生产可用jwt认证需三步：环境变量读密钥转[]byte、显式校验token.valid、透传时降级为可信字段；硬编码密钥、忽略token.valid、混用时间戳单位将导致认证失效。
直接用 golang-jwt/jwt + 环境变量密钥 + 显式校验三步走，就能跑通一个生产可用的无状态认证中心；硬编码密钥、忽略 token.Valid、混用毫秒/秒级时间戳，这三处一错，整个认证就形同虚设。
JWT密钥必须从环境变量读取且转成[]byte
Go 的 jwt.SigningMethodHS256 内部调用 hmac.New()，它只接受 []byte 类型密钥。传入字符串虽不报错，但可能因隐式转换失败（比如含 BOM 或不可见空格）导致签名无效或验签永远失败。
- 启动时就读取并强转：
secret := []byte(os.Getenv("JWT_SECRET")) - 必须校验非空和长度：
if len(secret) 就 <code>log.Fatal—— HS256 安全性要求密钥至少 32 字节 - 别用配置文件或
os.Args存密钥：它们容易被日志打印、备份泄露或权限误配暴露 - Kubernetes 下用
Secret挂载；Docker Compose 用secrets字段，而非environment
ParseWithClaims 总提示 “token is expired” 怎么办
最常见原因是 exp 字段用了毫秒时间戳，但 jwt.ParseWithClaims 默认用 time.Now().Unix()（秒级）校验，两者差 1000 倍，token 一签发就过期。
- 签发时务必用
.Unix()："exp": time.Now().Add(24 * time.Hour).Unix() - 别用
.UnixMilli()或手动乘 1000 - 若服务端和客户端时钟偏差大（比如 >5 秒），可加容忍：
jwt.WithValidTimeFunc(func(t time.Time) bool { return t.After(time.Now().Add(-5 * time.Second)) }) -
iat字段不能用于业务判断——它完全由客户端控制，可任意篡改
从 token 取 uid 为什么总 panic
直接写 token.Claims.(jwt.MapClaims)["uid"] 会 panic：token 解析失败、结构不对、字段缺失，甚至类型断言失败，都触发 panic，且无法区分错误类型。
- 必须分两步：先确认
token != nil && token.Valid && err == nil，再取字段 - 取值用安全方式：
if claims, ok := token.Claims.(jwt.MapClaims); ok && uid, ok := claims["uid"].(float64); ok { ... } - 更推荐自定义 Claims 结构体并实现
Valid() error，把字段存在性、类型校验、业务规则都收口进去 - 别依赖
err是否为 nil 判断 token 有效性——err == nil只代表语法合法，不代表签名正确或未过期
微服务间透传 JWT 该用哪个 HTTP Header
直接转发原始 Authorization: Bearer xxx 头，会让下游服务重复解析、浪费 CPU，还可能被中间件自动拦截校验，造成冲突或绕过。
- 网关鉴权后，应剥离原始 token，改用可信内部头透传必要字段，如：
X-User-ID、X-User-Roles - 若下游确实需要原始 token（比如按需重验签），必须换非标准头，如：
X-Forwarded-JWT，并在下游禁用对该头的自动处理逻辑 - 绝对不要在多个服务中复用同一个
Authorization头做层层验证——这不是透传，是污染 - JWT 本身无状态，但权限变更（如角色调整、强制登出）必须靠有状态机制兜底，比如 Redis 黑名单或用户 token 版本号
真正难的不是签发 token，而是让每个服务都严格遵守校验链：环境变量读密钥 → []byte 传入 → ParseWithClaims 后必判 token.Valid → 取字段前先做类型断言和存在性检查 → 透传时主动降级为可信字段而非裸 token。漏掉任何一环，无状态就变成“无防护”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
