HMAC 签名怎么生成？API 鉴权、密钥、SHA-256 和验签指南

很多开放 API 会要求请求签名，HMAC 是常见方案。它使用共享密钥和消息内容计算签名，服务端用同样方式验证。

你可以用 HMAC 签名生成器 测试签名结果。

HMAC 解决什么

HMAC 可以帮助验证：

• 请求内容没有被改。
• 调用方知道共享密钥。
• 签名字段和服务端规则一致。

它不负责加密内容。请求体仍然可能被看到，所以传输层还需要 HTTPS。

签名内容必须一致

常见错误是前后端签名字符串不一致：

• 参数顺序不同。
• 多了空格或换行。
• URL 编码规则不同。
• 时间戳格式不同。
• JSON 序列化结果不同。

验签失败时，先打印待签名原文，而不是只看最终签名。

密钥要保密

HMAC 密钥不能放在前端代码里。浏览器里的代码用户都能看到，密钥应该只在服务端保存。

测试时可以用工具生成签名，生产系统要在后端实现。

调试时先固定样本

接口签名问题最好先准备一组固定样本：固定密钥、固定时间戳、固定请求体、固定参数顺序。前后端都用这组样本计算，结果一致后再接入真实请求。否则每次时间戳都变，很难判断到底是算法错还是数据错。

如果服务端要求把 method、path、query、body、timestamp 拼在一起，文档里必须写清分隔符和编码规则。空字符串是否参与签名、JSON 字段顺序是否稳定、中文是否先编码，都要统一。

防重放也要考虑

HMAC 只能证明请求知道密钥和内容没有变，不能天然阻止别人复制同一条请求重复发送。实际 API 往往还会加入时间戳、nonce 或请求 ID，并在服务端设置有效期和去重逻辑。

错误信息要收敛

生产环境里不要把密钥、完整待签名字符串或服务端计算出的签名直接返回给调用方。调试环境可以详细记录，正式环境只返回统一的签名失败原因，并在服务端日志里保留足够排查的信息。

总结

HMAC 是 API 签名常用方案，重点是密钥保密和待签名字符串完全一致。

调试签名时，可以用 HMAC 签名生成器 对照服务端结果，逐项排查编码、排序和换行。