最稳妥选择是Go标准库的crypto/hmac+crypto/sha256；禁用MD5/SHA-1；密钥须私有二进制且安全加载；参数排序拼接须严格一致；timestamp须校验偏差≤300秒；错误响应不暴露签名细节。
签名验证该用哪个哈希算法
Go 标准库的
+
是最稳妥的选择。别碰
或
，哪怕只是内部系统——它们已被证明可碰撞，攻击者能伪造合法签名。
SHA-256 足够快、足够安全，且
支持任意字节密钥，不强制要求固定长度。密钥必须是服务端私有、不参与传输的二进制数据（比如从环境变量读取的 32 字节随机值），绝不能硬编码在代码里或用明文字符串拼接。
错误做法：
—— SHA-1 已过时
错误做法：
—— 若环境变量含 Unicode 或换行，
会静默截断或引入不可见字符
正确做法：用
解码预设的 base64 密钥，确保字节精确
参数排序和拼接规则必须严格一致
签名失效最常见的原因是「客户端和服务端对参数排序逻辑不一致」。不是按 key 字典序就行——要排除签名字段本身（如
）、过滤空值、统一编码（URL decode 后再排序）、小写 key（有些 SDK 默认转小写）。
推荐固定流程：提取所有 query/form 参数 → 删除
键 → 对每个 value 做
（注意：不是
）→ 按 key 升序排列 → 拼成
形式（无空格、无换行、无结尾 &）。
立即学习
“
go语言免费学习笔记（深入）
”；
坑点：
会自动排序并 escape，但默认包含
；必须先
再 encode
坑点：前端 JS 的
和 Go 的
行为基本一致，但若前端用了
（不编码
），签名必错
建议：把拼接逻辑封装成独立函数，客户端和服务端共用同一份 spec 文档，而非各自实现
时间戳校验不能只 check 是否存在
签名里带
不是为了“有”，而是为了防重放。只判断
字段非空毫无意义。
必须做两件事：解析为
（用
或
，注意时区！推荐全用 Unix 时间戳秒级整数）→ 和服务器当前时间比对，偏差超过 300 秒（5 分钟）直接拒绝。不要用
算 duration，避免跨时区解析错误。
常见错误：
—— 忽略解析失败，
吞掉错误导致永远通过
更糟错误：用
但客户端发的是毫秒时间戳，类型错配
务实做法：约定 timestamp 必须是秒级 Unix 时间戳（int64 字符串），服务端用
，失败即拒
签名验证失败时别暴露细节
返回
或
都可以，但响应体里绝不能写
、
这类信息。攻击者靠这些提示能快速试出密钥长度、时间偏差、甚至参数排序规则。
统一返回模糊错误，比如
，日志里才记具体原因（如
）。
特别注意：开发环境开启详细错误没问题，但上线前必须关掉所有
、
在 handler 中打印签名相关中间值
别在 HTTP Header 里加
—— 即使是内网，Header 也可能被代理、CDN 缓存或意外泄露
真正难的是密钥轮换：旧密钥要保留一个窗口期（比如 2 小时），新请求用新密钥签，旧请求仍可用旧密钥验——这个逻辑很容易漏测
crypto/hmaccrypto/sha256md5sha1hmac.Newhmac.New(sha1.New, []byte("my-key"))hmac.New(sha256.New, []byte(os.Getenv("SECRET")))[]bytebase64.StdEncoding.DecodeStringsignsignurl.QueryEscapeurl.PathEscapekey1=value1&key2=value2url.Values.Encode()sign=xxxdel("sign")encodeURIComponenturl.QueryEscapeencodeURI/ ? : @ & = + $ , #timestamptimestamptime.Timetime.Unixtime.Parsetime.Now().Sub(t)if t, _ := strconv.ParseInt(req.FormValue("timestamp"), 10, 64); time.Now().Unix()-t > 300_time.Parse("2006-01-02T15:04:05Z", ts)strconv.ParseInt(v, 10, 64)401 Unauthorized400 Bad Request"signature mismatch""timestamp expired"{"code": 4001, "msg": "invalid request"}verify_sign: hmac mismatch for path=/api/pay, ts=1712345678fmt.Printflog.PrintlnX-Debug-Sign-Reason