HMAC 签名
HMAC 签名计算：选 SHA-1/256/384/512，输入密钥与消息，WebCrypto 本地计算，输出 hex / base64。
>_ 使用指南 · GUIDE
选择哈希算法（SHA-1 / SHA-256 / SHA-384 / SHA-512），填入密钥（Key）与消息（Message），本工具通过浏览器 WebCrypto 在本地实时计算 HMAC 签名，输出 hex 或 base64 两种格式，点一下即可复制。
HMAC（Hash-based Message Authentication Code）是一种带密钥的哈希：它把密钥和消息按固定方式混合后做多次哈希，所以不同于裸哈希，不知道密钥的人无法伪造出同样的签名。常见用途是接口签名——客户端用共享密钥对请求参数算 HMAC，服务端用同样密钥重算并比对，能同时验证「消息没被篡改」和「请求确实来自持有密钥的一方」。
典型步骤：
- 选算法：按服务端约定选择 SHA-256 等哈希
- 填密钥与消息：输入双方共享的密钥和待签名的消息（参数串、时间戳等）
- 选输出格式：hex（十六进制）或 base64，与服务端校验逻辑一致即可
- 复制比对：把结果与服务端要求或参考实现的结果对照，一致即通过
密钥与消息都在浏览器本地计算，不出设备，可以放心处理签名对接时的敏感参数。
>_ 常见问题 · FAQ
Q1 · HMAC 和普通哈希（如 MD5、SHA-256）有什么区别？
普通哈希只对消息本身做摘要，任何人算出的值都一样，可用来校验完整性，但无法区分是谁算的；HMAC 在此基础上混入了只有双方知道的密钥，同一消息不同密钥会得到不同签名。所以 HMAC 能同时提供完整性校验和身份认证（防伪造），接口签名通常用 HMAC 而非裸哈希。
Q2 · HMAC 输出为什么要分 hex 和 base64？
同一个摘要值可以用不同编码表示：hex 是把字节写成两位十六进制（长但常见），base64 更紧凑。选哪种取决于服务端校验时用的编码——两边必须一致才能比对通过。多数约定会写清「HMAC-SHA256，hex 小写」之类，照此选择即可。
Q3 · HMAC 的密钥怎么选才安全？
密钥应足够长且随机，理想是与哈希输出等长甚至更长（如 SHA-256 用 ≥32 字节随机串）；绝不能把密码、用户名这类可猜测值当密钥。密钥只在客户端与服务端间共享、走安全通道（如 TLS）分发，工具本身不存储密钥，关闭即无残留。
Q4 · HMAC 能用来替代加密吗？
不能。HMAC 是「认证」不是「加密」——它不隐藏消息内容，只证明消息完整且来自持密钥方。需要同时保密内容，应使用对称加密或 HTTPS；HMAC 通常与加密配合（先加密再签名）用于接口鉴权防篡改场景。
Q5 · 为什么我在网上算的 HMAC 结果对不上？
HMAC 要求消息逐字节一致，最常见的坑是：① 密钥的编码解读不一致——本工具支持把密钥按 UTF-8 文本、hex、base64 三种方式解读（密钥区可切换），第三方支付回调等场景常使用 hex 密钥，双方解读不同结果必然对不上，这是第一排查项；② 密钥/消息里有看不见的空格或换行没去掉；③ 消息拼接顺序与约定不符（如参数要先排序再拼）；④ 输出 hex 大小写或 base64 变体差异。逐项核对后通常就能对上。