先说一个核心判断：前端加密这事儿，做得再漂亮，也替代不了 HTTPS。本质上，它们是两个不同层面的安全手段。
为啥这么说？如果页面是通过 https:// 加载的，那整个环境对攻击者来说就是透明的。他可以在数据到达浏览器之前，把 Ja vaScript 文件替换掉，把公钥换成自己的，甚至直接拦截你在加密之前输入的明文——加密的逻辑和密钥都暴露在前端，这时候的加密跟没加密一样。
真正起作用的，是 TLS 那一层的加密。只有当整个页面走的是 https://，浏览器才会信任加载过来的脚本，证书的验证才会生效，SubtleCrypto 的密钥生成流程才不会被降级或者劫持。这里面有几个容易踩的坑：
- 证书必须有效，而且不能是自签名的。否则，iOS Safari 或者 Chrome 会直接拒绝调用
SubtleCryptoAPI。 - 如果后端用 Nginx 做反向袋里，但 upstream 指向的是
https://localhost:3000，那其实只是“前端加密 + 半段 HTTPS”，中间那一截走的还是明文。这种半拉子工程，意义不大。 - 别把公钥硬编码在 JS 文件里。理想的做法是让后端在页面渲染的时候动态注入，这样能避免被爬虫批量提取。
如何用 Web Crypto API 构建加密 Payload
加密不是简单地把字符串拼起来就行，关键是要按照服务端约定的格式序列化后再加密。一个很常见的翻车现场是：先用 JSON.stringify() 把对象转成字符串，然后直接加密，但完全没有处理字段顺序、空值、或者特殊字符的转义问题。结果服务端解密之后，JSON 解析直接挂掉。
建议的做法是：先构造一个标准的对象 → 按照 key 的字典序排序 → JSON.stringify() → 用 UTF-8 编码成 Uint8Array → 最后调用 encrypt()。这中间有几个技术细节需要留意：
- 密钥必须通过
importKey()导入，类型要明确设为"public"，格式根据算法不同，RSA 公钥用"spki"，AES 共享密钥用"raw"。 - 加密输出的结果是一个
ArrayBuffer，不能直接塞到表单字段里，得先转成 Base64 字符串（可以用btoa(String.fromCharCode(...))或者Buffer.from(...).toString('base64')）。 - 加密之前一定要先校验字段值。空字符串、
null、undefined这些情况，如果不做处理，后端的解析逻辑大概率会报错。
POST 请求中如何携带加密数据
加密之后的 payload 可不能直接当成普通表单字段去提交，因为 enctype="application/x-www-form-urlencoded" 这种编码方式会破坏二进制数据。正确的做法是用 fetch() 手动构造请求体：
- 设置
method: 'POST'，headers里加上'Content-Type': 'application/json'。 - 把加密结果包进一个标准的 JSON 结构里，比如
{ "encrypted": "BASE64_STRING", "iv": "BASE64_IV", "timestamp": Date.now() }。 - 不要用
FormData去提交加密数据。因为它默认会用multipart/form-data的格式，后端收到的就不是你想要的原始 payload 了。 - 如果后端只认
application/x-www-form-urlencoded，那就把加密字段名设为data，值用 Base64 字符串，同时要确保 URL 编码正确，别忘了用encodeURIComponent()。
容易被忽略的密钥与上下文管理
Web Crypto 的密钥对象（CryptoKey）是没办法序列化的，也不能跨 iframe 或者 service worker 共享。每次页面加载都得重新导入一次，密钥的生命周期必须严格控制。这个环节有几个容易被忽略的细节：
- 别把私钥存到
localStorage里，哪怕加密了也不行，这违背了密钥隔离的基本原则。 - RSA 公钥可以缓存，但最好每次页面加载时还是从后端的
/api/public-key接口拉取一次，配合ETag可以避免重复请求。 - 加密之前，最好检查一下
na vigator.credentials是否可用。某些隐私模式下，SubtleCrypto会被禁用。 - 服务端解密失败的原因通常比较集中：IV 不一致、padding 方式不匹配（比如后端用 PKCS#7，前端却用了默认的 padding）、或者时间戳过期导致防重放机制被触发。
