md5本身无密钥，无法防篡改和重放；必须使用带密钥的hmac-md5或更安全的hmac-sha256，且需严格统一原始数据序列化规则、编码和拼接顺序。
为什么不能直接校验客户端传来的 MD5 签名
MD5 本身不是签名算法，它不带密钥，客户端算出的 MD5("data") 服务端也能随便重放或篡改——这根本防不住中间人。真正需要的是「带密钥的摘要」，比如 HMAC-MD5 或更推荐的 HMAC-SHA256。如果你看到文档写“MD5 签名”，大概率是历史叫法，实际指 HMAC-MD5，或者用拼接密钥再 MD5（md5(data + secret)），后者虽不标准但常见于老系统。
在 Gin 中提取并验证 HMAC-MD5 签名的典型流程
假设客户端按约定把签名放在请求头 X-Signature，原始数据在 JSON body 中，密钥由服务端保管：
- 先用
c.ShouldBindJSON(&req)解析 body，但别急着校验——body 只能读一次，得先缓存原始字节 - 用
c.Request.Body读取并保存为[]byte，再用io.NopCloser重置回 request body，否则后续绑定会失败 - 用
hmac.New(md5.New, []byte("your-secret"))构造 HMAC，写入缓存的字节，得到期望签名 - 用
hex.EncodeToString()转成小写字符串，与请求头里的X-Signature严格比对（注意大小写）
示例关键片段：
body, _ := io.ReadAll(c.Request.Body)
c.Request.Body = io.NopCloser(bytes.NewBuffer(body))
var req MyRequest
if err := c.ShouldBindJSON(&req); err != nil {
c.AbortWithStatusJSON(400, gin.H{"error": "invalid json"})
return
}
h := hmac.New(md5.New, []byte("my-key"))
h.Write(body)
expected := hex.EncodeToString(h.Sum(nil))
if !hmac.Equal([]byte(expected), []byte(c.GetHeader("X-Signature"))) {
c.AbortWithStatusJSON(401, gin.H{"error": "signature mismatch"})
return
}
用拼接密钥 MD5 的方式（兼容旧接口）要注意什么
如果协议明确要求 md5(data + secret)（无 HMAC），必须保证拼接顺序、编码和大小写完全一致：
- 客户端若用 UTF-8 编码 body 后拼接密钥，服务端也必须用 UTF-8；若客户端用了
JSON.stringify默认格式（无空格），服务端就不能用json.MarshalIndent - MD5 输出是 16 字节二进制，必须转成 32 位十六进制字符串，且全部小写（
strings.ToLower(hex.EncodeToString())） - 签名头里如果带
MD5=xxx前缀，记得先截掉再比对 - 这种拼接方式无法抵御长度扩展攻击，仅限内网或低风险场景，切勿用于支付类接口
Gin 中全局签名中间件的坑
想统一加签名校验？别直接在中间件里调 c.ShouldBindJSON——它会消费 body，导致下游 handler 绑定失败。正确做法是：
- 中间件只做签名校验，用
io.ReadAll+io.NopCloser处理 body - 校验失败直接
c.Abort()并返回错误，别继续走后续 handler - 校验成功后，把原始 body 字节存到
c.Set("raw-body", body)，下游 handler 如需再次解析可复用 - 避免在中间件里解析结构体，除非你确定所有路由都用同一套 schema
签名逻辑一旦涉及时间戳、随机数（nonce）、请求路径等上下文，就一定要从 c.Request 和 c.Param 等地方实时取，不能依赖绑定后的结构体字段——因为字段可能被忽略或重命名。
真正难的不是算 MD5，而是确认客户端和你用的是同一套原始数据序列化规则、同一套密钥注入时机、同一个编码前提。线上出问题，八成卡在空格、换行、时间格式或 URL decode 上。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
