VSCode插件调试调用堆栈不完整、变量显示not available，主因是未正确启用extensionHost调试、sourceMap路径错配或断点设在不可执行行；需确认launch.json的type为extensionHost、配置正确sourceMaps和outFiles，并在JS实际可执行行设断点。
VSCode 插件调试中，调用堆栈不完整、变量值显示为 not available 或根本看不到局部变量，不是插件写错了，而是调试器没真正进入插件运行时上下文——常见于未启用 extensionHost 调试、sourceMap 路径错配，或断点设在了被优化掉的代码行。
为什么插件调试时调用堆栈只显示“eval”或空帧？
VSCode 插件运行在独立的 Extension Host 进程中，普通 Node.js 调试配置无法捕获其调用链。你看到的 eval 帧，通常是插件入口（如 activate）被动态加载后执行的匿名函数，调试器因 sourceMap 缺失或路径映射失败，无法还原原始源码位置。
- 确认 launch.json 中
type是extensionHost，不是node - 检查插件项目是否生成了正确的
out/目录和.map文件，并在launch.json中配置sourceMaps: true和准确的outFiles（例如["${workspaceFolder}/out/**/*.js"]） - 避免在 TypeScript 源码的
import行或export行打点——这些语句在 JS 运行时不存在，断点会挂空 - 若使用 Webpack 打包插件，需额外配置
devtool: "source-map"并确保output.devtoolModuleFilenameTemplate生成可解析的绝对路径
Variables 面板里局部变量显示 “not available” 怎么办？
这不是变量没定义，而是 V8 对未实际使用的变量做了死代码消除（DCE），尤其在 async 函数或箭头函数中常见。调试器读不到，不代表它不存在；但你确实没法直接看。
- 在变量首次赋值后、或即将被使用前的语句行设断点（比如
const config = getConfig();的下一行），比在声明行更可靠 - 在调试控制台中手动输入变量名回车，有时能强制触发求值（前提是该变量在当前帧作用域内已初始化）
- 临时加一句
console.log(config);再删掉——看似倒退，实则是绕过 V8 优化最稳的验证手段 - 启动调试时加上
--disable-optimizations参数（需修改launch.json的runtimeArgs），但会拖慢执行，仅限排查阶段用
Watch 面板输什么表达式才对插件开发真正有用？
插件变量常跨模块、异步、带生命周期钩子，光输 context 没用——它是个对象，但关键属性如 context.subscriptions 或 context.globalState 才是问题源头。
- 监控扩展状态：输入
context.globalState.get("lastOpenFile")或context.workspaceState.get("searchHistory") - 检查注册项是否生效：用
vscode.commands.getCommands().then(cmds => cmds.includes("myExtension.doThing"))（注意这是 Promise，值不会自动展开，但错误会暴露） - 安全访问嵌套对象：
context?.globalState?.keys?.()?.length比context.globalState.keys().length更健壮 - 避免副作用：别在 Watch 里写
context.globalState.update("x", 1)——Watch 是只读求值，但某些运行时可能意外触发，导致状态污染
插件调试最难的不是设断点，而是确认你停住的那一帧，确实是你要调试的逻辑所处的真实上下文。每次看到 not available 或空堆栈，先问自己：sourceMap 对得上吗？断点在 JS 可执行行吗？Extension Host 进程真连上了吗？这三个问题盖过所有技巧。
