vscode 调试浏览器必须用内置 javascript debugger（nightly），type 必须设为 "pwa-chrome"；webroot 指浏览器 url 与本地路径映射起点，sourcemappathoverrides 用于修正构建工具生成的虚拟路径，attach 模式需 chrome 手动启用 --remote-debugging-port。
VSCode 本身不直接调试浏览器，必须靠插件桥接。现在官方已把 Debugger for Chrome 的能力整合进内置的 JavaScript Debugger（Nightly），你不需要额外安装旧插件，但配置逻辑没变，错配就断点不生效、源码映射失败、控制台空白。
launch.json 中 type 字段该填 chrome 还是 pwa-chrome
填 pwa-chrome。这是当前唯一推荐值，chrome 类型已被弃用，VSCode 1.80+ 版本会直接报错或静默降级，导致断点不触发、source map 加载失败。
-
pwa-chrome支持现代调试协议（CDP v2）、ESM 模块断点、Worker 调试、条件断点等关键能力 - 如果你看到旧教程里写
"type": "chrome"，务必改成"type": "pwa-chrome" - 部分项目（如 Next.js App Router）需配合
"resolveSourceMapLocations"才能正确映射构建后的路径
webRoot 配置错误会导致断点全部失效
webRoot 不是“代码在哪”，而是“浏览器请求的 URL 路径”和“本地文件路径”的映射起点。设错后 VSCode 找不到对应源文件，断点变成空心圆，控制台也看不到变量。
- 开发服务器跑在
http://localhost:3000，且 HTML 引用了/static/js/main.js→webRoot应设为"${workspaceFolder}"（假设static在项目根目录下） - 若用 Vite，入口 HTML 是
index.html，且打包后资源在dist/→webRoot应设为"${workspaceFolder}/dist" - React/Vue CLI 默认输出到
public/或dist/，别盲目套用${workspaceFolder}/src
sourceMapPathOverrides 是 webpack/vite 项目的救命配置
构建工具生成的 source map 里路径常含 webpack:///./src/ 或 webpack:///src/ 这类虚拟路径，VSCode 默认不认识，必须手动告诉它怎么转成真实路径，否则断点永远打不到原始 .ts/.jsx 文件上。
- 常见 webpack 配置：
"webpack:///./src/*": "${webRoot}/src/*" - Vite 用户更常见：
"*": "${webRoot}/*"（简单粗暴，覆盖大部分情况） - 如果用了 monorepo，路径含
packages/my-app/src/，得写成："webpack:///../my-app/src/*": "${webRoot}/src/*" - 验证是否生效：在调试时打开“调试控制台”，输入
debugger触发断点，看调用栈里显示的是src/App.tsx还是main.js:1234
attach 模式下 Chrome 必须带 --remote-debugging-port 启动
选 request: "attach" 时，VSCode 不会帮你开浏览器，而是去连一个已运行的、开了调试端口的 Chrome 实例。没开这个端口，连接直接超时，日志里只显示 Cannot connect to runtime process。
- 手动启动命令（macOS/Linux）：
google-chrome --remote-debugging-port=9222 --no-first-run --no-default-browser-check - Windows 命令：
start chrome.exe --remote-debugging-port=9222 - VSCode 配置中
port字段默认是 9222，别改；改了就得同步改启动参数 - 别用日常 Chrome 窗口 —— 它默认不开启调试端口，且多个用户数据目录可能冲突
真正卡住人的从来不是装插件，而是 launch.json 里那几行配置和构建产物路径之间的微妙对齐。source map 映射错一格，断点就全废；webRoot 多一层少一层，变量就全黑。这些地方没有报错提示，只有沉默的失效。
