VS Code 自1.60起内置JavaScript Debugger，已取代Debugger for Chrome扩展，安装后者可能引发断点失效等冲突；验证方式为在扩展视图中确认启用Microsoft官方的JavaScript Debugger。
为什么 Debugger for Chrome 现在基本不用单独装了
VS Code 自 1.60 版本起已内置 JavaScript Debugger（由 Microsoft 维护），它直接替代了旧版 Debugger for Chrome 扩展。强行安装后者反而可能引发冲突，比如断点不命中、sourceMap 映射失败或调试面板空白。
验证方式很简单：打开 VS Code 的扩展视图（Ctrl+Shift+X），搜索 debugger，如果看到已启用的 JavaScript Debugger（作者是 Microsoft），就不用再装任何第三方调试插件。
- 旧配置中
"type": "chrome"依然有效，但底层实际走的是内置调试器 - 如果你项目里还保留着
launch.json且能正常调试，说明它已经在用新调试器，无需改动 - 若遇到“无法连接到 Chrome”错误，优先检查是否误启用了已废弃的
Debugger for Chrome扩展并禁用它
launch.json 里 request: "launch" 和 "attach" 怎么选
二者本质区别在于谁启动浏览器进程：launch 是 VS Code 起一个新 Chrome 实例；attach 是连上你已经开着的 Chrome 窗口（需开启远程调试端口）。
日常开发中，launch 更安全、更可控，尤其适合本地开发服务器场景；attach 则适合需要复用已有登录态、扩展环境或特定 DevTools 配置的情况。
-
launch模式必须指定url（如"http://localhost:3000"）或file（如"${workspaceFolder}/index.html"） -
attach模式需提前手动启动 Chrome 并加参数：chrome --remote-debugging-port=9222 --user-data-dir=/tmp/chrome-debug，否则 VS Code 连不上 - 两者都依赖
webRoot正确设置，否则断点打在 bundle 文件里，源码映射会失效
调试时断点不生效？先看这三处
断点灰色、控制台报 Breakpoint ignored because generated code not found，大概率不是插件问题，而是构建产物和源码路径没对齐。
核心矛盾点永远在 sourceMap —— 它得让调试器知道压缩/打包后的代码行，对应原始 .ts 或 .jsx 的哪一行。
- 确认构建工具（Vite/Webpack/Rollup）已开启
sourceMap生成，例如 Vite 中设build.sourcemap: true -
launch.json中的webRoot必须指向源码根目录，不是dist或build目录 - 若用 Webpack，常需配
sourceMapPathOverrides，比如："webpack:///./src/*": "${webRoot}/src/*"，否则路径前缀不匹配
vscode-browser-preview 和内置调试器不是一回事
vscode-browser-preview 是个独立渲染容器，它内嵌 Chromium，但默认不开放完整 DevTools 协议通道——所以你不能用它做 DOM 断点、网络拦截或性能分析，只能做基础 JS 断点和 console 输出。
它真正价值在于「编辑器内预览」，而非「全功能调试」。想用 Network、Elements、Performance 面板，必须走 pwa-chrome 或 pwa-msedge 类型的调试配置。
- 它的
launch.json配置里"type": "browser-preview"只支持简单 attach/launch，不支持trace、skipFiles等高级调试选项 - 如果同时启用
vscode-browser-preview和pwa-chrome调试，注意别让两个实例同时访问同一localhost端口，否则可能触发端口占用或 CORS 冲突 - 它适合快速验证样式、布局、基础交互；复杂逻辑调试请切回标准
pwa-chrome流程
sourceMap 路径映射的准确性。哪怕 launch.json 写得再漂亮，只要构建产物里的 sourceMap 指向错误路径，断点就永远打不进真实代码里。 
