vscode插件协作开发关键在于状态控制与调试入口选择：vscode-browser-preview侧重实时预览共享，需手动开启且依赖可访问url；javascript debugger专注断点调试，须配置pwa-chrome及正确webroot；二者不可叠加，需按场景取舍，并注意chrome进程清理。
VSCode 插件与浏览器协作开发，核心不是“能不能连上”，而是“谁控制状态、谁同步行为、谁承担调试入口”。vscode-browser-preview 和 JavaScript Debugger 是两条不同路径：前者重实时共享预览，后者重单点断点调试。选错插件组合，协作时会出现“你看到的不是我操作的”或“断点不命中”这类典型问题。
vscode-browser-preview 的 Live Share 协作必须手动开启预览窗口
很多人以为只要开了 Live Share 会话，浏览器预览就自动同步——不是这样。vscode-browser-preview 默认不参与 Live Share 的自动共享，必须由主机主动执行 Browser Preview: Open Preview 命令，才会创建一个被共享的浏览器实例。
- 访客无法自行打开预览窗口，只能看到主机已开启的窗口
- URL 必须是可访问的（比如
http://localhost:3000），不能是file://协议（会触发 CORS 或空白页） - 如果项目用 Vite/Next.js 等 dev server，确保 host 机器上服务已启动且端口未被防火墙拦截
- Chrome Executable 路径配置错误会导致预览窗口打不开，错误信息通常是
Failed to launch browser
JavaScript Debugger 的 launch.json 配置中 type 必须为 pwa-chrome
旧版文档常写 "type": "chrome"，但 VS Code 当前稳定版（2026 年）已弃用该类型，强制使用 pwa-chrome。否则断点不会生效，控制台也看不到源码映射。
-
request: "launch"表示 VS Code 启动新 Chrome 实例；"attach"则用于连接已打开的 Chrome（需提前加--remote-debugging-port=9222参数） -
webRoot必须指向实际源码目录，例如 React 项目应设为"${workspaceFolder}/src"，而非仅"${workspaceFolder}"，否则断点映射失败 -
sourceMapPathOverrides在构建工具输出路径不标准时才需要，比如 Webpack 输出到dist/js/main.js，而 source map 指向webpack:///src/，就得配"webpack:///./src/*": "${webRoot}/src/*"
两个插件共存时，调试入口只有一个能生效
vscode-browser-preview 自带简易 DevTools 面板（右键 → Inspect Element），但它不支持断点、作用域变量查看等完整调试功能；而 JavaScript Debugger 启动的 Chrome 实例自带完整 DevTools，但不被 Live Share 共享。二者不能叠加使用。
- 要多人同步操作+看效果 → 用
vscode-browser-preview+ Live Share，放弃断点，靠 console.log 或 React DevTools 插件辅助 - 要精准调试逻辑+查变量 → 用
JavaScript Debugger，每人各自 attach 到同一 dev server，不依赖共享预览 - 想兼顾？目前唯一可行方式是：主机用
vscode-browser-preview共享页面，同时另开一个pwa-chrome调试会话供自己单人调试——访客看不到这个调试窗口
真正容易被忽略的，是 Chrome 实例的生命周期管理：Live Share 共享的预览窗口关闭后，Chrome 进程未必退出；而 pwa-chrome 的 launch 模式每次都会启新进程。长时间协作后，本地可能堆积多个无响应的 Chrome 进程，占用内存且干扰调试端口。建议协作结束时手动关掉所有预览窗口，并在终端执行 pkill -f "chrome.*9222"（macOS/Linux）清理残留调试进程。
