签名生成本质是js调用crypto.subtle.sign()执行hmac-sha256哈希，需将payload转uint8array、secret导入为cryptokey，输出arraybuffer再转hex；常见不一致源于payload序列化、secret隐藏字符及编码不统一。
签名生成本质是拼接+哈希，不是前端加密
HTML 本身不参与签名逻辑，它只是把 secret 和 payload 交给 JS 处理；真正生成签名的是 JavaScript 调用的哈希函数（比如 HMAC-SHA256）。浏览器里没有原生 HMAC API，必须靠 crypto.subtle 或第三方库（如 crypto-js）——但注意：crypto.subtle 要求页面在 HTTPS 或 localhost 下运行，否则直接报错 SecurityError: The operation is insecure.
常见错误现象：TypeError: crypto.subtle is undefined（HTTP 环境下）、InvalidAccessError（密钥没正确导入）、签名结果和后端对不上（编码不一致）。
- payload 必须转成
Uint8Array，不能直接传字符串给subtle.sign() - secret 必须用
subtle.importKey()导入为 CryptoKey，不能直接当字符串用 - 输出是 ArrayBuffer，要转成 base64 或 hex 才方便传输（后端通常要 hex）
用 crypto.subtle.sign() 生成 HMAC-SHA256 签名
这是现代、安全、无需引入库的方式，但兼容性需留意：IE 完全不支持，Safari 15.4+ 才完整支持 HMAC。实操时建议加个降级提示或 fallback 到 crypto-js。
关键步骤：
- 先用
TextEncoder把payload编码为Uint8Array - 用
subtle.importKey()导入secret，format必须是raw，algorithm设为{ name: "HMAC", hash: "SHA-256" } - 调用
subtle.sign()，返回 Promise，resolve 值是 ArrayBuffer - 用
Array.from(new Uint8Array(sig)).map(b => b.toString(16).padStart(2, "0")).join("")转 hex
示例片段：
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
const encoder = new TextEncoder();
const key = await crypto.subtle.importKey(
"raw",
encoder.encode("my-secret-key"),
{ name: "HMAC", hash: "SHA-256" },
false,
["sign"]
);
const sig = await crypto.subtle.sign("HMAC", key, encoder.encode('{"id":123}'));
const hexSig = Array.from(new Uint8Array(sig))
.map(b => b.toString(16).padStart(2, "0"))
.join(""); // → "a1b2c3..."
为什么签名总和后端对不上？重点查这三处
90% 的签名不一致问题出在这三个地方，不是算法错了，是数据“看起来一样，实际不同”。
-
payload是否被 JSON.stringify() 过？后端如果直接解析原始对象，而你传的是字符串，两边序列化顺序/空格/引号可能不一致 —— 统一用JSON.stringify(payload)并禁用空格（JSON.stringify(payload, null, 0)） -
secret有没有隐藏 BOM 或换行？复制粘贴时容易带\uFEFF或\n，用secret.trim()和JSON.stringify(secret)看真实内容 - 编码是否统一？JS 默认 UTF-8，但若后端用 GBK 解密 secret，或用 Latin-1 读 payload，哈希结果必然不同 —— 明确约定全部用 UTF-8
演示页里别硬编码 secret，用 input 控制更安全
写 demo 时很多人直接把 secret 写死在 JS 里，这等于把密钥暴露给所有人。真要演示，应该让用户自己输入 secret 和 payload，再实时计算签名 —— 这样既符合安全常识，也避免误传测试密钥到生产环境。
简单做法：
- 两个
<input type="text">分别绑定secretInput和payloadInput - 监听
input事件，每次触发都重新 importKey + sign（注意 abort 旧 Promise 防止竞态） - 签名结果展示在
<output></output>或<div> 里，不要 console.log <p>这样用户能直观看到 “改一个字符，签名就全变”，比静态示例更能理解签名的敏感性。</p> <p>最易忽略的一点：签名过程不涉及 DOM 渲染性能，但反复调用 <code>importKey开销不小 —— 实际项目中应缓存 key 对象，只在secret变更时重新 import。
