vscode插件无法直接调用用户js函数，必须通过调试协议、进程通信或消息通道（如webview.postmessage）间接交互；变量读取限于调试会话scope或全局暴露属性。
VSCode插件如何调用用户JS代码中的函数
插件不能直接执行工作区里的 myFunction()，必须通过调试协议或进程通信间接触发。最可靠的方式是让插件启动一个带 --inspect 参数的 Node.js 子进程，并监听其调试端口；或者注入脚本到已打开的浏览器页（需配合 pwa-chrome 调试器）。直接 require 用户 JS 文件会因路径、模块系统（ESM/CJS）、TS 编译状态不一致而失败。
- 推荐做法：插件执行
node --inspect-brk ./src/index.js，再用vscode.debug.startDebugging()关联该进程 - 避免硬编码路径，用
vscode.workspace.rootPath拼接src/index.js，但要先检查该路径是否存在 - 若目标是浏览器环境，插件可调用
vscode.env.openExternal()打开本地服务地址，再通过debugger-for-edge的 attach 配置连接
用户JS里怎么主动通知VSCode插件
纯前端 JS 无法直接调用插件 API，必须借助消息通道。常见且稳定的做法是：在 HTML 中注入一个全局 window.vscode 对象（由插件通过 webview 或 Live Server 注入），然后用户代码调用 window.vscode.postMessage({ type: 'log', data: x })。插件侧监听 webview.onDidReceiveMessage 即可捕获。
- 注意：只有插件控制的
WebviewPanel或通过Debugger for Edge/Chrome启动的页面才允许注入window.vscode - 普通
file://页面会被浏览器同源策略拦截，postMessage无效 - 如果用 Live Server 启动，必须在
launch.json的url字段填http://localhost:5500，而非file://路径
调试时断点打在插件代码里却没停住
根本原因是插件运行在 VSCode 主进程或扩展主机进程，与用户 JS 所在的 Node.js 或浏览器渲染进程完全隔离。你在插件 TS 文件里打的断点，只对插件逻辑生效；它不会影响你正在调试的 app.js。
- 插件自身调试需单独配置：
type: "pwa-node"+program: "./extension.js"，且必须在插件开发窗口（Extension Development Host）中运行 - 用户 JS 断点是否命中，只取决于
launch.json中的type（node或pwa-chrome）和 source map 映射是否正确 - 混淆过的代码（如 Terser 压缩后）即使有 source map，也可能因列映射丢失导致断点偏移——建议开发阶段禁用压缩
插件读取用户JS变量值的可行边界
插件无法直接访问 let count = 42 这样的局部变量，只能拿到调试器暴露的运行时快照。真正能读取的是：调试会话中暂停时的 scope 数据（通过 vscode.debug.activeDebugSession.customRequest() 调用 evaluate 协议），或用户显式挂载到 window / globalThis 上的属性。
- 安全做法：让用户在代码开头加一行
globalThis.DEBUG_CONTEXT = { api, state };，插件再用debugSession.customRequest('evaluate', { expression: 'globalThis.DEBUG_CONTEXT' })获取 - 不推荐依赖
console.log输出——插件无法可靠拦截 stdout，除非重写process.stdout.write（仅限 Node.js 调试场景，且需提前注入） - 浏览器环境更受限：插件无法读取未暴露的闭包变量，哪怕用了
debugger语句暂停，也得靠用户配合暴露数据入口
