⚠️ 签名结果对每一个字节都敏感：多一个空格、换行是 \n 还是 \r\n、字段拼接顺序，都会导致签名对不上。
选哪个主要看对接方要求，安全性上 SHA-256 及以上都没问题。
| 算法 | 输出长度 | 安全性 | 常见使用场景 |
|---|---|---|---|
| HMAC-SHA-1 | 20 字节 / 40 位 Hex | ⚠️ 已不推荐 | 老系统、部分云厂商旧版 API |
| HMAC-SHA-256 | 32 字节 / 64 位 Hex | ✅ 推荐 | 绝大多数接口签名、JWT HS256 |
| HMAC-SHA-384 | 48 字节 / 96 位 Hex | ✅ 推荐 | JWT HS384、合规要求较高的场景 |
| HMAC-SHA-512 | 64 字节 / 128 位 Hex | ✅ 推荐 | JWT HS512、对长度不敏感的场景 |
⚠️ 使用提示：① 不要把生产环境的真实密钥粘贴进任何网页（包括本工具）——调试请用测试密钥；② 签名不一致时，先查这几处：消息是否多了/少了空格与换行、换行是 \n 还是 \r\n、字段拼接顺序、密钥是文本还是 Hex 解码后、输出是 Hex 还是 Base64；③ HMAC 是对称的：签名方和验签方用的是同一个密钥，密钥泄露等于签名可被伪造；④ 涉及时间戳的接口要注意时钟偏差，本地时间不准会导致验签失败；⑤ 本工具只在浏览器内计算，不保存密钥、不记录消息，但浏览器插件、企业管控软件仍可能读取页面内容，敏感场景请离线处理。
对接第三方接口、调 Webhook、验签调不通——最折磨人的不是算法，而是「我算出来的和文档里的对不上」。
这个工具把调试过程变得可观察：
① 四种算法：HMAC-SHA-1 / 256 / 384 / 512；
② 密钥和消息都能选格式：文本、Hex、Base64——因为「密钥到底是字符串本身，还是 Hex 解码后的字节」是最常见的出错点，这里让你明确指定；
③ 三种输出编码：Hex 小写 / 大写、Base64、Base64url，不用再手动转换；
④ 一致性校验：把文档里给的示例签名粘进来，自动比对并显示是否一致——这是本工具最实用的功能，能快速定位到底是算法错还是拼接错；
⑤ 字节数实时统计：一眼看出消息里是不是混进了多余的换行。
全程在你自己的浏览器里完成，用浏览器内置的 Web Crypto 实现，密钥和消息都不会离开这台设备。
怎么实现：
① 导入密钥：`crypto.subtle.importKey('raw', 密钥字节, { name: 'HMAC', hash }, false, ['sign'])`。密钥按你选的格式解码成字节后再导入，不做任何隐式转换；
② 签名：`crypto.subtle.sign('HMAC', key, 消息字节)`。消息同样按所选格式解码，UTF-8 编码由 `TextEncoder` 完成，保证多字节字符（中文、emoji）按字节正确参与计算；
③ 输出编码：Hex 直接按字节转十六进制；Base64 用 `btoa` 分块转换（避免大数组爆栈）；Base64url 在此基础上把 `+` → `-`、`/` → `_`，并去掉尾部 `=`；
④ 校验：把你的结果与期望值规范化后比较——统一去掉空白、统一小写，再做字符串比较，避免因为大小写或空格造成误判；
⑤ 注意：这里做的是非恒定时间比较。作为调试工具没问题，但生产环境的验签代码必须使用恒定时间比较（避免计时攻击）。
它不做：不发任何网络请求、不保存密钥、不做 JWT 解析、不做 RSA/ECDSA 签名。
importKey + sign）实现 HMAC-SHA-1/256/384/512 计算；密钥与消息均可选文本 / Hex / Base64 格式，避免「密钥到底是字符串还是字节」导致的经典错误；输出支持 Hex 大小写 / Base64 / Base64url；内置一致性校验（规范化后比对期望值）与实时字节数统计、示例一键填入。非安全上下文给出明确引导。纯本地零依赖，适配黑夜模式。
审核通过后就会展示在留言板上，稍安勿躁～
还没有留言，来抢沙发吧！