Go中HMAC验证失败主因是输入不一致或比较错误：hmac.New需传哈希构造器（如sha256.New）而非实例；签名原文须严格对齐（空格、顺序、编码）；验签必须用hmac.Equal并先解码签名。
Go 里 HMAC 验证失败，90% 不是算法问题，而是输入没对齐或比较方式错了。
hmac.New 传错参数：sha256.New 还是 sha256.New()？
必须传哈希函数构造器，不是哈希实例。传错直接编译失败或 panic。
-
hmac.New(sha256.New, key)✅ 正确：sha256.New是类型为func() hash.Hash的函数指针 -
hmac.New(sha256.New(), key)❌ 错误：传的是hash.Hash实例，类型不匹配 - 同理，
sha512.New不能带括号；sha1.New已不安全，别用
签名原文必须一字不差：空格、顺序、编码全得对齐
服务端和客户端哪怕只差一个换行或 URL 编码方式不同，hmac.Equal 就会返回 false。
- query 参数必须字典序排序后拼接，别依赖
req.URL.RawQuery（顺序不可控） - body 参与签名时，统一用
sha256(bodyBytes).Sum(nil)算出body_hash字符串，避免空 body 和 nil body 差异 - 时间戳必须是秒级整数字符串：
time.Now().Unix()，不是毫秒，也不是"2006-01-02T15:04:05Z" - 路径只取
req.URL.Path，不含 query，也不补 trailing slash
验签必须用 hmac.Equal，且输入得是 []byte
手写 == 或 bytes.Equal 不仅逻辑错，还可能引入时序攻击。
立即学习“go语言免费学习笔记（深入）”；
-
hmac.Equal只接受[]byte，收到的 hex 或 base64 签名必须先解码：hex.DecodeString(sig)或base64.StdEncoding.DecodeString(sig) - 解码失败要提前返回
false，hex.DecodeString("xxx")出错返回nil，而hmac.Equal(nil, nil)返回true，造成校验绕过 - HTTP Header 里的签名（如
X-Signature）要先strings.TrimSpace去首尾空格再解码
密钥长度和环境差异最容易被忽略
本地能过、线上挂掉，往往不是代码问题，而是密钥或时区不一致。
- 密钥建议至少 32 字节，硬编码字符串（如
"my-key"）极不安全；推荐从环境变量加载 hex 或 base64 编码的随机密钥：[]byte(os.Getenv("HMAC_SECRET")) - CI/CD 环境和本地时区不同，会导致
timestamp字段值不一致——确认双方都用 UTC 时间计算秒级时间戳 -
hmac.Equal从 Go 1.3 起存在，但老旧镜像可能卡在 1.2；运行go version确认，再执行go mod tidy && go build刷新缓存
真正难的不是调通 hmac.New，而是让两端对“待签名数据”达成完全一致的共识——它不声不响，却决定整个验证链是否成立。
