WebStorm Debug 调试固定打开指定本地浏览器

默认的 debug 配置总是会打开一个新的浏览器。通过以下图片设置来打开一个新的浏览器。
主要是将默认打开的应用程序路径固定。

浏览器配置在哪

设置路径是：

Settings → Tools → Web Browsers and Preview

这个页面列出了 IDE 识别到的所有浏览器，每一行有三个可编辑的部分：

勾选框 — 是否在编辑器右上角的浏览器快捷图标里显示。
Family — 浏览器内核类型（Chrome / Firefox / Safari / Internet Explorer / Any）。这个决定 WebStorm 用什么协议跟它通信，选错了 debug 连不上。
Path — 可执行文件的完整路径。默认是空的，表示「让系统自己找」，正文说的「固定路径」就是把这一栏填上。

页面底部还有 Default Browser 下拉，决定 Open in Browser 这类操作用哪个浏览器。选 System default 就跟随系统设置，选具体某个则始终用它。

macOS 上路径要指到 app bundle 里的可执行文件，不是 .app 本身：

/Applications/Google Chrome.app/Contents/MacOS/Google Chrome

Windows 上一般是：

C:\Program Files\Google\Chrome\Application\chrome.exe

如果装了多个 Chrome 通道（Stable、Beta、Canary），可以点 + 各加一行，分别指到不同的可执行文件，这样能选具体用哪个。Canary 常被用来测新特性，跟日常用的 Stable 分开比较方便。

为什么每次都开新浏览器窗口

这个现象背后是 Chrome 的 debug 机制决定的，理解了就知道为什么「固定路径」能解决一部分问题、但不能解决全部。

WebStorm 调试前端代码走的是 Chrome DevTools Protocol（CDP）。它需要 Chrome 以远程调试模式启动，也就是带上这个参数：

--remote-debugging-port=9222

正在运行的普通 Chrome 实例没有开这个端口，WebStorm 没法接上去。于是它做的事是：用一个独立的用户数据目录（user data dir）启动一个新的 Chrome 实例，带上调试端口。这就是为什么每次 debug 都弹出一个全新的、没有你的书签和插件的浏览器窗口。

那个独立的用户数据目录在 WebStorm 的配置目录下，路径类似：

~/Library/Caches/JetBrains/WebStorm&lt;版本>/chrome-user-data

（macOS；Windows 在 %LOCALAPPDATA%\JetBrains\WebStorm<版本>\）

这个设计是有道理的：如果复用你日常的 Chrome 配置，你装的那堆插件会往页面里注入脚本，调试时断点、Console 里全是插件的噪音；而且调试实例崩溃会连带影响你的正常浏览。所以「新窗口」不是 bug，是刻意的隔离。

想复用日常浏览器的两种做法

如果确实希望在自己常用的 Chrome 里调试（保留登录状态、用得上某些插件），有两条路。

做法一：手动以调试模式启动 Chrome，让 WebStorm 连上去

先完全退出 Chrome（macOS 用 Cmd + Q，不是关窗口），然后用命令行带参数启动：

# macOS
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome \
  --remote-debugging-port=9222 \
  --user-data-dir="$HOME/chrome-debug-profile"

:: Windows
"C:\Program Files\Google\Chrome\Application\chrome.exe" --remote-debugging-port=9222 --user-data-dir="%USERPROFILE%\chrome-debug-profile"

--user-data-dir 建议指一个独立目录而不是默认配置目录。原因是新版 Chrome 出于安全考虑，用默认用户数据目录时会忽略 --remote-debugging-port（防止恶意程序通过调试端口读取你的 cookie）。指定一个独立目录能绕过这个限制，代价是这个 profile 里的登录状态要重新建立一次，但它是持久的——下次用同一个目录启动，登录状态还在。

启动后浏览器里访问 http://localhost:9222/json 应该能看到一段 JSON，列出所有可调试的页面，说明端口通了。

然后在 WebStorm 里建一个 Attach to Node.js/Chrome 或者用 JavaScript Debug 配置，端口填 9222。

做法二：用 JetBrains IDE Support 扩展（已不推荐）

早期 JetBrains 提供了一个 Chrome 扩展叫 JetBrains IDE Support，用来在普通 Chrome 里建立调试连接。这个扩展已经废弃了，Chrome 移除了它依赖的 API，现在装了也不工作。看到老教程里提这个可以直接跳过。

调试配置怎么建

WebStorm 里前端调试有几种配置类型，用错了会连不上，这是比浏览器路径更常见的问题来源：

JavaScript Debug — 调试运行在浏览器里的代码。填一个 URL（比如 http://localhost:5173），启动时 WebStorm 会开浏览器访问这个地址并接上调试器。适合 Vite / webpack dev server 起的项目。

关键的一项是 Remote URL 映射。如果 sourcemap 里的路径和本地文件路径对不上，断点会显示成空心圆（表示未绑定）。在配置的 Remote URLs 部分把本地目录和远端 URL 对应起来即可。大部分现代构建工具的 sourcemap 是准的，不需要手动配。

Attach to Node.js/Chrome — 接到一个已经在跑的进程上。上面的做法一用这个。

npm — 直接跑 package.json 里的 script。这个配置本身不是调试器，但可以配合 --inspect 调试 Node 端代码。

Node.js — 调试 Node 脚本、Express 服务这类服务端代码。

Vue / React 项目最常见的组合是两个配置一起用：一个 npm 配置跑 dev 启动开发服务器，一个 JavaScript Debug 配置接上浏览器。WebStorm 支持复合配置（Compound），把这两个打包成一个，点一次同时启动。

断点打不上的排查顺序

这是调试里最耗时的问题，按这个顺序查能覆盖大部分情况：

1. 断点是空心的还是实心的。空心圆（或带问号）表示 IDE 没能把这个断点绑定到运行中的代码，也就是路径映射有问题。实心红点表示已绑定，如果没触发就是代码逻辑上真的没走到。

2. sourcemap 有没有生成。Vite 开发模式默认有 sourcemap，生产构建需要显式开：

// vite.config.js
export default {
  build: {
    sourcemap: true,
  },
};

在浏览器 DevTools 的 Sources 面板里看能不能看到原始的 .vue / .ts 文件，能看到说明 sourcemap 是好的，问题在 IDE 的映射上。

3. 浏览器缓存。改了代码但浏览器加载的还是旧的 bundle，断点位置就对不上。DevTools 打开时勾 Disable cache，或者硬刷新（Cmd + Shift + R）。

4. 端口冲突。9222 被别的进程占了，WebStorm 连上去的是另一个 Chrome 实例。查一下：

lsof -i :9222

5. 多个 Chrome 实例在跑。macOS 上 Chrome 只允许一个实例使用同一个用户数据目录，如果之前的调试实例没退干净，新的启动会失败或者行为异常。彻底关掉所有 Chrome 再试。

其实很多时候直接用 DevTools 更快

说句实在的：WebStorm 的浏览器调试功能配起来有一定成本，而 Chrome DevTools 本身零配置且功能更全（Performance 面板、Memory 快照、Network 的请求改写、Coverage）。

我实际的分工是：

前端代码调试 — 直接在 Chrome DevTools 里打断点。Cmd + P 搜文件、Cmd + Shift + P 搜命令，比切回 IDE 更快。
Node 服务端代码调试 — 用 WebStorm，因为这时 IDE 的优势明显（能直接在源码上打断点、变量面板和编辑器在同一个窗口）。
单元测试调试 — 也用 WebStorm，右键测试文件选 Debug，Jest / Vitest 都开箱可用，这是 IDE 体验最好的场景。

如果只是想让 WebStorm 点一下就用固定的浏览器打开页面（不涉及断点），那就不用碰调试配置——编辑器右上角悬停会出现几个浏览器图标，点哪个用哪个；或者在 HTML 文件上右键 → Open In → Browser。这个功能不需要调试端口，路径固定了就够。