VS Code条件断点需先设普通断点再右键编辑，不支持空白行直接添加；表达式须为无副作用的JS语法，作用域受限于断点行上下文，且依赖sourceMap映射源码变量名。
条件断点必须先打普通断点再右键编辑
VSCode 不支持直接在空白行号区右键添加条件断点。你得先单击行号左侧灰色区域打一个普通断点（红色圆点），然后右键该断点，选择 Edit Breakpoint 才能输入表达式。误以为“右键某行→Add Conditional Breakpoint”就能生效，是新手最常卡住的第一步。
这个设计背后是调试协议的限制：断点需先被调试器注册为有效位置，条件才是附加属性。没基础断点，VS Code 甚至不会把那行纳入断点管理列表。
- 普通断点打错行？删掉重打——条件断点不会自动随代码移动更新
- TS/JSX 项目务必确认
launch.json中sourceMaps设为true，否则断点可能绑到编译后文件，条件表达式查不到源码变量名 - Python、Java、.NET 等语言同样走这套流程，但表达式语法仍用 JS 风格（如
x == 5，不是x == 5的 Python 写法）
条件表达式只能写纯 JS 计算式，不能有副作用
VS Code 把你写的表达式原样传给运行时（如 V8、debugpy、delve）求值，它不是在编辑器里执行的。所以任何会产生副作用或依赖环境的操作都会失败或静默忽略：
- 禁止赋值：
i = 5是语句，必须改成i === 5 - 禁止函数调用：
Array.isArray(arr)在多数 Node.js 调试场景会报ReferenceError；fetch()、console.log()直接不支持 - 禁止解构、模板字符串、正则字面量：
/abc/.test(s)会报错，改用new RegExp("abc").test(s) - 字符串比较必须加引号：
status === "done"，写成status === done就去找变量done，找不到就失效
变量作用域陷阱：断点停在哪一行，就只看那一行能访问到的变量
条件表达式求值发生在断点所在行「即将执行前」，所以它能看到的变量，严格受限于当前执行上下文的作用域。这不是 IDE 智能补全的问题，而是调试器真实读取的栈帧数据。
-
let/const声明的变量只在块内有效：在for循环外设断点，却写i === 10，i根本不可见 - 异步回调里的变量，在外层设断点时大概率未定义：比如
setTimeout(() => { x = 1 }, 100)，在外层写x === 1永远不触发 - 对象属性访问要防
undefined：user.id === 123在user为null时崩掉，得写成user && user.id === 123或(user?.id || 0) === 123 - TS 编译后变量名可能被压缩（如
_a），但条件断点仍要用源码名（userId），VS Code 依赖 source map 映射——混淆构建后这层映射大概率失效
性能敏感：复杂条件会让调试变卡，甚至挂起
每次执行到该行，调试器都得完整跑一遍你的条件表达式。如果它涉及大数组遍历、深对象递归、JSON.stringify() 或正则匹配，延迟会肉眼可见，高频循环里尤其明显。
- 避免
arr.find(x => x.name === "test")，改用arr.some(x => x.name === "test")或更简单的arr.length > 5 - 别在条件里调用耗时方法：
Date.now() > 1720000000000可以，但performance.now() > 1000在某些 runtime 下不稳定 - 多个条件断点叠加时，VS Code 不合并优化，每个都独立求值——别在
while(true)里乱加 - 真需要复杂判断？不如设普通断点，停住后去
Debug Console手动输表达式，反而更快更可控
