不能直接用Web Crypto API的encrypt()加密敏感数据；需结合PBKDF2派生密钥、AES-GCM加密、唯一IV及安全密钥管理，否则密钥泄露或误用将导致加密失效。
Web Crypto API 真的能直接拿来加密敏感数据吗
不能直接用，至少不能只靠 encrypt() 就完事。Web Crypto API 本身是安全的，但「安全」取决于你怎么用——密钥怎么生成、怎么存储、用什么算法、是否带认证（AEAD）、IV 怎么处理，每一步出错都会让加密形同虚设。
为什么不能用 subtle.encrypt('AES-GCM', key, data) 直接加密用户密码
这不是 API 的问题，而是语义错误：AES-GCM 加密的是「数据」，不是「密码」。密码需要的是抗暴力破解的密钥派生（如 PBKDF2 或 Argon2），而不是对称加密。直接拿密码当密钥或拿密码明文去加密，等于把锁芯暴露在门外。
-
PBKDF2或Scrypt（Web Crypto 目前不支持 Scrypt）适合从密码派生密钥，必须配足够高的iterations（如100000）和随机salt -
AES-GCM要求每次加密使用唯一且不可预测的iv（通常 12 字节），重用iv会导致密文可被部分解密 - 密钥对象（
CryptoKey）默认不可导出（extractable: false），这是好事，但若误设为true并暴露到前端 JS 变量里，密钥就泄露了
一个可用的端到端加密流程示例（AES-GCM + PBKDF2）
场景：用户输入密码，加密一段文本并保存到 localStorage；后续用同一密码解密。注意这里不传密钥，只传密码，密钥始终在内存中临时生成。
async function encryptWithPassword(plaintext, password, salt = window.crypto.getRandomValues(new Uint8Array(16))) {
const enc = new TextEncoder();
const pwBuf = enc.encode(password);
// 从密码派生 AES-GCM 密钥（256 位）
const keyMaterial = await window.crypto.subtle.importKey(
'raw', pwBuf, { name: 'PBKDF2' }, false, ['deriveKey']
);
const key = await window.crypto.subtle.deriveKey(
{ name: 'PBKDF2', salt, iterations: 100000, hash: 'SHA-256' },
keyMaterial,
{ name: 'AES-GCM', length: 256 },
false,
['encrypt', 'decrypt']
);
// 生成唯一 IV
const iv = window.crypto.getRandomValues(new Uint8Array(12));
const cipherBuf = await window.crypto.subtle.encrypt(
{ name: 'AES-GCM', iv },
key,
enc.encode(plaintext)
);
// 返回 base64 编码的 salt、iv、ciphertext（实际存储时可转成字符串）
return {
salt: btoa(String.fromCharCode(...salt)),
iv: btoa(String.fromCharCode(...iv)),
ciphertext: btoa(String.fromCharCode(...new Uint8Array(cipherBuf)))
};
}
Web Crypto API 在哪些情况下会不安全
不是 API 不安全，而是环境或用法打破了它的安全边界：
立即学习“Java免费学习笔记（深入）”；
- 在非
https://页面上调用 ——SubtleCrypto在 HTTP 下被完全禁用，连初始化都失败 - 把密钥通过
exportKey('jwk', key)导出后，用JSON.stringify存进 localStorage 或发到后端 —— 这等于放弃 Web Crypto 的密钥隔离保护 - 用
Math.random()生成 salt 或 IV —— 必须用window.crypto.getRandomValues()，否则熵不足，密钥可被穷举 - 在 React/Vue 组件的
useEffect或mounted中反复调用importKey却没缓存CryptoKey，导致性能下降且可能触发 GC 时机问题（虽不直接破密，但影响稳定性）
真正难的从来不是调用 API，而是守住密钥生命周期的每个环节：生成、使用、内存驻留、销毁。一旦密钥出现在可被调试器读取的 JS 变量里，或者被序列化成字符串，那它就已经不在 Web Crypto 的保护范围内了。
