url.Values.Encode()不能用于签名参数拼接，因为它不保证键的字典序，且编码行为（如空格转+）与签名要求（空格应为%20）不一致；正确做法是手动解析RawQuery、剔除签名字段、按键字典序排序、对key和value分别调用url.PathEscape后拼接。
为什么 url.Values.Encode() 不能直接用于签名参数拼接
它不保证键的字典序，且对空值、+、/、中文等字符的编码行为与标准签名要求不一致——比如 url.QueryEscape 把空格转成 +，但多数服务端要求空格是 %20；而 url.PathEscape 才符合签名规范。
正确做法是手动提取所有 query 参数（从 r.URL.RawQuery 解析），剔除 sign、signature 等签名字段，按键名做字典序排序，再对每个 key 和 value 单独调用 url.PathEscape，最后用 key=value 格式拼接，& 连接。
- 别用
r.FormValue()或r.URL.Query()—— 它们会自动 decode，破坏原始编码一致性 - 必须在服务端也用相同逻辑解析 query，否则客户端和服务端拼出的字符串必然不同
- 如果请求同时带 query 和 JSON body，需约定：query 参数参与排序拼接，body 先算
sha256.Sum256(bodyBytes).Sum(nil)再 hex 编码后作为固定字段加入拼接串
并发场景下 hmac.Hash 实例不能复用
有人把 hmac.Hash 对象缓存起来，在多个 goroutine 中反复 Reset() + Write()，结果签名串货——因为 hmac.Hash 不是线程安全的，Reset() 并不会清掉内部状态缓冲区。
每次签名都应新建 hasher：
立即学习“go语言免费学习笔记（深入）”；
h := hmac.New(sha256.New, secretKeyBytes) h.Write([]byte(signingString)) signature := hex.EncodeToString(h.Sum(nil))
-
secretKeyBytes必须是预解码好的[]byte，不是每次调用都[]byte(secret) - 别用
h.Sum()字段——它是内部缓冲区引用，可能含旧数据；必须用h.Sum(nil)或h.Sum([]byte{}) - 如果性能敏感，可用
sync.Pool缓存hmac.Hash实例，但必须确保每个实例只被一个 goroutine 使用，且每次使用前Reset()后完整Write()
时间戳和 nonce 的校验必须独立于签名比对
只验证 signature 值相等就放行，等于没加防篡改——攻击者截获一次请求，改参数重发，只要时间戳和 nonce 没过期，签名依然有效。
服务端必须做三件事：
- 解析
X-Timestamp头（或 query 参数），确认是纯数字字符串，再转为int64；用abs(now.Unix() - ts)判断是否 ≤ 300 秒，别只做ts > now.Unix() - 300 - nonce 需存 Redis，key 形如
api:nonce:fmt.Sprintf("%d:%s", ts, nonce)，TTL 设为 305 秒（窗口 300 秒 + 5 秒冗余） - 若用多实例部署，绝不能用内存 map 做 nonce 去重——扩容后新实例无法感知旧 nonce
常见错误：客户端传毫秒级时间戳（time.Now().UnixMilli()），服务端却按秒解析，导致永远校验失败。
调试时最该打印的是 signingString 而不是 signature
当本地签名和线上验签结果不一致，90% 的问题出在拼接逻辑差异：大小写、换行符、空格、URL 编码方式、字段剔除范围。此时打印最终 signature 没用，因为两端哈希输出都是黑盒；真正需要对比的是原始待签字符串。
建议在开发阶段开启 debug 日志：
log.Printf("signing string: %q", signingString)- 确保客户端和服务端都打印同一格式的
signingString，逐字符比对 - 注意
signingString中的分隔符：是\n还是&？是否含末尾换行？大小写是否严格一致？ - 如果用
method + "\n" + path + "\n" + timestamp + "\n" + nonce + "\n" + queryStr，那每段都不能多也不能少一个\n
一旦 signingString 对齐，signature 自然一致——HMAC 本身没有玄学。
