go微服务鉴权需分层解决身份验证（who）、权限校验（what）和服务间信任（how）：jwt必须用rsa/ecdsa公钥验签并动态加载jwks，rbac权限查o(1)映射且规则运行时更新，服务间通信禁用用户jwt，强制mtls+service token隔离凭证边界。
Go微服务鉴权不是“加个中间件就完事”，而是要分清身份验证（who）、权限校验（what）和服务间信任（how）三层问题。直接套用jwt.Parse或硬编码HasPermission方法，在服务拆分后大概率会出权限绕过、token吊销失效、服务调用被伪造等问题。
JWT解析必须用公钥验签，不能只靠HS256共享密钥
很多团队一开始用jwt.SigningMethodHS256配一个全局your-secret-key，看似简单，但一旦某个服务被攻破，整个系统的token签名密钥就暴露了。服务间通信场景下更危险——恶意服务可伪造任意用户token。
- 生产环境务必改用RSA或ECDSA非对称签名，认证服务用私钥签发token，各业务服务只持有公钥验签
-
jwt.ParseWithClaims回调里必须显式检查t.Method类型，否则攻击者可篡改alg头部为none绕过验签 - 公钥建议从JWKS端点动态加载（如
https://auth.example.com/.well-known/jwks.json），避免重启服务才能更新密钥
RBAC权限校验不能只查内存结构，得支持运行时变更
把角色和权限硬编码在User结构体里，或者每次请求都从DB全量加载Roles []Role，在微服务里是反模式。权限规则变一次就得发版，且高并发下DB压力大。
- 权限判断逻辑应下沉到独立的
authz服务，通过gRPC或HTTP API统一查询，比如POST /v1/authorize传入subject、resource、action - 本地可缓存
role → permissions映射（用sync.Map+TTL），但缓存失效必须监听配置中心（如etcd或Consul KV变更） - 避免在
HasPermission里做嵌套循环遍历——实际应转成map[string]struct{}查O(1)，且权限字符串格式要统一（如"order:cancel:own"）
服务间调用必须用mTLS或Service Token，不能复用用户JWT
把前端传来的用户JWT直接透传给下游服务，等于把用户权限“借”给内部服务，一旦订单服务被入侵，它就能用这个token去调支付服务，完全越权。
- 服务间通信必须用独立凭证：
X-Service-Token头传Service Token（由网关或控制平面签发），且该token只含服务标识和有限scope（如"service:order"） - 更安全的做法是启用mTLS：每个服务启动时加载唯一证书，HTTP client设置
tls.Config{Certificates: ..., VerifyPeerCertificate: ...} - 网关层要做token剥离——用户JWT只用于认证和生成上下文，服务间转发时替换为Service Token，且禁止下游服务再解析原始JWT
真正难的不是写Parse或HasPermission，而是让权限决策点收敛、凭证边界清晰、变更不重启。任何一个环节把“信任”错当成“便利”，都会在横向扩展后变成安全裂缝。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
