VSCode插件调试需确认crypto模块可用：确保VSCode≥1.80、禁用package.json中crypto依赖、老版本改用crypto-js；Web Worker/WebView须用Web Crypto API；launch.json须设"type":"extensionHost"且配置outFiles；密钥来源需抽象为可注入配置并校验长度。
调试前先确认 crypto 模块在插件进程里能用
VSCode 插件运行在独立的 Node.js 进程（Extension Host），它和你在终端跑的 Node 脚本不是同一个上下文。很多加密逻辑在普通 Node 脚本里能跑，一进插件就报 Cannot find module 'crypto' 或 ERR_CRYPTO_INVALID_KEYLEN——根本原因是插件宿主进程没加载内置模块，或用了不兼容的 Electron 内置 Node 版本。
验证方式：在插件代码里加一行测试：
console.log('crypto available:', typeof require('crypto') === 'object');
如果输出 false，说明当前 Extension Host 的 Node 环境没暴露 crypto（常见于旧版 VSCode 或某些打包配置）。此时不能靠 npm install crypto 补救——那是无效的 polyfill，反而引入非安全实现。
- 确保 VSCode 版本 ≥ 1.80（对应 Electron 25+、Node.js 20.9+），这是 crypto 模块稳定可用的底线
- 不要在
package.json的dependencies里写crypto——它是内置模块，写进去会导致 webpack 打包时错误地 external 化或 mock - 若必须支持老版本 VSCode，改用
crypto-js等纯 JS 库，但注意它不支持 GCM 认证模式，且性能差、无常数时间比较
解密逻辑断点失效？检查是否在 Web Worker 或 WebView 中执行
插件里有些加密操作会刻意放到 Web Worker（比如大文件 AES 解密）或 WebView（渲染加密后的 HTML 报表），这时你在主扩展代码里打的断点完全不会触发——因为执行上下文已切换。
典型表现：日志有输出，但 debugger; 不停；console.log 看到密文，但解密后结果为空或乱码。
- Web Worker 中无法直接 require('crypto')，必须用
self.crypto.subtle（Web Crypto API），且只支持部分算法（如 AES-GCM、RSA-OAEP），不支持 scrypt 或 pbkdf2 - WebView 是沙箱环境，默认禁用 Node 集成，
require('crypto')会报 ReferenceError；需在webview.options中显式开启enableScripts和localResourceRoots，但仍无法访问 Node 原生模块 - 调试 Web Worker：在 DevTools 的 Sources → Threads 面板里找 worker 名称；调试 WebView：右键 WebView → “Inspect” 打开独立 DevTools，它用的是 Chromium 内核，不是 Node
launch.json 配置错一个字段，加密流程就静默失败
VSCode 插件调试依赖 .vscode/launch.json 启动 Extension Host 实例。很多人照抄普通 Node 调试配置，漏掉关键项，导致加密函数看似执行了，实际根本没走通。
最常被忽略的三项：
-
"type": "extensionHost"—— 必须是这个，不是"node"；设成node会启动一个孤立的 Node 进程，压根不加载你的插件 -
"runtimeExecutable"删掉或留空 —— 它不该指向某个 node 可执行文件；插件调试由 VSCode 自己控制 runtime，硬指定反而会拉起错误版本 -
"outFiles"要包含编译产物路径（如["${workspaceFolder}/out/**/*.js"]）——TypeScript 插件若没配这个，断点打在 .ts 文件上会偏移或失效，你看到的“解密结果”其实是上一次缓存的旧值
一个最小可用配置示例：
{
"version": "0.2.0",
"configurations": [{
"name": "Launch Extension",
"type": "extensionHost",
"request": "launch",
"runtimeExecutable": "${execPath}",
"args": ["--extensionDevelopmentPath=${workspaceFolder}"],
"outFiles": ["${workspaceFolder}/out/**/*.js"]
}]
}
密钥来源不一致，本地调试和真实环境行为割裂
插件里解密往往依赖密钥，而密钥来源在调试和发布时天然不同：开发时可能从 process.env 或 vscode.workspace.getConfiguration() 读，生产时走系统密钥库（如 Windows DPAPI、macOS Keychain）。这种差异会让解密在 launch.json 里成功，一打包发布就失败。
更隐蔽的问题是：密钥派生参数（salt、iterations）在调试时写死，但线上由服务端动态下发——你永远没法在本地复现那个 salt，自然解不出真实密文。
- 别在插件代码里直接调用
crypto.pbkdf2Sync(password, 'hardcoded-salt', ...)；把 salt 和参数做成可注入的配置项，调试时用固定值，上线时替换为服务端响应 - 对密钥读取逻辑做抽象，例如封装
getDecryptionKey(): Promise<Buffer>，调试时返回 mock key，生产时调用vscode.authentication.getSession()或 native host - 在解密函数开头加校验：
if (!key || key.length !== 32) throw new Error('Invalid key length for AES-256')—— 很多静默失败其实只是 key 为 undefined
真正容易被忽略的，是插件进程的环境隔离性：它看不到你终端里的 env，也读不到全局 npm 包里的密钥管理器。任何假设“密钥已就位”的逻辑，在 Extension Host 里都得重新验证。
