JWT签名密钥必须用[]byte而非字符串直传，因jwt.Parse等函数内部哈希处理要求[]byte类型；字符串直传会导致静默失败或验证不通过，且密钥长度须≥32字节。
JWT签名密钥必须用 []byte而非字符串直传
Go的jwt.Parse和jwt.SigningMethodHS256等函数内部对密钥做哈希处理时，要求密钥是 []byte类型。如果直接传入字符串（比如"my-secret"），虽然编译不报错，但运行时Parse可能静默失败或验证始终不通过——因为底层把字符串指针当成了密钥内容。
实操建议：
- 初始化密钥时显式转为字节切片：
jwtKey := []byte(os.Getenv("JWT_SECRET")) - 避免在
SigningMethodHS256.Sign中临时拼接密钥，如[]byte("prefix-" + secret)，应提前计算并复用 - 密钥长度建议≥32字节（HS256最低要求），否则
Parse会返回"key is not of expected type"错误
解析token时必须显式调用token.Valid且检查err
很多开发者以为jwt.Parse返回非nil *Token就代表验证成功，其实不然。该函数只负责解析结构+基础校验（如签名格式、过期字段是否存在），不执行签名比对或过期时间检查。真正触发这些逻辑的是token.Valid字段读取，它内部会调用Verify并检查exp/nbf等声明。
常见错误现象：token已过期但仍能通过if token != nil判断，后续业务逻辑误认为身份有效。
立即学习“go语言免费学习笔记（深入）”；
正确写法：
token, err := jwt.Parse(reqToken, func(token *jwt.Token) (interface{}, error) {
return jwtKey, nil
})
if err != nil || !token.Valid {
http.Error(w, "invalid token", http.StatusUnauthorized)
return
}
无状态服务里别存token到内存或Redis做“黑名单”
所谓“无状态”，核心是拒绝在服务端维护token生命周期状态。但很多人为了支持登出/吊销，习惯性把token加到Redis黑名单，这直接破坏了无状态设计，还引入单点故障和延迟。
更合理的做法是利用JWT自身机制：
- 缩短
exp时间（如15分钟），配合前端自动刷新机制（用refresh token换新access token） - 在
claims中嵌入user_version或revoked_at时间戳，每次解析时比对用户最新版本号（从DB查） - 若必须立即失效，改用JTI（token唯一ID）+ DB记录，但只查不存token本体；验证时
SELECT 1 FROM revoked_jti WHERE jti = ? AND revoked_at > ?
注意：所有这些方案都依赖每次请求时实时查DB或缓存，不能省略验证步骤。
中间件里提取token要防Authorization: Bearer 前缀缺失或空格错位
HTTP头Authorization的规范格式是"Bearer xxx"，但客户端可能传"bearer xxx"（小写）、"Bearerxxx"（缺空格）、甚至"Basic xxx"（协议混淆）。直接strings.Split(header, " ")再取第二项极易panic或取错值。
安全提取方式：
- 先
strings.TrimSpace(header)去首尾空格 - 用
strings.Cut(header, " ")拆分，检查ok为true且first == "Bearer"（忽略大小写用strings.EqualFold） - 若拆分后
second为空，直接拒掉，不尝试Parse
示例片段：
auth := r.Header.Get("Authorization")
if auth == "" {
http.Error(w, "missing Authorization header", http.StatusUnauthorized)
return
}
scheme, token, ok := strings.Cut(auth, " ")
if !ok || !strings.EqualFold(scheme, "Bearer") || token == "" {
http.Error(w, "invalid Authorization format", http.StatusUnauthorized)
return
}
JWT无状态验证真正的复杂点不在签名或解析，而在于如何让每个请求都严格、可重复地完成「密钥加载→头解析→签名验证→声明校验→业务上下文注入」这一整条链路，且任意一环出错都不留模糊空间。最容易被忽略的是：你以为跳过了某步（比如没检查token.Valid），实际只是把bug压到了下游业务里。
