Go语言中字符串的对称签名：基于HMAC-SHA256的字符串完整性校验-Golang-PHP中文网

直接用hmac.new校验失败是因为未调用sum(nil)获取最终摘要，而使用中间状态字节；且key必须为[]byte类型，字符串需显式转换，否则可能因地址误用导致不可预测行为。

go语言中字符串的对称签名：基于hmac-sha256的字符串完整性校验

为什么直接用 `hmac.New` 会校验失败？

Go 的 hmac.New 默认使用的是哈希的“写入式”接口，它内部维护一个未完成的哈希状态；如果你在签名后没调用 Sum 或 Sum(nil)，拿到的只是中间状态字节，不是最终摘要。更隐蔽的问题是：Sum 返回的切片可能复用底层底层数组，若后续修改原 hmac 实例（比如再写一次），旧结果可能被意外覆盖。

务必用 sum := mac.Sum(nil) 获取完整、独立的字节切片
不要用 mac.Sum(sumBuf[:0]) 这类复用缓冲区的方式，除非你明确控制生命周期
签名前确保 key 是 []byte 类型，字符串需显式转为 []byte(key)，否则 HMAC 会把字符串地址当 key（极小概率触发不可预测行为）

如何安全地编码和传输签名？

HMAC 输出是原始字节（32 字节 SHA256），不能直接拼进 URL 或 JSON。常见错误是用 string(sig) 强转——这会产生乱码甚至截断（遇到 \x00 就终止）。必须编码成可传输格式。

Go语言（Golang）1.26.0

Go语言（Golang）1.26.0版本官方下载，版本号 1.26.0，适合旧项目维护、兼容性测试和指定版本开发环境搭建。

下载

推荐用 base64.StdEncoding.EncodeToString(sig)：标准 Base64，URL 安全性一般但兼容性最好
如用于 URL 查询参数，改用 base64.URLEncoding.EncodeToString(sig)，避免 + 和 /
切忌用 hex 编码（fmt.Sprintf("%x", sig)）：长度翻倍，传输开销大，且易因大小写不一致导致校验失败

校验时怎么避免时序攻击？

直接用 == 比较两个签名会暴露时间差异：从左到右逐字节比，第一个不同就返回，攻击者可通过响应延迟反推签名内容。Go 标准库提供了常量时间比较函数。

用 hmac.Equal(gotSig, expectedSig)，而非 gotSig == expectedSig
注意：hmac.Equal 要求两个参数都是 []byte；如果签名是 Base64 字符串，先用 base64.DecodeString 解码，再比较
解码失败（如非法 Base64）应统一返回 “校验失败”，不要区分 “解码错” 和 “签名错”，防止信息泄露

字符串预处理是否必要？

对称签名只保证“给定输入 + 给定 key”的输出唯一，但不解决语义歧义。例如 "a=1&b=2" 和 "b=2&a=1" 若未经标准化，签名必然不同，哪怕逻辑等价。

若签名对象是查询参数，应在签名前做排序+编码标准化（类似 OAuth 1.0a 的 signature base string）
若只是纯文本（如日志行、配置项值），无需额外处理，但必须约定是否保留首尾空格、换行符
特别注意：JSON 字符串签名前，应使用 json.Marshal 得到确定格式（而非 fmt.Sprintf），因为字段顺序、空格、键名引号都影响字节流

实际中最容易被忽略的，是签名与校验两端对原始字符串的“字节级一致性”——哪怕多一个空格、少一个换行、编码不一致（UTF-8 vs GBK），HMAC 就完全失效。别依赖“看起来一样”。