Node.js中crypto.createCipher被弃用，因其隐式使用弱默认参数且不支持AEAD；应改用createCipheriv/createDecipheriv，并优先选用aes-256-gcm等带认证的模式。
Node.js 的 crypto 模块本身不“调优”，它只是 OpenSSL 的封装层；真正影响性能和安全性的，是算法选择、模式配置、密钥管理方式，以及你是否在无意中触发了低效路径。
为什么 crypto.createCipher 被弃用？该用什么替代
Node.js 10+ 已将 crypto.createCipher() 和 crypto.createDecipher() 标记为废弃（DEP0086），因为它们隐式使用弱默认参数（如固定 IV、无认证加密），且不支持 AEAD 模式。继续用会收到警告，更关键的是：它容易写出有填充 oracle 风险或无法验证完整性的代码。
- 必须改用
crypto.createCipheriv(algorithm, key, iv)和crypto.createDecipheriv(algorithm, key, iv)，显式传入 IV 和密钥 - 推荐优先选 GCM 模式（如
aes-256-gcm），它自带完整性校验，避免额外做 HMAC - ECB 模式绝对禁用——它不接受 IV，每个块独立加解密，明文重复 → 密文重复，等同于裸奔
IV 和密钥怎么生成才安全且高效
IV 不是密码，但必须满足“唯一且不可预测”；密钥则必须具备足够熵值。硬编码、Math.random()、字符串拼接都是典型错误。
- IV 用
crypto.randomBytes(12)（GCM 推荐 12 字节）或crypto.randomBytes(16)（CBC）生成，每次加密都重生成 - 密钥别手写字符串——用
crypto.scryptSync(password, salt, { N: 1024, r: 8, p: 1, maxmem: 32 * 1024 * 1024 }, 32)派生，或直接用crypto.randomBytes(32)生成 AES-256 密钥 - 千万别把 IV 或 salt 存成固定值；它们可以明文传输/存储（比如和密文拼在一起），但绝不能复用
加密输出怎么处理才不踩坑
很多人卡在“解密失败”上，其实问题常出在编码与二进制数据的混淆，尤其是 base64 和 hex 的混用、padding 处理不一致。
-
cipher.update(data, 'utf8', 'base64')输出的是 base64 字符串；对应地，decipher.update(cipherText, 'base64', 'utf8')才能正确还原——两边 encoding 必须严格匹配 - GCM 模式下，必须调用
cipher.setAuthTag(tag)（解密前）和cipher.getAuthTag()（加密后），漏掉就解密失败，且错误信息是 generic “Unsupported state or unable to authenticate data” - 不要对密文再做 Base64 编码两次——比如先
update(..., 'base64')再手动Buffer.from(...).toString('base64')，这会导致解密时长度错乱
VSCode 调试时怎么确认 OpenSSL 实际行为
VSCode 本身不干预 crypto 行为，但你可以借它快速验证底层 OpenSSL 是否按预期工作，避免被 JS 层封装掩盖问题。
- 在 launch.json 中启用 node --trace-warnings，捕获废弃 API 警告和加密异常
- 加断点到 cipher.final() 后，用
console.log(cipher instanceof crypto.Cipher)确认实例类型，排除构造失败 - 运行
console.log(crypto.getCiphers().filter(c => c.includes('aes')))查看当前 Node 版本实际支持的 AES 变种（比如是否有aes-192-gcm） - 若怀疑 OpenSSL 版本过旧（如 Ubuntu 18.04 自带的 1.1.1），可临时在终端执行
node -e "console.log(require('crypto').getDiffieHellman('modp15').generateKeys('hex'))"测试高级特性可用性
最易被忽略的点是：GCM 的 auth tag 长度默认 16 字节，但某些旧客户端可能只认 12；而 IV 复用一次，整个加密就形同虚设——这些都不是报错能立刻暴露的问题，得靠设计时的约束和测试覆盖来守住底线。
