签名验证必须在HTTP中间件中统一拦截并早返回，严禁放入业务逻辑；需校验时间窗口、使用HMAC-SHA256算法、正确拼接canonical string、妥善处理空body，并确保密钥安全与可轮换。
签名验证必须在 HTTP 中间件里做，不能放业务逻辑里
签名验证是请求进入业务前的守门人，一旦放到 handler 里，意味着非法请求已经触发了日志、DB 查询甚至下游调用。Gin 或 Echo 的中间件能统一拦截所有路由，且天然支持 early return。
常见错误是把 verifySignature 写成普通函数，在每个 handler 开头手动调用——漏掉一个接口就等于开后门。
- 中间件里用
c.Abort()阻断非法请求，返回 401 或 403 - 验证失败时，不要记录完整请求体（含敏感参数），只记 method、path、timestamp、sign
- 务必校验
X-Timestamp是否在允许窗口内（如 ±5 分钟），防止重放攻击
签名算法要用 HMAC-SHA256，密钥绝不硬编码
MD5 或 SHA1 已不安全，HMAC-SHA256 是当前微服务间签名的事实标准。密钥必须从环境变量或 secret manager 加载，且不同服务实例应使用不同密钥（避免单点泄露全盘崩）。
签名原文拼接顺序极易出错：不是简单把 query + body 拼一起，而是按固定规则生成 canonical string。
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 先提取所有非空 query 参数，按 key 字典序排序，
url.Values.Encode()编码 - body 必须是原始字节（
c.Request.Body只能读一次！需用io.TeeReader或bytes.Buffer缓存） - 拼接格式：
method\npath\nquery_string\nbody_hash，其中body_hash是sha256(body_bytes)的 hex 小写字符串
客户端时间偏差会导致签名失效，服务端要容忍时钟漂移
微服务部署在不同机器上，NTP 同步总有毫秒级误差；移动端更可能有分钟级偏差。若服务端严格校验 X-Timestamp 等于 time.Now().Unix()，大量合法请求会 401。
正确做法是把时间窗口设为可配置（如 SIGN_EXPIRE_SECONDS=300），并用 time.Unix(timestamp, 0).Before(time.Now().Add(5 * time.Minute)) 做双向判断。
- 拒绝
timestamp超过当前时间 +5 分钟的请求（防未来时间伪造） - 拒绝
timestamp早于当前时间 -5 分钟的请求（防重放） - 该窗口值需与客户端协商一致，且上线前压测验证边界场景
Body 为空时签名计算容易漏判，必须显式处理
GET 请求无 body，但 POST/PUT 的空 body（如 {} 或纯空字符串）和 nil body 在 Go 里表现不同：c.Request.Body == nil 和 io.ReadAll(c.Request.Body) 返回空 slice 都要区分。
若忽略此点，同一请求在客户端发两次（一次带空 body，一次不带 body），服务端可能算出两个不同签名，导致偶发验证失败。
- 统一将 nil body 视为
[]byte("") - 对空 JSON body（
len(bodyBytes) == 2 && string(bodyBytes) == "{}"）不做特殊处理，按原始字节参与签名 - 调试时打印
fmt.Printf("body len: %d, hex: %x\n", len(bodyBytes), bodyBytes)能快速定位差异
签名验证本身不复杂，难的是在高并发下保持 body 可读性、时间窗口不被绕过、以及密钥轮换时不中断线上流量。这些细节没对齐，再标准的算法也形同虚设。
