企业官网建设流程全解析

做微服务这几年，我几乎每次评审架构方案时都会碰到同一个话题：微服务 Token 鉴权到底怎么做。别看网上讲 JWT 的文章一抓一大把，真到落地的时候，大家纠结的不只是“用不用 JWT”，而是谁来签发、谁来校验、怎么过期、出了安全问题怎么回收。这篇文章把我在项目里实际用过的几种主流 Token 鉴权方案梳理了一遍，包括无状态 JWT、分布式 Session、网关统一鉴权、以及 OAuth2 授权服务方案，同时会给出不同场景下的选型建议。不管你是刚开始拆服务，还是已经在处理多服务之间的认证乱象，都可以直接拿来做对照参考。我会尽量把每一步背后的理由也讲清楚，而不是只贴一段配置就收工。

1. 为什么服务一拆，登录状态就变得很难管

单体应用时代，登录状态其实很简单。用户登录后把 Session 存在应用进程里，或者放到一个共享缓存中，后面每个请求只要拿着 Session ID 来查一下，就知道请求属于谁。微服务拆开之后，问题马上就变了：用户请求先到网关，网关把请求转发给订单服务，订单服务又可能需要调用用户服务拿资料。这一路上，谁来确认“这个人是谁”？如果每个服务都各自去查会话，那会话到底存哪儿？如果都不查，那怎么判断请求不是伪造的？

这里有一个核心矛盾：我们普遍希望微服务尽量无状态，这样好扩展、好容灾，但“认证”这件事本质上是有状态的。你把用户信息塞进 Token 里，服务端就不用记状态了，可又面临 Token 泄露后无法立即让它失效的尴尬；你选择在服务端存状态，又会让“无状态化”带来的很多好处打了折扣。理解了这一层，后面每一种方案，本质上都是在“服务端记忆”和“客户端自证明”之间找一个平衡点。

实际项目里，我习惯用一个分类法来梳理需求：先看请求是从公网进来的，还是从内网服务之间进来的。公网进来的请求，身份可信度低，需要走完整的认证流程；内网服务之间的请求，身份可信度相对高，没必要每次都用同一套用户 Token 体系。很多团队的鉴权混乱，问题就出在这里——把所有请求都拿到同一个入口去验证，结果公网场景要用的能力，内部调用也在用，又笨重又慢。

除了身份来源，还要考虑三种典型场景：面向普通用户的 C 端场景，要求用户在使用过程中平滑续期；面向内部员工的 B 端后台，权限模型复杂，要求有精细的访问控制；还有就是服务间调用，比如定时任务系统要调用订单系统拉数据，这里需要的不是“用户身份”，而是一个“程序身份”。这三种场景对应的最优解法并不一样，下面的几种方案也正是按这些场景来划分的。

1.1 单体与微服务的关键差异

单体里一个 Session 可以只存在当前机器的内存里，因为请求总是打在同一台机器上。微服务打开负载均衡以后，同一个用户的两次请求可能落到不同实例上，如果你还把 Session 写在单机内存里，第二次请求就会因为“查无此会话”被无情地踢下线。解决方法是把 Session 外置到 Redis，或者干脆抛弃 Session 改用自包含 Token。

但这只是表象。更实质的差异是信任边界变了。单体是一个进程内部的事情，从控制器到数据层，代码都在同一个保护半径里；微服务是多个进程、多台机器协作，进程之间的网络调用是明文裸奔的，请求可以被伪造，也可能在链路中被篡改。所以需要有一整套机制保证：每个请求从哪儿来、身份是什么、权限到哪儿，都必须有依据可查。

理解了这些差异，就明白为什么微服务架构里要单独讨论 Token 鉴权，而不是继续沿用单体里的 Session 思路了。

1.2 两个典型的“身份请求”来源

我把请求来源拆成两类来设计，是非常实用的一种做法。一类是“用户请求”，通常经由浏览器、App、小程序甚至第三方开放接口进入系统，代表的是某个真实的人。这类请求需要完整的登录和授权校验，还要考虑 Token 过期、续期、多设备管理。

另一类是“服务请求”，是后台服务之间的互相调用。比如报表服务需要从用户服务拉取用户列表，这种调用并没有一个用户在操作，它要的不是“某个人的 Token”，而是“某个服务的调用凭证”。这类凭证生命周期短，权限范围可以收得很窄，签发机制也和用户登录完全不一样。

很多项目一开始没做这个区分，结果就是所有服务间的 HTTP 调用都硬塞一个用户 JWT 进去，一旦某个内部 Token 泄露，整个系统的数据都可能被拖走。这个风险我在后面网关方案里会重点讲。

2. 先分清两种 Token：引用型与自包含

讲方案之前，得先明确 Token 这个词到底指什么。Token 本质上就是一个“凭据”，客户端拿到它，后续访问时出示它，服务端借此判断请求合法性。但按校验方式不同，可以分成两大类。

第一类是引用型 Token。它本身不携带信息，就是一串随机字符，服务端拿到以后要去存储里查，查到对应的会话数据才有效。这就像图书馆门口给你一把存包柜钥匙，钥匙本身只是一块金属，管理员得拿它去柜子那里打开，才知道里面放了什么。

第二类是自包含 Token。最典型的就是 JWT。它把用户身份信息直接编码进了 Token 本身，服务端不需要查库，只要验一下签名，就知道 Token 是否真实、是否在有效期内。这就相当于一张带照片的通行证，保安拿到手，看照片对上脸就知道是你本人，不用再回办公室翻档案。

引用型的优势是可控性强，删掉存储里那条记录，Token 立刻就作废；劣势是需要额外的存储和高可用保障，一旦存储不可用，整个鉴权链路跟着挂。自包含的优势是无状态，任何服务只要拿到验证公钥就能校验，特别适合微服务分布式部署；劣势是不容易即时吊销，一旦私钥泄露、或者 Token 被完整截获，影响范围会很大。

2.1 引用型 Token 的维护成本

引用型 Token 听起来简单，但落地时要考虑的东西不少。首先是存储选型，绝大多数团队都用 Redis，因为 Key-Value 天然适合存会话。其次是高可用，Redis 一旦挂了，所有登录用户都会掉线，这比数据库挂掉还要可怕，因为数据库挂掉还能通过熔断避免流量冲击，Redis 挂掉则是直接拒绝所有需要登录的业务。

其次是过期策略。引用型 Token 通常在写入 Redis 时设置过期时间，为了保证活跃用户不掉线，又得在每次请求时续期，这就带来并发问题：多次请求同时续期，Redis 里的过期时间可能被覆盖成错误值。我在实际项目里干脆不做“每次请求续期”，而是用一个单独的中间件定时刷新活跃会话，或者在写操作时顺带续期，避免无意义的写放大。

你不能只看引用型 Token 实现简单，就忽略它背后的存储可用性、过期续期、序列化格式这些维护成本。后面方案二会专门展开。

2.2 自包含 Token 的签名与校验

自包含 Token 的校验核心是签名。JWT 的签名可以用对称算法也可以用非对称算法。对称算法 HS256，签发和验签都是同一个密钥；非对称算法 RS256，用私钥签发，用公钥验证。微服务架构里我一般建议直接用 RS256，原因很实际：你不必把同一个密钥复制到十几个服务里，只需要把公钥集中下发，万一哪个服务被攻破，私钥还在认证中心手里，风险可控。

公钥怎么下发也有很多讲究。最简单的方式是配置文件写死，但公钥一旦轮换，就要改所有服务；好一点的做法是通过配置中心下发，再配合定时刷新；更规范的方式是用统一认证服务暴露一个公钥接口，各服务本地缓存公钥，只在这个接口拉不到时才用本地兜底。方案没有绝对优劣，关键是你要事前想清楚“公钥过期了、换掉了，服务怎么感知”。

3. 方案一：无状态 JWT 全链路鉴权

这是讨论度最高、也最容易让人误以为“很省事”的方案。整体流程是：用户登录后，认证服务签发 JWT；客户端后续请求在 Authorization 头带上它；每个微服务收到请求后用公钥验签、检查过期时间，然后直接信任 Token 里的用户信息。整条链路没有共享存储，服务随便水平扩展，谁都能独立验签，这是它最吸引人的地方。

3.1 JWT 到底由哪几部分组成

JWT 分三段，用点号连接。第一段是 Header，通常包含算法和类型；第二段是 Payload，存放标准声明，比如 sub（用户标识）、iss（签发者）、aud（受众）、exp（过期时间）、iat（签发时间）、jti（JWT 唯一 ID）；第三段是签名。一个简单的 payload 长这样：

{ "sub": "100123", "name": "zhang3", "iss": "auth-center", "aud": "order-service", "exp": 1735689600, "iat": 1735686000, "jti": "4f2d3e1a-9b1c-4a0d-8c7e-2f1e1a2b3c4d" }

这里我要提醒一个常见误区：不要往 JWT 里塞太多业务数据。有人在 Payload 里放用户完整资料、岗位、部门、甚至上次登录 IP，最后发现每个请求都带着一个 4KB、8KB 的大头。HTTP 头在部分代理和网关上是有大小限制的，而且每次转发都要携带这份重量，浪费带宽也拖慢响应。正确姿势是只放必要的身份标识和关键属性，其它用户详情通过服务间调用或缓存去取。

3.2 签发与校验的关键参数

签发 JWT 时，几个时间参数必须认真设计。exp 是过期时间，iat 是签发时间，nbf 表示在这个时间之前不可用。实际项目里，我希望 access Token 有效时间定在 15 分钟到 2 小时之间。太短会让用户频繁重新登录，太长又会让泄露风险放大。

校验侧同样有几个容易漏掉的点。一是必须校验证书的算法，防止攻击者把算法篡改成 none，直接绕过验签；二是校验收音标准和 audience，防止一个服务签发的 Token 被用到另一个服务上；三是时钟偏移问题，不同机器的时间可能相差几秒，过期判断建议加一个小的可接受时钟偏移量，否则用户明明刚登录成功，下一秒请求却被判定为过期。

下面是一段偏 Java 风格的伪代码，展示的是校验逻辑最核心的部分：

try { Jwt jwt = Jwt.parser() .setVerifier(rs256PublicKey) .setExpectedIssuer("auth-center") .setExpectedAudience("order-service") .setClockSkewSeconds(60) .parse(accessToken); String userId = jwt.getSubject(); // 通过校验，继续执行后续业务逻辑 } catch (TokenExpiredException e) { // 提示前端刷新 Token } catch (SignatureException e) { // 记录告警，可能遭遇伪造请求 }

很多人忽略 setExpectedAudience，结果 token 在用户服务和订单服务之间通用，权限边界变得模糊。这个习惯很不好，我建议从第一天起就强制每个服务校验 audience。

3.3 过期、续期与强制失效

纯 JWT 有一个绕不开的痛点：没法在签发生效后远程作废。用户改密码了，用户被封禁了，或者 Token 被偷了，你总不能等着它自己过期。业界通用解法是引入黑名单机制：把要失效的 Token 的 jti 或用户 ID 写入 Redis，设置一个和 Token 剩余有效期一致的过期时间，每次验签时先查一下黑名单。

但这时候要注意，你已经从一个“完全无状态”的方案滑向了“半状态”方案了。黑名单 Redis 一旦不可用，你是选择放行所有请求还是拒绝所有请求，这需要有个预案。另外，为了让长期在线的用户不被过期时间打断，通常还要引入 refresh Token。refresh Token 单独签发，有效期可以长达 7 天甚至更长，只能通过一个固定的刷新接口换取新的 access Token。有人问为什么不直接把 access Token 时间调长，非要搞两个 Token 出来，我举个例子：access Token 被中间的某个服务日志拿走了，15 分钟就失效，损失可控；refresh Token 被拿走，理论上也有风险，但它通常存储更严格、校验更细致，而且可以通过服务端主动吊销，风险和收益完全不成比例。

4. 方案二：分布式 Session 方案

如果说 JWT 是“把信任交给客户端”，那分布式 Session 就是“把信任牢牢攥在服务端”。登录成功以后，服务端生成一个随机字符串作为 Token，把会话数据存到 Redis，把这个随机字符串返回给客户端。客户端后续请求带着这个字符串，服务端从 Redis 里查一次拿到用户信息，完成鉴权。

4.1 从内置 Session 到 Redis 共享 Session

分布式 Session 的核心是把原本存在单机内存里的会话数据，搬到所有服务都能访问到的共享存储里。最常见的实现方式是 Redis，也可以使用其他存储。我见过的一个典型错误是，直接把单机 Session 里的内存对象用 Java 原生的序列化塞进 Redis，结果因为类版本不一致导致反序列化失败。更稳妥的做法是定义一套独立的 Session 数据格式，用 JSON 存，各语言都能读，升级也方便。

Redis 里一条典型会话记录的 key 可以设计为 session:{userId}:{randomToken}，value 是用户 ID、昵称、角色列表、过期时间映射。为什么要加 userId 这一层？因为运营后台经常需要“查看某个用户的所有会话”，如果只用随机 Token 做 key，想踢人下线都不知道踢谁；加了 userId 前缀，可以很方便地按用户维度做清理。

4.2 Key 设计与过期策略

设计 key 时要特别注意 Redis 的过期策略。我给会话设置过期时间，通常用“相对活跃时间”，也就是用户如果一直有操作，会话就持续有效；如果超过 N 天没有任何操作，会话自动销毁。这种策略对后台管理系统特别友好，员工周一登录，下周一还能保持登录状态，但如果整个团队放了个长假回来，长假的第二天就全部过期，重新登录一次，安全上也说得通。

为了不让每次请求都去修改 Redis 的过期时间，我通常只在比较重的操作时更新过期时间，或者干脆用滑动过期中间件统一处理。这里要小心极端情况：如果一个请求链路特别长，网关续期完，第二个服务又续期完，多个服务同时续期会把 TTL 覆盖成不同时长。我的建议是只允许一个节点负责续期，其他节点只读。

SET session:100123:a9f8... "{\"userId\":100123,\"role\":\"admin\"}" EX 86400

4.3 何时选它而不是 JWT

分布式 Session 方案的优点非常明显：第一，可以随时删除会话，用户立刻掉线，这是后台管理系统最需要的能力；第二，服务端看到的数据永远是最新的，用户改权限后会话里的角色信息马上就能更新；第三，实现和排查都简单，没有签名、算法、公钥那些微妙的问题，一个 Redis 查询搞定。

缺点也很明显：每次请求多一次缓存网络开销；Redis 必须保障高可用；会话数据一旦从 Redis 里丢了，用户无感掉线。因此我通常这样选型：内部系统、员工后台、对“可撤销性”要求高的场景，优先用分布式 Session；对外提供 API 的开放平台、要求服务无状态快速扩展的场景，优先用 JWT。没有谁一定比谁高级，只有谁在这个场景里更合适。

5. 方案三：网关统一鉴权，服务间最小信任

如果说前两种方案讨论的是“Token 长什么样、谁来验”，那第三种方案要讨论的是“在哪儿验”。思路很清晰：把鉴权这层逻辑从所有服务里抽出来，只让 API 网关统一负责用户 Token 校验，后端每个服务不再自己验证用户身份，而是信任网关转发过来的身份头。

5.1 把所有外部请求“挡”在网关

网关是外部流量进入系统的唯一入口，天然适合做鉴权。用户带着 JWT 或 Session Token 访问任意接口，网关先验签，验过了，在请求头里写入 X-User-Id、X-User-Name 这样的身份信息，再转发给后端服务。后端服务只认这个头，不再需要解析签名或者查 Redis。

这样做最大的好处是避免重复劳动。如果没有网关统一校验，订单服务要验一次，用户服务再验一次，支付服务再验一次，每个服务都得实现同一套验签逻辑。一旦签发的 Token 格式升级，比如从 JWT 换成别的，所有服务都要跟着改。由网关统一收口以后，后端服务从鉴权这件事里彻底解脱出来，只需要做一个约束：外部请求不允许绕过网关。

但这里要强调一个安全问题：后端服务绝不能盲目信任请求头里的 X-User-Id。因为内网里如果有一个服务被攻破，攻击者可以直接构造这个头来冒充任意用户。所以网关在转发前要覆盖掉客户端传入的同名请求头，服务端也要有机制区分“来自网关的请求”和“内网服务之间的普通请求”。很多团队在这个细节上翻过车，我后面在踩坑实录里会再展开。

5.2 内网请求如何证明自己可信

一旦后端服务不再自行验证用户 Token，就必须回答一个问题：内网服务之间的调用，凭什么让对方相信你？总不能在网络调用里随便塞一个 X-User-Id 就说“我是订单服务”吧。

常用的手段有两类。一类是网络层隔离，让后端服务只监听内网地址，不暴露任何公网端口，网关作为唯一公网入口。这样即使有攻击者拿到了一个内部服务的地址，也没办法从外部直接访问，只能先打网关。

另一类是服务间身份认证。常见做法是使用客户端证书的 mTLS，每个服务有独立证书，调用方和服务端在 TLS 握手阶段相互验证身份。没到 mTLS 这个级别的话，也可以采用短期的内网调用 Token，比如由认证中心统一签发，有效期只有几分钟，服务之间的 SDK 会自动换发。需要注意的是，不要把用户 JWT 直接拿来做服务间认证，因为用户 Token 代表的是“某个人”，服务间认证代表的是“某个程序”，混在一起会让权限体系复杂到没法收场。

5.3 身份头替换与透传的细节

网关统一鉴权还有一个很容易忽略的细节：身份信息是“替换”还是“透传”。原样透传客户端发来的 Authorization 头，会让后端服务拿到原始 Token，可能在日志里记录下来，安全隐患很大。网关校验完成之后，我一般直接把原始 Authorization 头删除，换成内部统一命名的身份头。

X-User-Id: 100123 X-User-Role: admin X-Request-Trace-Id: 8f3a... (用于链路追踪，不是身份信息)

后端服务之间继续透传这几个头，就能在整条调用链上保持同一个用户身份。这里要注意，身份头的 key 必须全组统一，不能订单服务叫 X-User-Id，用户服务叫 X-UserId，到时候排查问题能把人绕晕。另外，如果业务需要拿到用户原始 Token 去做第三方开放接口转发，那就说明设计方案其实还没想清楚，需要单独设计一个受控的临时凭证机制，而不是简单地把 Token 扩大传播范围。

6. 方案四：基于授权服务的统一认证与授权

前三种方案解决的是“你是不是你”的问题，也就是认证。当系统需要一个统一的地方来管理“你能干什么”的授权能力，尤其是存在多个应用端、第三方接入方、多种权限模型时，就应该考虑引入一个独立的授权服务了。

6.1 为什么要引入授权服务

当公司内部同时挂着十几个系统，每个系统都自己搞一套用户体系，员工账户在两个系统里不能通用，每套系统都要登一次，这是很典型的“账号孤岛”。引入统一认证与授权服务，把登录、身份签发、权限判定全部集中到一个中心，各业务系统作为接入方，只负责接收中心返回的身份信息并做业务处理。这样做的好处是账户数据统一、审计集中、权限策略一致。

在微服务架构里，授权服务一般扮演两个角色：一个是认证服务器，负责登录和签发 Token；另一个是资源服务器集群，业务服务在收到请求后，如果拿不准某个 Token 有什么权限，就向授权服务校验或获取权限信息。有些团队把这两者合并成一个中心，有些团队会拆成独立组件。

6.2 微服务与授权服务如何协作

一个典型的协作过程是这样的：用户访问客户端，客户端把用户导向授权服务的登录页，用户输入账号密码，授权服务校验通过后，向客户端签发授权码，客户端再用授权码换取了 access Token 和 refresh Token。接下来，客户端拿着 access Token 访问业务服务，业务服务作为资源服务器，带着 Token 向授权服务发起校验，确认 Token 有效且拥有当前请求所需的 scope。

这一套流程规范的实现就是 OAuth2 协议体系。微服务里最常见的模式有两种：一是授权码模式，用于有后端的应用；二是客户端凭证模式，用于服务间调用，签发出来的就是一种“程序身份 Token”。在开放平台场景，这种模式几乎是唯一选择，因为你需要把“某个用户在某个应用里能访问哪些接口”这种授权关系管理起来，而不是让每个业务服务自己拍脑袋判断。

# 客户端凭证模式示意 POST /oauth/token client_id=order-service client_secret=xxxx grant_type=client_credentials

6.3 权限粒度谁来判断

引入授权服务之后，自然产生一个新问题：细粒度的权限判断到底放在哪里。太小的判断放在授权服务，会导致业务服务每次请求都得做一次远程调用；全部放在业务服务，又会让权限规则散落各处，中心化形同虚设。

我在实践中比较倾向“两级权限模型”：授权服务负责确认身份和粗粒度权限，比如“你是否属于可访问订单域的用户”；业务服务负责细粒度数据权限，比如“你是否只允许看自己创建的订单”。粗粒度统一收口，细粒度贴近业务处理，查询次数和灵活性之间能取得一个比较好的平衡。角色和权限数据更新后，业务服务内的本地缓存需要做失效机制，否则权限改了，用户行为却还是老版本，等用户投诉再排查就晚了。

7. 四种方案横向对比与选型参考

讲了这么多，做一个横向对比，把关键差异放在一张表里，方便你对照自身情况来挑。

7.1 四个阶段的选择策略

我一般这样给团队建议：如果项目刚开始拆服务，用户规模不大，后台管理类为主，直接选分布式 Session，实现简单、可控制强，团队成员都容易理解。如果对外提供 API，并且需要支持多端、第三方应用，那么 OAuth2 授权服务是躲不掉的，早做比晚做好。如果公司已经有很多服务了，但还没有独立授权服务，先做网关统一鉴权，把公网入口收住，再逐步演进到统一认证。如果团队技术能力强，业务形态是标准微服务，对水平扩展有明确诉求，那无状态 JWT 配合 RS256 是一个很顺手的方案。

7.2 场景选型：照着选就行

我来举几个完全虚构但非常典型的项目场景。

场景一，某公司内部项目管理平台，有员工后台和移动端。员工数量撑死几千，要求支持管理员随时把某个员工踢下线、审计所有人登录记录。这种场景明显应该用分布式 Session。它不需要 JWT 那套复杂度，踢人下线直接删 Redis 记录，实时生效。

场景二，某开放数据平台，面向第三方开发者提供数据查询 API。每个第三方应用要有独立凭证，应用之间权限边界严格，还要支持按套餐控制调用量。这种场景就该上 OAuth2 客户端凭证模式。业务服务通过网关校验 Token，再由授权服务判断 scope，整个链路清晰可控。

场景三，某电商平台，流量大、服务数量多、希望扩展时不用动鉴权链路。这种场景用无状态 JWT更合适，网关统一验签，服务端只保留验签公钥，新增一个副本服务不需要同步任何会话数据。同时加 refresh Token 解决会员长期在线的问题。

选型不是越高级越好，而是匹配场景，不要为一个三千人的系统就搭一个四层授权体系，那是给自己找麻烦。

8. 实战中的坑与排查实录

最后汇总一些我在真实落地过程中踩过的坑，这些经验几乎都是线上事故换来的，写出来给大家做一个排查速查表。

8.1 JWT 无法注销的风险与黑名单兜底

有一个内部系统，最初设计的是纯 JWT，没有黑名单。结果有一天安全巡检发现，一个离职员工的 Token 还能访问系统，因为 Token 要到第二天才过期，而账号已经在当天封禁了。从那时起，我就在所有 JWT 方案里强调黑名单兜底：凡是需要即时封禁的场景，必须把用户 ID 或 jti 写入 Redis，校验时先查黑名单。同时还兼容了一种极端情况：黑名单 Redis 连接超时时，系统自动拒绝要求必检的接口，宁可让用户重登，也不能放行已被封禁的用户。

8.2 令牌过期时间设错了，用户骂声一片

有个 C 端项目一开始把 access Token 设置为 7 天，结果用户反馈“App 用几天就莫名其妙要重新登录”，排查了半天才发现是后端每 12 小时强制刷新一次 access Token，却不刷新 refresh Token 的状态，一边想让 Token 长命，一边又用短逻辑去续期，两边时间对不上。后来统一改成 access Token 2 小时、refresh Token 14 天，并且 refresh 接口不设置 UA 校验以外的额外约束，问题就消失了。过期时间不是随手填的数字，要结合业务活跃频率、安全等级和续期逻辑一起定。

8.3 内网服务被绕过的安全事件

这个坑出现在网关方案落地过程中。某团队把网关校验做好了，后端服务开始信任 X-User-Id，但内部有一个老的端口仍然对办公网开放，员工可以直接拿文件服务下载接口拼请求，伪造 X-User-Id 越权访问数据。后来整改用了三层措施：第一，所有后端端口只能从网关内网访问；第二，网关转发前删除客户端传入的 X-User-Id 头，防止伪造；第三，内部服务之间加日志审计，出现“奇怪的跨用户数据访问”能追到源头。

8.4 鉴权链路故障导致全站登录失效

分布式 Session 方案最怕 Redis 故障。有一回 Redis 集群升级，某个分片短暂不可用，结果所有会话都失效，用户集中重新登录，把登录接口打崩，连带数据库压力飙升。处理这类问题，我的经验是三层：缓存降级要有“读多写少”的容忍策略；登录接口要做限流；会话丢失时要有自动重登的友好提示，而不是直接报 500。另外，Redis 主从切换时，如果从节点还没完全同步，会话数据可能丢，所以写入策略要尽量采用“失之毫厘”也能兜底的模式，比如关键会话同时持久化一份到本地存储作为最终恢复来源。

8.5 Token 日志泄露，谁能猜到

这个坑比较隐蔽。某次排查线上问题，大家打开日志平台搜请求 ID，发现某个请求头里带上了一长串 JWT。日志平台的权限本来就比较宽，结果 Token 被复制走，直接借用了别人的身份。从那以后，我对日志采集做了强制脱敏，所有带 Token、密码、Authorization 的字段一律打码。这个习惯看起来很简单，但如果不写进团队的编码规范里，迟早会在某个全链路日志收集方案上线时踩中。

结束语

我个人在这些方案里来回切换过很多次，最大的体会是：没有银弹，只有匹配。引用型和自包含可以混合用，网关统一鉴权和分布式 Session 也可以搭配得很默契，关键是想清楚你的业务属于哪类场景、愿意为哪类风险买单。如果让我只给一个建议，就是先画一张系统拓扑图，标出哪些服务面向公网、哪些只跑内网，再根据“用户被踢下线后是否必须立刻生效”这条硬指标去选方案，比听别人说哪个方案流行要可靠得多。另外在团队里推行统一鉴权工具包，把验签、刷新、黑名单逻辑封装成同一个基础依赖，避免每个服务各自维护一版，是投入产出比最高的一件事。