crypto.subtle.encrypt调用AES-GCM必须传入含name:"AES-GCM"、iv（Uint8Array，推荐12字节且不可复用）和tagLength（默认128，显式指定更安全）三字段的对象；additionalData可选但参与认证；密钥须为importKey导入的合法CryptoKey，不可为字符串。
crypto.subtle.encrypt 调用 AES-GCM 是可行的，但必须满足安全上下文（HTTPS 或 localhost）、正确参数结构和密钥生命周期管理，否则会静默失败或产生不安全输出。
必须传入的参数对象长什么样
AES-GCM 模式不是只填 iv 就能跑通的。浏览器要求参数对象至少包含三个字段：
- name: "AES-GCM"（字符串字面量，大小写敏感）
- iv：必须是 Uint8Array，长度建议 12 字节（96 位），也可用 8–120 字节，但同一密钥下绝对不可复用
- tagLength：默认 128，常用 128 或 96；若设为 96，解密时也必须显式传入相同值，否则抛 DataErroradditionalData 是可选的，但业务中携带元数据（如请求 ID、时间戳）时应放这里——它参与认证但不加密，不能丢。
密钥不能是字符串，也不能硬编码
直接传"my-secret-key" 给 encrypt() 会报错：TypeError: The provided value is not of type '(ArrayBuffer or ArrayBufferView)'。
正确做法是：
- 用 crypto.subtle.importKey("raw", keyBytes, {name: "AES-GCM"}, false, ["encrypt"]) 导入密钥
- keyBytes 必须是 ArrayBuffer 或视图（如 Uint8Array），可通过口令派生（PBKDF2 + salt）或服务端下发的二进制密钥生成
- 禁止把密钥存在 localStorage 或拼进 URL；短期会话密钥建议绑定 JWT 的 jti 或 WebSocket 连接 ID
加密后怎么拿到可用的密文+标签
crypto.subtle.encrypt() 返回的是单个 ArrayBuffer，结构为「密文｜认证标签」拼接体（标签在末尾，默认 16 字节）。
常见错误是手动截取前 N 字节当密文、后 16 字节当 tag——这不可靠，因为：
- tagLength 可能设为 96（即 12 字节）
- 浏览器不保证标签严格附在末尾（虽然目前所有实现都如此，但规范未强制）
正确方式是：解密时原样传回整个 ArrayBuffer，由 Web Crypto 自动拆分并校验；若需单独传输，应在加密后显式提取：
const result = await crypto.subtle.encrypt({ name: "AES-GCM", iv, tagLength: 128 }, key, data);
const buffer = result;
const tag = buffer.slice(buffer.byteLength - 16); // 仅当 tagLength === 128 时成立
const ciphertext = buffer.slice(0, buffer.byteLength - 16);
但更稳妥的做法是用 ArrayBuffer 整体 Base64 编码后与 iv 一起传给后端，由后端按标准 GCM 格式解析。
为什么 decrypt() 总是抛 OperationError
这个错误通常不是代码写错，而是底层验证失败的统一出口，真实原因包括： -iv 和加密时不一致（哪怕只差 1 字节）
- 密钥对象用途不匹配（生成时没声明 ["decrypt"]，或 importKey() 时设了 false 用于 extractable 却又想复用）
- 传给 decrypt() 的 ArrayBuffer 被意外修改（如用 TextDecoder 再转回 ArrayBuffer）
- 后端篡改了密文或标签（GCM 会拒绝，这是正常行为，不是 bug）
最易忽略的一点：前端加密后若用 FormData.append("file", new Blob([encrypted])) 上传，Blob 的 MIME 类型可能被浏览器自动设为 application/octet-stream，但某些后端框架（如 Express multer）会因类型不符拒绝解析——此时应显式指定 new Blob([encrypted], {type: "application/octet-stream"})。
