diff --git a/hzh/MS/02-服务治理.md b/hzh/MS/02-服务治理.md
index d7a3c6b..cf2831a 100644
--- a/hzh/MS/02-服务治理.md
+++ b/hzh/MS/02-服务治理.md
@@ -133,6 +133,7 @@ graph LR
 
 > [!question] 权衡题
 > 有人说："鉴权放到网关统一做，避免每个服务重复写。"但如果某个内部服务不需要鉴权呢？或者不同团队要求不同的鉴权方式呢？你怎么设计才能兼顾统一性和灵活性？
+> 👉 [[02-服务治理/网关鉴权策略]] — 分层鉴权模型详解
 
 ## 服务间通信
 
diff --git a/hzh/MS/02-服务治理/网关鉴权策略.md b/hzh/MS/02-服务治理/网关鉴权策略.md
new file mode 100644
index 0000000..809f0e6
--- /dev/null
+++ b/hzh/MS/02-服务治理/网关鉴权策略.md
@@ -0,0 +1,177 @@
+---
+tags: [microservice, api-gateway, auth, service-mesh, mTLS, jwt, rbac]
+create time: 2026-04-30 15:30
+---
+
+# 网关鉴权分层设计
+
+## 概述
+
+探讨"鉴权是否应该全部放在网关统一处理"这个常见架构争议，给出兼顾统一性和灵活性的分层鉴权方案。
+
+## 问题的本质
+
+### 一刀切的陷阱
+
+> [!question] 引出思考
+> 有人说："鉴权放到网关统一做，避免每个服务重复写。"但如果某个内部服务不需要鉴权呢？或者不同团队要求不同的鉴权方式呢？你怎么设计才能兼顾统一性和灵活性？
+
+核心矛盾在于：**网关做鉴权的优势是集中化和性能**，但代价是 **失去对差异化需求的表达能力**。现实中至少存在三种网关无法处理的场景：
+
+| 场景 | 例子 | 为什么网关搞不定 |
+|------|------|----------------|
+| **内部调用免鉴权** | A服务直调B服务的内部查询接口 | 外部请求到不了这里，网关做无意义开销 |
+| **不同团队标准不同** | 财务系统要求 OAuth2+MFA，运营后台只需 API Key | 策略硬编码在网关里会变成巨石中间件 |
+| **精细化权限控制** | 订单服务需要判断"用户A是否有权看这笔订单" | 网关不知道业务数据归属关系 |
+
+## 三层鉴权架构
+
+```mermaid
+flowchart TB
+    subgraph L1["第一层：网关层 - 你是谁？"]
+        G1["JWT / Token 校验"]
+        G2["IP 白名单"]
+        G3["基础限流"]
+    end
+
+    subgraph L2["第二层：服务入口层 - 你能做什么？"]
+        S1["内部服务间 Token 验证"]
+        S2["mTLS 双向认证"]
+        S3["角色 / 权限检查"]
+    end
+
+    subgraph L3["第三层：业务逻辑层 - 你能操作这个资源吗？"]
+        B1["行级权限：userId == order.userId"]
+        B2["数据范围：仅本部门可见"]
+        B3["审批状态机流转"]
+    end
+
+    Client["外部请求"] --> GW["API Gateway<br/>L1 快速过滤非法请求"]
+    GW --> svcA["Order Service"]
+    GW --> svcB["Finance Service"]
+    
+    svcA --> L2
+    svcB --> L2
+    
+    L2 --> L3
+    
+    svcA -.->|"内部调用"| svcC["Inventory Service<br/>仅 L2 鉴权，跳过 L1"]
+    svcC --> L2
+```
+
+### 三层职责划分
+
+> [!summary] 鉴权分层原则
+>
+> | 层级 | 关注点 | 粒度 | 谁来实现 |
+> |------|--------|------|---------|
+> | **L1 网关层** | 身份认证 — "你是合法用户吗？" | 粗粒度（用户级） | 平台团队统一维护 |
+> | **L2 服务层** | 接口授权 — "你有权限调这个接口吗？" | 中粒度（角色/服务级） | 各业务团队自己定义 |
+> | **L3 业务层** | 数据权限 — "你能操作这条数据吗？" | 细粒度（数据级） | 业务逻辑自身实现 |
+
+**设计哲学**：越往上过滤越早失败，但信息越少；越往下信息越多但成本越高。每一层只做它最擅长的那件事。
+
+## 内部服务调用的鉴权策略
+
+对于内部服务互不调用网关的问题，答案是：**不是不需要鉴权，而是用更轻量级的鉴权**。
+
+```go
+// 服务间调用：用短期签名 Token 代替完整 JWT
+func serviceToServiceAuth(serviceID string, target string) string {
+    // 使用共享密钥 HMAC 签发短时效 Token
+    payload := map[string]string{
+        "sub":    serviceID,
+        "target": target,
+        "exp":    time.Now().Add(5 * time.Minute).Format(time.RFC3339),
+    }
+    return signWithSharedKey(payload) // 比解析完整 JWT 便宜得多
+}
+
+// 接收方校验
+func verifyInterServiceToken(token string) error {
+    claims, err := verifyHMAC(token)
+    if err != nil {
+        return fmt.Errorf("无效的内部服务 Token")
+    }
+    // 额外检查：该服务是否有权限访问目标服务
+    if !allowedAccess(claims.ServiceID, claims.Target) {
+        return fmt.Errorf("服务 %s 无权调用 %s", claims.ServiceID, claims.Target)
+    }
+    return nil
+}
+```
+
+> [!note] 解释
+> 这段代码展示了两个关键点：一是用 **HMAC 短期 Token** 替代完整的 JWT 校验链，将延迟控制在 ~1ms 量级；二是在校验身份之外还做了 **服务间的访问控制检查**，避免被入侵的服务冒充其他服务。
+
+内部鉴权方案对比：
+
+| 方案 | 延迟 | 安全性 | 适用场景 |
+|------|------|--------|---------|
+| 完全跳过鉴权 | ~0ms | ❌ 不安全 | 同 Pod 内 Sidecar 互调 |
+| 简单 Token 签名 | ~1ms | ⚠️ 中等 | 同一安全域内的服务互调 |
+| mTLS 双向认证 | ~2ms | ✅ 高 | 跨租户、跨团队、混合云环境 |
+
+## 多团队差异化鉴权方案
+
+针对第二个问题——不同团队需要不同的鉴权方式——推荐用 **策略即代码（Policy-as-Code）** + **可插拔鉴权中间件**。
+
+```go
+// 鉴权处理器接口 — 每个团队实现自己的策略
+type AuthMiddleware interface {
+    Name() string
+    CanHandle(ctx *Context) bool       // 这个服务 / 路由是否适用我的策略
+    Authenticate(w http.ResponseWriter, r *http.Request) bool
+}
+
+// 注册表模式：运行时动态装配
+var registry = make(map[string]AuthMiddleware)
+
+func Register(name string, m AuthMiddleware) {
+    registry[name] = m
+}
+
+// 路由级别的策略声明
+// router.go
+router.Use(multiAuth(
+    "jwt-gateway",   // L1 网关已经校验过的 JWT
+    "rbac-finance",  // 财务团队的额外 RBAC 校验
+))
+```
+
+> [!note] 解释
+> 通过接口抽象 + 注册表模式，每个团队可以在不修改基础设施代码的前提下，将自己团队的鉴权策略注册到系统中。`multiAuth` 按顺序执行所有匹配的中间件，任一失败则拒绝请求。
+
+这样做的收益：
+
+> [!tip] 核心收益
+>
+> 1. **统一但不僵化**：网关承担公共部分，各服务按需叠加自定义策略
+> 2. **渐进式迁移**：老服务可以逐步从简单鉴权升级到新策略，不用一次性改造
+> 3. **职责边界清晰**：平台团队维护基础设施鉴权，业务团队维护业务鉴权
+> 4. **审计友好**：每层的鉴权结果独立记录，出问题时能精确到是哪一层拦截的
+
+## 什么时候应该让网关不做鉴权？
+
+> [!warning] 反模式警告
+>
+> 以下情况考虑 **绕过网关鉴权**，由服务自行处理：
+>
+> 1. **内部工具/API**：定时任务脚本、后台管理接口，不走对外网关
+> 2. **IoT 设备直连**：设备有自己的凭证体系，不适合套用用户 JWT
+> 3. **Webhook 回调**：上游厂商的回调签名验证应在消费侧服务完成
+> 4. **高性能扫描场景**：高频行情推送，鉴权开销占总延迟 >5% 时可考虑批量校验
+
+## 总结
+
+这套设计的核心理念是 **"默认严格、按需放宽"**：
+
+- 网关做 **防御纵深的第一道**——挡住明显非法的请求，保护后方
+- 每个服务保持 **独立的鉴权决策能力**——因为最了解自身需求的只有服务本身
+- 服务间通信用 **轻量级信任机制**——不过度设计，但绝不调包
+
+最终达到 **统一的安全基线 + 灵活的差异化策略** 的平衡。
+
+## 关联笔记
+
+- [[hzh/MS/02-服务治理]] — 服务治理总览