jwt可替代session实现微服务无状态认证：将用户id、角色等信息编码进token，由网关签发并透传至各服务，服务端仅需验签解析即可获取上下文，避免共享session存储与跨服务耦合。
JavaScript 中的 Session 本身是浏览器端与单个服务端应用之间的状态机制，在微服务架构中它无法直接跨服务传递用户上下文。因为每个微服务独立部署、独立会话管理，传统基于 Cookie + Session ID 的方式会失效——你不能让所有微服务共享同一份内存或 Redis 中的 Session 存储（即使技术上可行，也违背微服务的松耦合原则）。
用 JWT 代替 Session 传递用户身份和权限
主流做法是将用户认证后的关键信息（如 user_id、role、scope）编码进 JWT（JSON Web Token），由网关或登录服务签发，后续请求携带该 Token（通常放在 Authorization Header 中）。各微服务只需验证签名、解析 payload，无需查 Session 存储。
- 前端在登录成功后保存 JWT（推荐存 localStorage 或 httpOnly Cookie，视安全要求而定）
- 每次请求通过 fetch / axios 拦截器自动添加
Authorization: Bearer <token></token> - 微服务使用轻量库（如 jose、jsonwebtoken）校验签名并提取用户上下文
- 注意设置合理的过期时间，并配合 refresh token 实现续期
通过 API 网关统一注入用户上下文
网关（如 Kong、Nginx + Lua、或自研 Node.js 网关）可在请求入口处完成鉴权，解析 JWT 后，把用户 ID、角色等字段作为 HTTP Header（如 X-User-ID、X-User-Roles）透传给下游服务。
- 避免每个微服务重复解析 Token，提升性能和一致性
- 下游服务可直接读取 Header 获取上下文，无需再验签
- 网关还可做权限预检（如 RBAC）、租户隔离、请求打标等
前端主动传递上下文（适用于非 HTTP 场景）
当微服务间存在 WebSocket、gRPC、消息队列等非 HTTP 通信时，JWT 或 Header 不适用。这时需前端或上游服务在调用时显式携带上下文数据。
- WebSocket 连接建立时，将 Token 或用户 ID 作为 query 参数或初始 payload 发送
- 调用 gRPC 方法时，通过 metadata 传入
user_id、auth_token等键值对 - 发 MQ 消息时，在 message headers 或 payload 中嵌入必要上下文字段（注意脱敏和最小化）
避免在客户端存储敏感上下文
JavaScript 运行在用户可控环境，任何存在前端的用户信息都可能被篡改或泄露。必须遵守最小权限原则：
- JWT 中只放必要字段（如 sub、roles、exp），不放手机号、邮箱等 PII 信息
- 服务端始终以 Token 签名和白名单 scope 为准，不信任前端传来的任意字段
- 高敏感操作（如支付、删账号）必须二次校验（如短信/指纹确认），不能仅依赖初始 Token
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
