vscode调试chrome扩展需三步：launch.json按popup、sw、content script分类型配置；chrome必须用--remote-debugging-port=9222命令行启动；扩展须以开发者模式手动加载，缺一不可。
VSCode 调试 Chrome 扩展不是“装个插件就能断点”，关键在三处：launch.json 配置必须匹配运行环境、Chrome 必须用命令行启动并开放调试端口、扩展得手动以开发者模式加载——漏掉任一环，debugger 就不生效。
manifest.json 里 manifest_version: 3 是硬门槛，别用 v2
v2 已被 Chrome 彻底弃用，2026 年起新提交全部拒收。常见错误是复制旧教程的 "background": {"page": "background.html"}，v3 不再支持该写法，必须改用 "background": {"service_worker": "background.js"}。同时注意：content_scripts 的 matches 字段不能写 "<all_urls>"</all_urls>（需显式声明协议和域名），permissions 和 host_permissions 要分开申请，否则安装时会报错 Permission '<all_urls>' is not supported</all_urls>。
Chrome 必须用 --remote-debugging-port=9222 启动，不能双击图标
VS Code 调试器靠 DevTools 协议通信，没这个端口就等于没开门。Windows/macOS/Linux 都要走终端启动：
- macOS：
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9222 --user-data-dir=/tmp/chrome-debug - Windows：
start chrome.exe --remote-debugging-port=9222 --user-data-dir=C:\temp\chrome-debug - Linux：
google-chrome --remote-debugging-port=9222 --user-data-dir=/tmp/chrome-debug
--user-data-dir 是强制项，不加会导致 Chrome 复用主配置、调试器连不上或弹窗异常；端口被占就换 9223，但 launch.json 里的 port 也得同步改。
launch.json 的 webRoot 和 url 写错，断点永远不命中
这是最常踩的坑：网上抄的配置里 "webRoot": "${workspaceFolder}/public" 对静态 HTML 项目可能对，但对 Chrome 插件完全无效——插件没 server，不走 http，url 应为空或填 about:blank，webRoot 必须指向你源码所在目录（比如 "${workspaceFolder}" 或 "${workspaceFolder}/src"）。同时确认：
-
"sourceMaps": true必须开启，否则断点打在压缩后代码上 - 若用 TypeScript，确保
tsconfig.json中"sourceMap": true且输出路径与manifest.json引用一致 - popup 页面调试：右键插件图标 → “检查弹出内容”，VS Code 才能自动 attach 到
popup.html对应的渲染进程
Service Worker 调试入口藏在 chrome://extensions 页面里
v3 的 background 不再是常驻页面，而是事件驱动的 Service Worker，没有“后台页”可点。正确做法是：打开 chrome://extensions → 找到你的扩展 → 点击“inspect views: service worker”链接 → 这才打开 SW 的 DevTools。VS Code 断点要想命中，launch.json 配置类型得是 "type": "pwa-chrome"（新版推荐）或 "type": "chrome"，且 webRoot 必须精确映射到 background.js 源文件位置，否则 source map 会失效。
真正卡住人的从来不是语法，而是 Chrome 的调试通道是否打通、VS Code 是否找得到源码、以及 v3 的生命周期模型是否理解到位——这三处不厘清，改一百行代码也没用。
