服务端验签失败90%源于signingString拼接不一致：method小写、path用EscapedPath、timestamp秒级、nonce16字节hex、sortedQuery需url.PathEscape且按key排序、bodyHash用原始字节计算；拼接格式为method\npath\ntimestamp\nnonce\nsortedQuery\nbodyHashHex。
签名原文拼接顺序和编码必须严格一致
服务端验签失败，90% 是因为客户端和服务端拼出的 signingString 不一致——不是 HMAC 写错了，是字符串本身对不上。关键字段缺一不可、顺序不能调换、分隔符必须统一为 \n。
-
method：全小写，如get或post，别用r.Method直接拼，要转小写 -
path：必须用r.URL.EscapedPath()，不是r.URL.Path（后者已被自动 decode，中文/特殊字符会乱） -
timestamp：秒级时间戳（time.Now().Unix()），毫秒级容易导致窗口校验不一致；注意客户端和服务端都用 UTC -
nonce：16 字节随机串，用crypto/rand.Read()生成后 hex 编码，明文传参 -
sortedQuery：从r.URL.RawQuery解析，url.ParseQuery()→sort.Strings(keys)→ 每个 key 和 value 单独调用url.PathEscape()（不是url.QueryEscape()，后者把空格转成+）→ 拼成key1=value1&key2=value2 -
bodyHash：若接口有 body，必须先io.ReadAll(r.Body)得到原始字节，再用sha256.Sum256(bodyBytes).Sum(nil)算 hash；之后用bytes.NewReader(bodyBytes)重建 Body 供后续逻辑读取
最终拼接格式：method + "\n" + path + "\n" + timestamp + "\n" + nonce + "\n" + sortedQuery + "\n" + bodyHashHex，末尾不加换行，所有字段之间仅一个 \n。
hmac.New 参数类型错位是签名恒定不变的主因
八成签名恒定不变或 signature mismatch，源于 hmac.New 参数类型错位：
- 第一个参数必须是哈希构造器函数，如
sha256.New（不带括号）；写成sha256.New()会编译报错 - 第二个参数必须是原始
[]byte，不能是中间多转一次的string或未解码的密钥字符串 - 如果密钥配置为 base64 字符串（如
"aGVsbG8="），启动时必须用base64.StdEncoding.DecodeString(secret)一次性解码并缓存 - 如果密钥是 hex 字符串（如
"deadbeef"），用hex.DecodeString(secret) - 绝不能写成
[]byte(string([]byte(secret)))——非 ASCII 字符会静默损坏；调试时打印len(key)和fmt.Printf("%q", key)，确认无 BOM、首尾空格或不可见字符
验签前必须做三重校验，少一项等于没防
只比对 hmac.Equal(sig1, sig2) 是最大误区。攻击者截包重放，只要签名值还有效，就能绕过业务逻辑：
立即学习“go语言免费学习笔记（深入）”；
- 时间戳校验：检查
X-Timestamp是否为纯数字字符串，再用abs(reqTime - time.Now().Unix()) > 300拒绝偏差超 5 分钟的请求 - 签名格式合法性：拒绝空或长度异常的
X-Signature（如非 64 位 hex 字符） - header 是否缺失：用
r.Header.Get("X-Signature")而非r.Header["X-Signature"]，避免大小写混淆（Go 默认 normalize header key）
提取完立即校验，不要缓存未验证的签名值到结构体字段中。
Token 防重放必须依赖服务端状态记录
JWT 本身仅提供签名验证和过期时间（exp）控制，无法识别请求是否首次使用，故无法防范有效期内的重放攻击；必须结合服务端状态记录（如 Redis 存已用过的 jti）实现“一次有效、用完失效”。
- 必须配合服务端状态记录（如 Redis 存已用过的
jti+ 过期时间），且 TTL 要略大于 token 最大可能网络延迟 + 处理耗时（比如设为 5 分钟） - 不要把
jti设为纯随机 UUID——它得可预测生命周期，否则无法清理；推荐用base64(urlSafe)+timestamp拼接后哈希，或直接用time.Now().UnixMilli()作为jti前缀 - 如果用 Redis，避免单 key 大量写入瓶颈：按小时分片，例如 key 为
used_jti:2024052015，value 存 set 或 bitmap - ParseWithClaims 的 error 处理要区分
jwt.ValidationErrorExpired和自定义的 “jti 已使用” 错误，前者返回 401，后者应返回 403（防止暴露校验顺序）
真正容易被忽略的是：时间漂移会导致防重放失效——客户端时间快 2 分钟，服务端就可能误判“这个刚发的 token 是重放的旧包”，所以禁止用 iat 或 nbf 做防重放依据，所有时效判断统一走 Redis TTL。
