条件断点是普通断点的js表达式增强，需返回布尔值、作用域内变量可见、无副作用；常见失效原因包括条件为假、语法错误、source map失败、异步变量未就绪及hmr导致断点失效。
条件断点不是独立功能，而是普通断点的表达式增强——你已经在某行打了红点，右键选 Edit Breakpoint 填 JS 表达式即可生效。
条件断点表达式怎么写才有效
WebStorm 把条件断点当作一段运行时求值的 JavaScript 表达式，它必须在断点所在作用域内能被正确解析和执行。
- 表达式必须返回布尔值：
userId === 123、items?.length > 5、typeof data === 'object'都合法；console.log('hit')或data = null无效（不返回 true/false） - 变量必须在当前作用域可见：不能在函数外引用函数内声明的
let localVar，也不能在箭头函数体外访问其参数id - 避免副作用操作：不要在条件里调用修改状态的函数，比如
updateCache() && id > 100—— 表达式可能被多次求值（如单步跳过时），导致逻辑错乱 - 异步代码中慎用未定义变量：比如在
setTimeout回调里设条件断点，但表达式里写了res.status，而res是上层作用域变量且尚未赋值，会报ReferenceError并跳过断点
为什么断点打了却从不暂停
条件为 false 是最常见原因，但更隐蔽的问题常出在作用域或执行时机上。
- 表达式语法错误（如少括号、用 = 代替 ==）会导致整个条件被忽略，断点退化为普通断点——建议先在 Chrome Console 或 WebStorm 的 Debug Console 里粘贴表达式验证是否可执行
- 断点设在编译后代码（如
dist/下的 JS）上，而 source map 映射失败：此时即使表达式语法正确，变量名也可能是压缩后的e、t，根本无法匹配原始逻辑 - 在 Promise 链或 async 函数中，变量可能尚未 resolve：比如写
user.id === 5，但user还是undefined或 pending 状态，表达式直接报错并跳过 - Webpack/Vite 的 HMR 热更新后，模块被替换，旧断点绑定失效——刷新页面或重启 dev server 后重设
调试 Node.js 时条件断点的特殊限制
Node.js 环境下，条件断点依赖 V8 的调试协议与源码映射，比浏览器端更敏感。
- 必须启用 source map：TypeScript 项目需确保
tsconfig.json中"sourceMap": true，且 WebStorm Run Configuration 里勾选Enable source maps - 入口文件不能是
dist/index.js：断点必须打在原始src/下的 TS/JS 文件，否则条件里的变量名对不上 - attach 模式下，表达式作用域受限：只能访问已加载模块中的顶层变量或闭包内确定存在的局部变量；动态 require 或
eval()加载的代码不支持条件断点 -
--inspect-brk启动时，首次命中断点前所有条件表达式不会触发——因为 JS 引擎还没开始执行用户代码，变量都不存在
真正容易被忽略的是：条件断点的表达式会在每次执行到该行时重新求值，包括单步（Step Over/Into）过程中。如果你的表达式里有 Math.random() 或 Date.now()，行为就不可预测；调试复杂逻辑前，先确认表达式是纯函数式的、无副作用的、且变量始终可达。
