VSCode调试前端依赖Debugger for Chrome插件与Chrome DevTools协议协同，需正确配置launch.json、启用source map、匹配webRoot及启动参数，否则断点不命中、console丢失、映射错乱。
VSCode 插件本身不直接“让浏览器开发流程更智能”，真正起作用的是插件与浏览器调试协议（Chrome DevTools Protocol）的协同，以及对源码映射（source maps）、断点同步、控制台复用等底层能力的封装。关键不在装了什么插件，而在是否配对了正确的调试配置和运行环境。
Debugger for Chrome 配置失败的典型表现
常见错误现象包括：Unable to launch browser: spawn chrome ENOENT、断点灰色不可命中、debugger 语句不触发、控制台输出显示 VMxxx 文件而非源文件名。
- 确保本地已安装 Chrome 浏览器（非 Chromium 或 Edge），且路径被系统识别；Windows 下可检查
where chrome，macOS 下常用/Applications/Google Chrome.app/Contents/MacOS/Google Chrome -
launch.json中的url必须指向已启动的服务（如http://localhost:3000），不能是本地文件路径（file://） - 若项目经构建（如 Webpack/Vite），必须启用
sourcemaps并正确设置webRoot，否则断点无法映射回原始.ts或.jsx文件 - 使用
request: "attach"模式时，需提前手动启动 Chrome 并带参：chrome --remote-debugging-port=9222 --user-data-dir=/tmp/chrome-debug
vscode 调试中 console.log 不显示或丢失的原因
不是插件问题，而是调试器默认行为与浏览器控制台的分流逻辑导致的。VSCode 的 Debug Console 默认只显示脚本执行期的 console 输出，但不捕获网络请求、渲染日志或异步 microtask 后的日志（如 Promise.then 内容）。
小红书长文-谷歌浏览器
下载
在 Linux 上通过 Chrome 挂载/VNC 自动发布小红书长笔记。Agent 撰写标题和正文后执行 xhs_publish.sh --publish --submit，触发小红书发布。
- 在
launch.json中添加"console": "integratedTerminal"可将日志重定向到集成终端，避免丢失 - 启用
"outputCapture": "console"（部分版本支持）能强制捕获所有控制台输出 - 更可靠的做法是：在代码中显式调用
debugger，再在 VSCode Debug Console 中手动执行console.log(...)—— 这时它一定走的是当前调试上下文 - 注意：某些框架（如 Next.js App Router）会在服务端执行部分
console.log，这些不会出现在浏览器调试器中
Source map 映射错乱时怎么快速验证
核心判断依据只有一个：在 Chrome DevTools 的 Sources 面板里，能否看到你编辑的原始文件（如 src/App.tsx），而不是打包后的 main.js？如果看不到，说明 source map 没生效或路径不对。
- 检查构建工具输出：Webpack 用户确认
devtool: 'source-map'；Vite 用户确认build.sourcemap: true（开发模式默认开启） - 在 VSCode 的 Debug Console 输入
require('source-map-support').install()（Node 环境下）可临时补救，但不解决根本问题 - 在
launch.json中加"sourceMapPathOverrides"是最常被忽略的一步，例如：{ "sourceMapPathOverrides": { "webpack:///./src/*": "${webRoot}/src/*" } } - 用 Chrome 打开
http://localhost:3000/main.js.map直接看 JSON 内容，确认sources字段是否为相对路径，且sourceRoot是否为空或合理
真正卡住人的从来不是插件装没装，而是 launch.json 里那几行配置是否匹配你的构建产物结构、Chrome 是否以调试模式启动、以及你有没有意识到 source map 是双向映射——既要在浏览器里显示源码，也要让 VSCode 能反查到行号。
