应使用 crypto/hmac 与 crypto/sha256 组合，通过 hmac.New(sha256.New, []byte(secretKey)) 构造带密钥哈希器，禁用字符串拼接哈希以防长度扩展攻击。
签名验证该用哪个标准库函数
Go 标准库里没有“开箱即用”的签名防篡改中间件，但 crypto/hmac 和 crypto/sha256 组合就能满足绝大多数场景——别去搜第三方签名库，除非你明确需要 RSA 或 ECDSA 等非对称方案。
常见错误是直接拼接字符串再哈希（sha256.Sum256([]byte(s + key))），这存在长度扩展攻击风险；正确做法必须用 hmac.New 构造带密钥的哈希器。
- 对称签名选
hmac.New(sha256.New, []byte(secretKey))，密钥长度建议 ≥ 32 字节 - 避免硬编码密钥，从环境变量或配置文件读取，且确保不被日志打印（比如别在
fmt.Printf里输出secretKey） - 如果模块要兼容旧系统，注意 Go 1.19+ 的
hmac.Equal是常数时间比较，务必用它校验签名，而不是==
如何设计签名 payload 结构才不容易出错
签名对象不是“整个请求体”，而是结构化、可复现的字节序列。很多人把 json.Marshal(req) 直接喂给 HMAC，结果因字段顺序、空值处理、浮点精度导致签名不一致。
推荐固定格式：按字段名 ASCII 升序拼接 key=value，用换行符分隔，末尾不加换行。例如：
立即学习“go语言免费学习笔记（深入）”；
content=hello timestamp=1717023456 version=v1
这样能规避 JSON 序列化差异，也方便其他语言对接。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 必须包含
timestamp字段，并在验证时检查是否超时（如 ±30 秒），防止重放攻击 - 禁止包含敏感字段（如
password、token）进签名计算，否则泄露风险翻倍 - 如果 payload 含二进制数据（如图片 base64），先做标准化处理（比如统一转小写、去掉空白），再参与签名
HTTP 请求里签名头怎么传和验
别发明新 header 名，用业界通用的 X-Signature 或 Authorization: HMAC-SHA256 ...。关键是服务端必须在读取 body 前完成签名验证——否则中间件可能被绕过。
典型坑：用 http.Request.Body 读一次后，后续 handler 再读就是空的。得用 io.TeeReader 或提前缓存 body。
- 签名头值格式建议为：
sha256=<hex-digest>,t=<timestamp>,k=<key-id></key-id></timestamp></hex-digest>（k用于多密钥轮换） - 验证失败时，统一返回
http.StatusUnauthorized，不要暴露是签名错还是超时——避免信息泄露 - 如果模块要支持多个 API 路径不同密钥，用路由前缀映射密钥，别靠 runtime 判断 path 字符串
测试签名逻辑最容易漏掉的边界
本地跑通不代表线上安全。真实环境里，Nginx 可能自动解码 URL 编码、Cloudflare 会改写 header 大小写、客户端 SDK 可能默认 trim 空格——这些都会让签名对不上。
最有效的测试方式：写一个最小闭环，用 net/http/httptest 模拟完整链路，手动构造原始字节流，不经过任何 JSON marshal/unmarshal。
- 测试用例必须覆盖：URL 编码参数（如
q=a%20b）、header 名大小写混合（X-Timestampvsx-timestamp）、空字段是否参与签名 - 用
go test -v -run=TestSignVerify单独跑签名测试，避免被其他逻辑干扰 - 上线前用 curl 手动构造一次请求，对比服务端 log 里解析出的 payload 字节和本地计算的 digest —— 这步能发现 80% 的集成问题
密钥管理、时间同步、header 处理顺序，这三个点任何一个没对齐，签名就失效。别假设“两边都用 Go 就一定一致”。
