断点必须设在原始源文件（如app.js、server/index.ts）中，而非dist/编译文件；TS项目需开启sourceMap并勾选WebStorm的Enable source maps；优先设在中间件函数内，避免顶层或动态加载代码。

断点打在哪才真正生效

断点不命中，八成是因为设错了位置。WebStorm 只能对 V8 实际执行的原始 JS 文件设有效断点，对 dist/ 下编译产物、eval 动态代码、或 Webpack 处理后路径映射错乱的文件，基本无效。

• 必须打在 src/ 或项目根目录下的原始源文件里，比如 app.js、server/index.ts，而不是 dist/index.js
• TypeScript 项目要确认 tsconfig.json 中 "sourceMap": true 已开启，且 WebStorm 运行配置里勾选了 Enable source maps
• 优先在中间件函数内部设断点，例如 router.get('/user', (req, res) => { /* 这里打 */ })；顶层 app.listen() 行几乎无法停住
• 避免在 new Function()、dynamic import() 加载的代码里设断点——这些代码不经过标准模块加载流程，调试器无法关联源码

Debug 按钮点了却没反应？检查这三件事

点击 绿色甲虫图标 后控制台一闪而过、进程秒退、或 Debug 窗口根本不弹出，不是环境坏了，而是配置漏项。

• 确认 Node.js 和 JavaScript Debugger 插件已在 Settings | Plugins → Installed 中启用
• Node interpreter 必须指向真实可执行路径（如 /usr/local/bin/node），不能留空或只写 “Project default” 却未实际配置解释器
• 若用 npm start 启动，别直接 Debug package.json 脚本——先右键该脚本选 Run 'start' 确认能跑通，再新建 Node.js 类型配置，Working directory 设为项目根目录，JavaScript file 填实际入口（如 ./bin/www 或 index.js）

调试已运行的 Node 进程（attach 模式）

微服务、Docker 容器或后台常驻进程没法重启，只能 attach 接入。但 host 写错就白忙活。

NodeMaven – Premium Proxies for Account Management, Automation, and Scraping

提供端到端的高端代理设置和使用指导，包括代理类型选择、地区定向、访问配置、API密钥验证和监控。

下载

• 启动目标进程时加参数：node --inspect-brk=0.0.0.0:9229 ./index.js（--inspect-brk 会阻塞直到调试器连接）
• WebStorm 新建配置 → Attach to Node.js/Chrome → Host 填 localhost，Port 填 9229
• 如果进程在 Docker 里，宿主机必须映射端口（-p 9229:9229），且 --inspect-brk 的 host 不能写 127.0.0.1（容器内无法回环）
• attach 后断点仍需设在源码上，WebStorm 会自动匹配已加载模块——前提是源码路径与进程内 require.resolve() 返回的路径完全一致

条件断点为什么总不触发

条件断点本质是运行时求值的 JS 表达式，不是“开关”，它依赖作用域、执行时机和 source map 精确性。

• 表达式必须返回布尔值：userId === 123 合法，console.log('hit') 或 data = null 无效
• 变量必须在当前作用域可见：不能在函数外引用 let localVar，也不能在箭头函数体外访问其参数 id
• 异步代码中慎用未就绪变量：比如 async 函数里写 user.name === 'admin'，但 user 还是 undefined 或 pending，表达式报错并跳过断点
• --inspect-brk 启动时，首次命中断点前所有条件表达式不会触发——因为 JS 引擎还没开始执行用户代码，变量都不存在

最易被忽略的是：条件断点会在每次执行到该行时重新求值，包括单步（Step Over/Into）过程中。含 Date.now() 或 Math.random() 的表达式会让调试行为不可预测。