go语言中hmac.new校验失败的主因是未调用sum(nil)获取最终摘要、密钥未显式转为[]byte、哈希构造器传参错误（如sha256.new而非sha256.new()）、签名前原文未标准化及重复使用hmac实例未reset。
Go 语言标准库 crypto/hmac 已经提供了完整的 HMAC 实现，不需要第三方包，但直接调用 hmac.New 容易因哈希函数选择、密钥类型、字节处理不一致导致签名不匹配——这是绝大多数“签名验签失败”的根源。
hmac.New 返回值必须显式调用 Sum 或 Sum(nil) 才能获取最终摘要
很多人误以为 hmac.Write 后直接 h.Sum([]byte{}) 就完事了，其实 h.Sum 是追加操作；若重复调用且未重置，会累积上一次结果。更常见的是忘记调用 Sum，只用了 h.Sum(nil) 但没接返回值，导致变量为空。
-
h.Sum(nil)返回新分配的[]byte，不是原h的内部缓冲区 - 如果需要十六进制字符串，应写成
hex.EncodeToString(h.Sum(nil))，而不是hex.EncodeToString(h.Sum([]byte{}))（后者语义等价但冗余） - 每次签名后，
h不会自动重置；如需复用h，必须调用h.Reset()并重新h.Write()
SHA256 和 SHA1 的 hmac.New 参数类型不同，不能混用
hmac.New 第一个参数是哈希构造函数，比如 sha256.New 或 sha1.New，它们类型都是 func() hash.Hash，但返回的 hash.Hash 底层结构不同。密钥长度也影响安全性：SHA256 要求密钥至少 32 字节才安全，而 SHA1 对短密钥容忍度略高，但已不推荐。
- 用
sha256.New时，密钥建议用[]byte直接传入，避免字符串隐式转码带来的空格/编码差异 - 若密钥是 hex 字符串（如
"a1b2c3..."），必须先hex.DecodeString(keyHex)，不能直接[]byte(keyHex) - 错误示例：
hmac.New(sha1.New, []byte("key"))和hmac.New(sha256.New, []byte("key"))签名结果完全不同，服务端若约定 SHA256 却用了 SHA1，必然验签失败
签名字符串拼接顺序和编码方式必须和服务端严格一致
HMAC 本身不关心内容格式，但签名前的原始数据（canonical string）怎么拼、是否 URL 编码、字段是否排序、换行符用 \n 还是 \r\n，这些细节出一点差错，签名就对不上。
- 常见陷阱：Go 的
url.Values.Encode()会做 URL 编码，但有些 API 要求「不编码的原始参数字符串」再签名 - 时间戳字段若用
time.Now().Unix()，注意是否要求秒级还是毫秒级；是否要四舍五入或截断 - 推荐做法：把待签名字符串先用
fmt.Sprintf或strings.Join显式拼成一行，打印出来和文档对照；用hex.Dump([]byte(s))查看实际字节，确认无不可见字符
最常被忽略的其实是密钥的编码一致性——服务端用 UTF-8 解析密钥，而你用系统默认编码（比如 Windows 上的 GBK）读取配置文件，哪怕内容看起来一样，字节也不同。签名这东西，差一个字节就全错。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
