VSCode默认不带浏览器调试能力，必须靠插件补足；Debugger for Chrome用于断点调试JS逻辑，vscode-browser-preview仅适合轻量预览渲染效果；webRoot必须指向实际服务的静态资源目录，Chrome路径需在settings.json中正确配置，否则断点失效或连接超时。
VSCode 默认不带浏览器调试能力，必须靠插件补足；但装错或配错，反而会让 launch.json 报错、断点不命中、甚至本地服务打不开。
选对插件：Debugger for Chrome 还是 vscode-browser-preview？
两者定位完全不同，混用会冲突：
-
Debugger for Chrome是传统调试方案：启动/附加真实 Chrome 实例，支持完整 DevTools 功能（如 Network、Performance 面板），但需手动管理浏览器进程 -
vscode-browser-preview是嵌入式预览方案：在编辑器内开一个 headless Chromium 实例，适合快速看效果，但调试能力弱（仅基础 Console + Elements），不支持断点和 Source Map 映射 - 如果你要调试 JS 执行逻辑、设断点、查 call stack，必须用
Debugger for Chrome；如果只是改完 CSS 立刻看渲染效果，vscode-browser-preview更轻量
launch.json 中 webRoot 配置错，断点永远不生效
这是最常被忽略的配置项。VSCode 调试器靠它把浏览器里加载的文件路径映射回你本地源码位置。一旦错配，断点灰色不可用。
- 值必须是绝对路径，且指向你实际运行的 HTML/JS 文件所在目录，不是项目根目录
- 例如你在
http://localhost:3000/index.html下调试，而服务器静态资源从./dist目录 serve，那么webRoot应设为"${workspaceFolder}/dist" - 若用 Vite 或 Webpack Dev Server，注意它们默认 serve 的路径可能带前缀（如
/@vite/client），此时还要配合sourceMapPathOverrides修正 sourcemap 路径
Chrome 可执行路径没填对，Debugger for Chrome 启动就报错
错误信息通常是：Cannot connect to runtime process, timeout after 10000 ms —— 多半是 VSCode 根本没找到 Chrome。
- Windows 默认路径一般是
C:\Program Files\Google\Chrome\Application\chrome.exe，但 64 位系统可能装在Program Files (x86)下 - macOS 上常见路径是
/Applications/Google Chrome.app/Contents/MacOS/Google Chrome - Linux 用户得确认是否安装了 stable 版 Chrome（而非 Chromium），并用
which google-chrome查真实路径 - 务必在
settings.json里加这一行："debug.chrome.path": "/your/path/to/chrome"，而不是只写在launch.json里
vscode-browser-preview 自动刷新失效的几个硬伤
它标榜“保存即刷新”，但实际有多个触发条件限制：
- 只监听当前打开的编辑器文件，如果你改的是未打开的
style.css，预览页不会刷新 - 不识别构建产物变化（比如你用 Webpack 打包后改
src/index.js，但预览的是dist/index.html，它不会感知 dist 变更） - HTML 文件里引用的 JS/CSS 必须是相对路径，不能是
http://或//开头的 URL，否则预览时加载失败且无提示 - 它不支持 service worker 缓存，开发中若已注册 SW，需手动清空 Application → Clear storage，否则改了代码也看不到效果
真正影响调试效率的，往往不是功能有没有，而是路径对不对、上下文认不认、缓存清没清——这些细节不手动验证一遍，装十个插件也没用。
