crypto.createDecipher 在 Node.js 19+ 已废弃，v20 默认禁用、v22+ 完全移除；必须改用 crypto.createDecipheriv，且 key/iv 需为 Buffer、显式设置 padding，并注意跨语言填充与编码一致性。
crypto.createDecipher 在 Node.js 19+ 已被标记为废弃，VSCode 调试时直接报错（如 TypeError: crypto.createDecipher is not a function 或 ERR_CRYPTO_INVALID_KEYTYPE），不是你代码写错了，而是 API 本身被移除或行为变更了。
为什么 crypto.createDecipher 会突然报错
Node.js 从 v19 开始逐步淘汰 crypto.createDecipher 和 crypto.createCipher，v20 起默认禁用，v22+ 完全移除。VSCode 的 Node.js 调试器（node 进程）会严格遵循当前运行的 Node.js 版本规则，不提供降级兼容层。
- 报错常见形式：
TypeError: crypto.createDecipher is not a function或ERR_CRYPTO_INVALID_KEYTYPE - 即使你在代码里写了
try/catch，错误也会在模块加载或首次调用时抛出，VSCode 断点可能根本进不去 - 老旧系统（如遗留 PHP/AES-CBC 互操作逻辑）常依赖
createDecipher('aes-256-cbc', key, iv)这种三参数签名，而新 API 强制要求createDecipheriv+ 显式key和ivBuffer
crypto.createDecipheriv 替代方案实操要点
必须改用 crypto.createDecipheriv，但不是简单替换函数名——参数结构、编码处理、填充方式都不同。
-
createDecipheriv(algorithm, key, iv)的key和iv必须是Buffer，不能是字符串（哪怕 hex 或 base64） - AES-CBC 默认使用 PKCS#7 填充，旧版
createDecipher可能隐式处理，新 API 需显式调用decipher.setAutoPadding(true)（否则解密失败或乱码） - 如果原始密钥/IV 来自 hex 字符串，用
Buffer.from(hexString, 'hex')；来自 base64，用Buffer.from(b64String, 'base64') - 注意：Node.js v22.3.0 文档明确列出
ERR_CRYPTO_INVALID_KEYLEN错误——AES-256 要求 key 长度严格为 32 字节，Buffer.from('my-key', 'utf8')生成的长度很可能不对
示例修复：
const crypto = require('crypto');
// ❌ 旧写法（v18 及以下可用，v20+ 报错）
// const decipher = crypto.createDecipher('aes-256-cbc', 'my-secret-key', '1234567890123456');
// ✅ 新写法（所有现代 Node.js 版本兼容）
const key = Buffer.from('your-32-byte-key-here-in-hex', 'hex'); // 必须 32 字节
const iv = Buffer.from('1234567890123456', 'utf8'); // 必须 16 字节
const decipher = crypto.createDecipheriv('aes-256-cbc', key, iv);
decipher.setAutoPadding(true); // 关键！否则解密失败
VSCode 调试时仍报错的隐藏原因
即使代码已改用 createDecipheriv，VSCode 启动调试仍可能失败，问题往往不在你写的代码里。
- Vite、Webpack、Rollup 等构建工具的内部依赖（如
vite/dist/node/chunks/...）可能仍调用废弃 API —— 这类错误堆栈里会出现node_modules/vite/...路径，说明是工具链问题，不是你的源码 - 检查
package-lock.json中是否有老版本crypto-browserify或browserify-cipher，它们在 Node.js 环境下会污染全局crypto模块 - VSCode 的
launch.json若指定"runtimeVersion": "18"，但实际系统安装的是 v22，Node.js 仍以 v22 运行，版本声明无效 - 某些 Electron 应用或 VSCode 插件自带 Node.js 运行时，可能版本滞后，需单独升级插件或换用系统 Node.js
兼容老旧系统数据的解密实操陷阱
和 PHP、Java 等系统对接时，createDecipheriv 解密失败往往不是语法问题，而是底层字节对齐差异。
- PHP 的
openssl_decrypt默认使用零填充（zero-padding）而非 PKCS#7，而 Node.js 默认 PKCS#7 —— 必须手动关闭自动填充：decipher.setAutoPadding(false)，再自行处理末尾 \x00 - PHP 的
md5($key)生成 16 字节 key，Node.js 用crypto.createHash('md5').update(key).digest()才等效；若用digest('hex')再Buffer.from(..., 'hex')，结果一样，但少一步易出错 - IV 如果来自 PHP 的
substr(md5($key), 0, 16)，注意 PHP 的md5返回小写 hex，Node.jsBuffer.from不区分大小写，但最好统一转小写避免混淆 - 加密数据若经 base64 编码传入，务必先
Buffer.from(encoded, 'base64')，而不是直接传字符串给decipher.update()
真正麻烦的从来不是“怎么写”，而是“怎么让两边字节完全一致”。一个字符编码、一次隐式 toString()、一处 padding 差异，都会导致解密成乱码或报 ERR_CRYPTO_INVALID_AUTH_TAG。
