chrome扩展调试必须用attach模式而非launch，因launch无法自动加载解压扩展；需手动启动带--remote-debugging-port和--load-extension参数的chrome，webstorm配置url为chrome-extension://id/对应页面，并确保source map路径正确及service worker生命周期适配。
Chrome 扩展调试必须用 Attach 模式，不能选 Launch
WebStorm 默认的 JavaScript Debug 配置里如果选 Launch，它会尝试自己启动 Chrome 实例——但 Chrome 扩展只能在显式加载 unpacked 的开发模式下运行，且需启用 --load-extension 或通过 chrome://extensions 手动加载。WebStorm 无法自动完成这一步，所以 Launch 必然失败。
正确做法是：Run → Edit Configurations → + → JavaScript Debug → 选择 Attach to Node.js/Chrome（注意不是 “Launch”）。这个模式下 WebStorm 只监听已启动的、带调试协议的 Chrome 实例，不干涉扩展加载流程。
- Chrome 必须提前用命令行启动，并指定扩展目录和调试端口：
"C:\Program Files\Google\Chrome\Application\chrome.exe" --remote-debugging-port=9222 --load-extension=C:\path\to\your\extension --user-data-dir=C:\temp\chrome_debug - macOS/Linux 路径需替换，
--load-extension后跟的是扩展根目录（含 manifest.json），不能是 zip 或打包后的 crx - 启动后访问
chrome://extensions确认扩展已加载且“开发者模式”开启，右上角应显示“已加载解压的扩展程序”
URL 字段填 chrome-extension://ID/，不是 localhost
扩展页面（popup、options、background）没有 HTTP 地址，它们的 URL 是 chrome-extension://<extension-id>/popup.html</extension-id> 这类格式。WebStorm 的 JavaScript Debug 配置中 URL 字段必须填真实地址，否则 source map 无法映射，断点永远不命中。
扩展 ID 不是随意生成的——它是基于扩展目录路径的固定哈希值。首次加载后，在 chrome://extensions 页面勾选“开发者模式”，找到你的扩展，点击“详情”，复制“扩展 ID”字段（一串 32 位小写字母+数字）。
- popup 页面调试：填
chrome-extension://abc123.../popup.html - options 页面：填对应
options_page声明的路径，如chrome-extension://abc123.../options.html - background 页面：填
chrome-extension://abc123.../_generated_background_page.html（若 manifest 中声明了background.service_worker，则 background 脚本不可直接访问，需用chrome.devtools或chrome.runtimeAPI 调试）
background script 断点不触发？检查 manifest 和 service worker
Manifest V3 强制使用 service worker 替代 persistent background page，而 service worker 生命周期由浏览器管理——它可能被挂起、终止、冷启动。WebStorm 断点在未激活状态下不会触发，这是正常行为，不是配置错误。
- 确保 manifest.json 中
background正确声明："background": {"service_worker": "background.js"} - 在 background.js 开头加
console.log('background loaded')，然后打开chrome://extensions→ 点击你的扩展 → “Inspect views: background page” → 查看 DevTools Console 是否输出；只有这时 WebStorm 才能附加到该上下文 - 如果用的是 Manifest V2（已弃用但仍有项目在用），确认
"persistent": true，否则 background page 也会被懒加载或销毁 - WebStorm 的断点只对当前活跃的 service worker 实例有效；刷新扩展或触发事件（如
chrome.runtime.onMessage）后才可能命中
source map 路径错乱导致断点打在 bundle 上
多数扩展用构建工具（Vite、Webpack、esbuild）打包，生成的 .js.map 文件若路径映射不准确，WebStorm 就找不到原始源码。尤其当构建输出目录与 manifest 中声明的脚本路径不一致时，断点会停在混淆后的 bundle 行，而不是你写的 TS/JS 文件。
- 检查构建产物中
background.js.map里的sources字段是否指向项目内真实路径（如../src/background.ts），而不是绝对路径或 node_modules 内路径 - Vite 用户：在
vite.config.ts中显式配置build.sourcemap = 'inline'或'hidden'，并确保build.rollupOptions.output.manualChunks不拆分 background 入口 - Webpack 用户：确认
devtool: 'source-map'且output.devtoolModuleFilenameTemplate返回相对路径（如'[absolute-resource-path]'容易出错） - WebStorm 中右键断点 → “Jump to Source” 若跳转失败，说明 source map 解析失败，优先查
sources和sourceRoot
