签名验证必须在中间件中统一实现，不可分散至各路由处理函数；需从header提取签名、校验时间戳有效期（如±5分钟），失败时调用c.abortwithstatusjson(401, ...)终止流程。
签名验证必须在中间件里做，不能放路由处理函数中
因为签名验证是所有受保护接口的共性逻辑，如果每个 handler 都重复写一遍 verifySignature()，既容易漏校验，又难以统一更新密钥或算法。Gin 的中间件机制天然适合拦截请求、统一鉴权。
常见错误是把签名解析和校验逻辑直接塞进 c.JSON() 前面——这样一旦某个接口忘了调用校验函数，就彻底绕过安全检查。
- 签名字段应从
c.Request.URL.Query()或c.Request.Header中提取（取决于设计，但推荐 Header，避免 GET 参数被代理截断或日志泄露） - 时间戳必须校验有效期（如 ±5 分钟），否则重放攻击极易得手
- 中间件里校验失败必须调用
c.AbortWithStatusJSON(401, ...)，不能只return，否则后续 handler 仍会执行 - 建议在中间件开头就调用
c.Request.ParseForm()和c.Request.ParseMultipartForm(32 ，确保 <code>c.PostForm和c.MultipartForm可靠可用
签名原文拼接顺序必须严格约定，且排除非业务参数
签名原文不是简单把所有参数 JSON 序列化，而是按固定字段名升序（或按文档约定顺序）拼接键值对，并跳过签名本身、时间戳、随机串等非业务字段。顺序错一点，签名就完全不匹配。
典型错误是直接用 c.ShouldBind(&req) 后对结构体反射取值拼接——这依赖字段定义顺序，Go struct 字段无序，且无法控制是否包含 json:"-" 字段。
- 推荐做法：手动从
c.Request.Form（含 query + form）中取出白名单字段，按 key 字典序排序后拼成key1=value1&key2=value2格式 - value 必须做 URL 解码后再参与拼接（
url.QueryUnescape()），否则前端编码差异会导致签名不一致 - Body 是 JSON 时，需先
ioutil.ReadAll(c.Request.Body)，再重新写回c.Request.Body = io.NopCloser(bytes.NewReader(data))，否则后续c.ShouldBindJSON()会读空 - 不要对 value 做额外 trim 或类型转换（如把
"1"转成1），签名原文必须与客户端原始字符串完全一致
使用 HMAC-SHA256 而非 MD5 或纯 SHA256
md5 已不安全，sha256 无密钥易被碰撞伪造，hmac 是唯一合理选择。Gin 本身不提供加密工具，需直接用标准库 crypto/hmac。
容易忽略的是密钥管理方式：硬编码在代码里、从环境变量读、还是对接 KMS？生产环境必须避免明文写死密钥。
- 签名生成示例：
h := hmac.New(sha256.New, []byte(secretKey)) h.Write([]byte(signingString)) signature := hex.EncodeToString(h.Sum(nil))
- 注意：
secretKey长度建议 ≥32 字节，过短会削弱 HMAC 安全性 - 客户端和服务端必须使用完全相同的
signingString构造逻辑，建议将拼接逻辑封装为独立函数并两端共用伪代码文档 - 别在签名中加入 IP、User-Agent 等易变字段——它们不属于业务上下文，反而增加失败率
调试阶段务必开启签名原文日志，但上线前必须关闭
签名不通过时，最有效的排查方式是比对服务端计算出的 signingString 和客户端声称的原文是否一致。但这个字符串含所有业务参数，属于敏感数据。
很多团队在线上开着 fmt.Printf("signingString: %s\n", s)，结果日志被同步到 ELK，造成批量参数泄露。
- 开发期可在中间件中加条件日志：
if gin.Mode() == gin.DebugMode { log.Printf("signingString: %s", s) } - 禁止记录原始密钥、完整 token、密码类字段，哪怕是在 debug 日志里
- 上线前全局搜索
signingString、rawPayload、debugSign等关键词，确保无残留 - 更稳妥的做法是写个单元测试，用已知参数+密钥生成签名，再用服务端逻辑反向验证，覆盖各种边界 case
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
