签名验证必须在网关层做，因微服务架构下各服务重复验签会导致密钥分散、逻辑不一致、非核心服务易漏校验；网关统一拦截所有敏感请求，用HMAC-SHA256验签，结合timestamp±300秒校验与nonce+Redis去重防重放，并安全复用request.Body。
签名验证为什么必须在网关层做
微服务架构下，如果每个服务都自己验签，会导致密钥管理分散、逻辑重复、且容易漏掉非核心服务（比如文件上传服务）的校验。真正该验签的位置是统一入口——API 网关或反向代理层。Go 生态里常用 gin 或 echo 做轻量网关，此时验签应作为中间件，在请求进入业务路由前完成。
常见错误是把验签逻辑写进某个具体服务的 handler 里，结果新接入的服务忘了加，或者前端绕过网关直连后端，签名形同虚设。
- 验签中间件必须拦截所有
POST/PUT/DELETE请求（GET一般不签名，除非含敏感参数） - 密钥不能硬编码，建议从环境变量或 Vault 加载，且不同环境用不同密钥
- 时间戳校验窗口建议设为
300秒（5 分钟），太长易被重放，太短对时钟漂移敏感
签名算法选 HMAC-SHA256 而不是 MD5 或 RSA
MD5 已被证明不安全，RSA 签名开销大、密钥管理复杂，而 HMAC-SHA256 在 Go 标准库中支持完善、性能好、且足够防篡改。签名原文格式要固定：按字母序拼接所有非空业务参数 + 时间戳 timestamp + 随机串 nonce，再拼上密钥。
注意：参数必须先 URL 解码再参与签名计算，否则前端 encode 后传过来的 %20 和后端 decode 后的空格会不一致。
立即学习“go语言免费学习笔记（深入）”；
- 签名字符串模板：
method|path|timestamp|nonce|sorted_query_string|body_hash（body_hash是 POST/PUT 的 SHA256(body)） - 务必忽略签名字段本身（如
sign或signature）参与计算，否则前端无法预生成 - Go 中用
hmac.New+sha256.New，别用crypto/md5或第三方封装不明的 hash 包
时间戳和 nonce 必须联合校验防重放
只校验时间戳不够——攻击者截获一个有效请求，在 5 分钟内重放，系统仍会接受。必须配合 nonce（一次性的随机字符串）+ Redis 去重（或本地 LRU cache，仅限单机场景）。
常见坑是把 nonce 存在内存 map 里，没设 TTL 或没做分布式清理，导致缓存爆炸或集群节点间不一致。
-
nonce建议用crypto/rand.Read生成 16 字节 base64，长度够、无特殊字符 - Redis key 设为
nonce:{value}，TTL = 时间窗口上限（如 300 秒），值可设为空或时间戳 - 校验顺序必须是：先查 nonce 是否已存在 → 再校验时间戳是否超窗 → 最后验签名。顺序错会导致逻辑绕过
Go 中如何安全读取并复用 request.Body
验签需要读 body，但后续业务 handler 还要读一遍，而 http.Request.Body 是一次性流。直接 ioutil.ReadAll 会导致后续读不到内容，必须用 io.TeeReader 或重写 Body 字段。
最稳妥的做法是：读完 body 后，用 bytes.NewReader 替换原 Body，并设置 ContentLength，否则某些中间件（如 gin 的 binding）会出错。
- 别用
r.Body = ioutil.NopCloser(bytes.NewReader(buf))就完事——漏设r.ContentLength = int64(len(buf))会导致 multipart 解析失败 - 如果 body 很大（>1MB），避免全量加载到内存，改用 streaming HMAC 计算（
hash.Hash.Write接io.TeeReader） - 对于
application/json，可提前解析成map[string]interface{}并排序键名，但注意浮点数精度、null 值序列化差异等边界
