VSCode条件断点需先打普通断点再右键“Edit Breakpoint”输入纯JS风格布尔表达式（如x===5），支持当前作用域变量但禁用函数调用和副作用，须使用官方调试器（如Python用debugpy）。
条件断点不是“高级功能”，而是你本该默认启用的调试基本功——只要调试器支持，它就该比 console.log 更早出现在你的排查流程里。
VSCode条件断点怎么加？右键+纯表达式是唯一正解
必须先在行号左侧点击打一个普通断点（红点），再右键它 → “Edit Breakpoint” → 输入表达式。没有“Add Conditional Breakpoint”菜单项可直接点，也没有插件需要装。
- Node.js / TypeScript / JavaScript 项目：写 JS 风格表达式，如
i === 500、user?.role === "admin" - Python 项目（用
debugpy）：同样写 JS 风格表达式，不是 Python 语法，user.id == 123可以，但user.get_name()会报错 - PHP 项目（用
xdebug或php-debug）：支持 PHP 风格表达式，如$status === "error"、isset($data['id']) - 别写
if (x > 10) { ... }—— 条件断点只接受求值后为布尔值的纯表达式，带语句块或赋值（i = 5）会导致断点静默失效
为什么断点加了却不触发？三个关键检查点
断点不命中，90% 情况下不是表达式写错了，而是环境没对齐。
- 确认调试器后端真正支持服务端条件计算：Python 必须用
debugpy（非已弃用的ptvsd），Node.js 要node >= v14.18.0，旧版可能只做客户端过滤，漏停或卡顿 - 检查
launch.json中的sourceMaps和outFiles：TS/JSX 项目若编译后路径映射错误，VSCode 实际在调试dist/index.js，而你在src/index.ts上设的断点根本没注册过去 - 打开“调试控制台”，手动输入表达式中用到的变量名（如
user），看是否返回有效值；如果报ReferenceError: user is not defined，说明它不在当前作用域——可能是异步回调、闭包丢失，或变量声明在断点行之后
条件表达式里能写多复杂？越简单越可靠
表达式是在运行时由调试协议（DAP）传给语言运行时求值的，不是在 VSCode 进程里执行。这意味着它无法访问任何外部上下文，也禁用副作用。
- 允许：
count > 100、Array.isArray(items) && items.length > 0、id != null && id % 7 === 0 - 禁止：
console.log("hit")、localStorage.getItem("token")、/error/.test(msg)（部分 Node 版本解析失败）、myUtil.validate(data)（函数调用） - 字符串比较务必加引号：
status === "pending"，写成status === pending就是查未定义变量 - 对象属性访问前加空值检查：
data?.user?.id === "abc"，比data.user.id === "abc"更安全
命中次数断点比条件更稳的两种场景
当你要定位“第 N 次执行”而非“某个具体值”时，命中次数断点几乎零出错，且无表达式解析开销。
- 循环体内部调试：比如想看第 100 次迭代的状态，设命中次数为
100，比写i === 99更可靠——避免i被闭包捕获错、被异步改写、或循环本身带continue跳过某次 - 高频事件回调（如滚动、输入）：条件断点在每帧都执行表达式，容易拖慢 UI；命中次数设为
5，只在第 5 次触发，既抓到现场又不影响体验
真正难的从来不是“怎么加断点”，而是判断该用条件、命中次数，还是日志点——这取决于你到底想回答什么问题：是“值对不对”，“次数够不够”，还是“它路过时长啥样”。选错类型，调试效率就掉一半。
