hmac-sha256更适合大多数api场景，rsa适合需强身份绑定的开放平台；hmac性能高但无法溯源，rsa可溯源但私钥泄露风险大；timestamp用秒级时间戳并校验±5分钟，nonce需随机且服务端去重缓存，签名原文须严格固定拼接顺序与大小写。
签名算法该用 HMAC-SHA256 还是 RSA？
防篡改校验本质是让接收方能确认请求没被中间人或恶意客户端修改过，核心靠「不可逆+密钥隔离」。HMAC-SHA256 更适合绝大多数内部服务间或客户端→后端的 API 场景；RSA 签名适合需要强身份绑定、且公钥可公开分发的场景（比如开放平台给第三方调用）。别一上来就上 RSA——私钥管理、验签开销、序列化格式（PKCS#1 v1.5 vs PSS）全是坑。
- HMAC 用
hmac.New+sha256.New，密钥直接参与计算，服务端和客户端必须共享同一份 secret（建议从环境变量读，别硬编码） - RSA 要求客户端用私钥签名、服务端用公钥验签，
rsa.SignPKCS1v15和rsa.VerifyPKCS1v15必须配对，错一个参数（比如 hash 类型传crypto.SHA1却用 SHA256 算摘要）就直接crypto/rsa: verification error - HMAC 性能高、实现简单，但无法证明“谁签的”；RSA 可溯源，但私钥一旦泄露，所有历史请求都可能被伪造
Header 里放 signature、timestamp、nonce 的正确姿势
这三个字段不是随便塞进 Authorization 或自定义 header 就完事。顺序、编码、有效期全影响安全性。
-
timestamp必须是秒级 Unix 时间戳（不是毫秒），服务端要校验 ±5 分钟偏移，避免重放攻击；别用time.Now().UnixMilli()，得用time.Now().Unix() -
nonce是一次性的随机字符串（推荐crypto/rand.Read生成 16 字节再 hex 编码），服务端需缓存最近 5 分钟内见过的 nonce 并去重，Redis TTL 设为 300 秒最稳妥 - 签名原文必须固定拼接顺序：比如
method + "\n" + path + "\n" + timestamp + "\n" + nonce + "\n" + body_hash，少一个换行或大小写不一致，签名就对不上
body_hash 怎么算才不会被前端/Postman 坑？
很多人卡在 body 签名校验失败，90% 是因为没处理好 body 的原始字节形态——HTTP body 可能被 gzip、被框架自动 JSON 格式化、被 Postman 自动加空格。
- 服务端验签时，
body_hash必须基于原始 request body 字节计算（用io.ReadAll(r.Body)一次读完），之后再用json.Unmarshal解析；别在解析后再拼字符串算 hash - 前端若发 JSON，必须保证无多余空格、换行、尾逗号；建议用
JSON.stringify(obj, null, 0)或后端统一用bytes.TrimSpace清掉首尾空白 - 如果 body 是 form-data 或文件上传，
body_hash应为空字符串或跳过（改用 query + header 组合签名），否则 multipart boundary 会随请求变化，hash 必然不稳
Go 标准库 http.Request 的 Header 读取陷阱
Go 的 Header.Get 对大小写不敏感，但签名原文里的 header key 必须和客户端发送的**原始 key 大小写完全一致**，否则验签失败。
立即学习“go语言免费学习笔记（深入）”；
- 客户端发
X-Signature，服务端就不能用r.Header.Get("x-signature")去取值参与签名计算——虽然能取到，但拼原文时 key 名错了 - 安全做法：遍历
r.Header的 map，用strings.EqualFold找 key，但拼签名原文时保留原始 key（比如从r.Header["X-Signature"]取第一个值，key 写死为"X-Signature"） - 更省事的是约定全部用小写 header（
x-signature,x-timestamp），客户端和服务端统一，避免大小写歧义
