直接用crypto.subtle.digest()计算凭证哈希并比对可行，但必须配合timingsafeequal()和严格序列化；不能分两步存原始凭证与哈希值，因localstorage无原子写入机制，易致数据与哈希错位，应打包为json对象一次性写入。
直接用 crypto.subtle.digest() 计算凭证哈希并比对，是可行的，但必须配合 timingSafeEqual() 和严格序列化，否则校验形同虚设。
为什么不能只存原始凭证 + 单独哈希值？
本地存储（如 localStorage）没有原子写入机制。如果分两步存：localStorage.setItem('cred', str) 和 localStorage.setItem('cred_hash', hash)，中间可能被中断、覆盖或篡改，导致数据与哈希错位。浏览器崩溃、脚本异常、甚至用户手动修改控制台都可能破坏一致性。
推荐做法是把哈希和数据打包进一个 JSON 对象，一次性写入：
const payload = {
data: { username: "alice", token: "x1y2z3" },
hash: "a1b2c3...",
timestamp: Date.now()
};
localStorage.setItem("user_credential", JSON.stringify(payload));
如何正确计算和比对哈希值？
关键在三件事：统一序列化、固定编码、防时序攻击。常见错误是直接对对象调用 JSON.stringify(obj)，但对象属性顺序不保证，undefined / function 被忽略，空格/换行差异也会让哈希完全不同。
- 始终用
JSON.stringify(value, null, 0)（无缩进）确保输出格式稳定 - 必须用
TextEncoder转为 UTF-8 字节流，不能用str.getBytes()或unescape(encodeURIComponent())等非标准方式 - 比对必须用
crypto.subtle.timingSafeEqual()，而非===—— 后者会因字符串逐字节比较而暴露哈希长度或前缀，构成侧信道风险
读取时校验失败的典型表现有哪些？
不是“哈希不匹配”就代表被篡改，很多看似正常的行为会导致校验失败：
-
localStorage中值被其他脚本覆盖（比如多个 Tab 共享同一 key，且未加锁） - 用户清除了部分缓存但没清
localStorage，旧哈希仍存在，新数据却没更新哈希 - 时间戳字段被意外修改（哪怕只是加了个空格），导致整个 JSON 字符串变化
- 服务端下发的凭证含不可见字符（如 BOM、零宽空格），前端未清洗就直接序列化
建议在校验失败时记录具体原因（例如打印重算哈希 vs 存储哈希的十六进制差异），而不是静默降级——完整性校验一旦失效，就不该继续信任该凭证。
HTTPS 是硬性前提，HTTP 下 crypto.subtle 可能不可用
crypto.subtle 在非安全上下文（即非 HTTPS 或非 localhost）中会被禁用或返回 undefined。开发阶段用 http://localhost 没问题，但部署到测试环境若走 http://test.example.com，digest() 会直接抛出 SecurityError。
检测方式很简单：
if (!window.crypto?.subtle) {
throw new Error("Web Crypto API not available — ensure HTTPS or localhost");
}
别试图 fallback 到 MD5 或 SHA-1 库补救：它们本身已不安全，且纯 JS 实现性能差、易被逆向，反而增加攻击面。真要兼容 HTTP 环境，应放弃客户端完整性校验，改由服务端签发带签名的凭证（如 JWT），前端只做解析和过期检查。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
