条件断点是普通断点的进阶用法，允许在满足特定布尔表达式（如i == 3或status === "failed"）时暂停执行，需先设普通断点再右键编辑，且依赖调试器服务端计算才稳定可靠。
条件断点不是“高级功能”，而是排查偶发 Bug 最直接有效的手段——只要调试器支持，它就能在特定变量状态出现时精准暂停，避免手动翻几十次循环或等半天复现。
条件断点怎么设？右键已有断点再编辑
必须先在行号左侧灰色区单击打一个普通断点（红点），再右键它 → 选择 Edit Breakpoint → 输入纯布尔表达式。不能跳过这一步直接“右键某行设条件断点”，VSCode 不识别。
- 表达式写
x === 5，不是if (x === 5)或return x === 5；删掉所有语法包裹 - 字符串比较务必加引号：
status === "failed"，写成status === failed会被当成未定义变量 - 对象属性访问要防
undefined：user && user.id === 123比user.id === 123安全得多 - 数组长度判断别裸写
items.length > 0，改用Array.isArray(items) && items.length > 0
为什么断点总不触发？先看调试器是否真支持
条件逻辑是否由运行时执行，决定了它靠不靠谱。客户端过滤（比如旧版 ptvsd）会漏停、卡顿；服务端计算（如 debugpy、Node.js inspector、delve 1.7+）才稳定。
- Python 项目确认用的是
debugpy（非已弃用的ptvsd），检查launch.json中type是python且没硬编码旧插件路径 - Node.js 项目基本无坑，但若用
ts-node启动，需配sourceMaps: true并确保.js.map文件存在 - Go 项目检查
delve版本：dlv version输出中Delve Debugger行应 ≥ v1.7.0 - 打开调试控制台，触发一次断点暂停，搜日志里有没有
[Debug] Condition breakpoint hit—— 没这句，说明条件被静默忽略
异步/循环场景下怎么写条件才不翻车
闭包变量、重用计数器、未初始化对象，在条件断点里极易误判。它的求值时机是“该行即将执行前”，作用域只锁定当前帧。
- 在
for (let i = 0; i { console.log(i); }, 100); }的回调里设i > 90，大概率失效——i已被外层循环改写完毕，实际值是100 - 想监控第 5 次 API 返回，优先在响应处理函数内设断点，条件写
response?.data?.length > 0 && callCount === 5（前提是callCount是闭包内可访问的计数器） - 不确定变量是否存在或是否为 null/undefined，一律用空值合并或逻辑与：
(data?.items?.[0]?.id || 0) === 42 - 复杂判断建议先用日志点（Logpoint）输出关键字段，确认值范围后再转条件断点
性能和兼容性容易被忽略的点
条件断点每次执行都需求值，高频代码里滥用会导致明显卡顿，甚至掩盖真实性能问题。
- 不要在每轮循环体第一行设
i % 1000 === 0这类条件——它仍会执行 999 次无意义判断；改用命中次数断点（Hit Count）更高效 - 某些嵌入式调试协议（如部分 gdb 封装的 C++ 配置）根本不支持条件逻辑，VSCode 会静默降级为普通断点，图标颜色也不变，毫无提示
- TypeScript 项目若
sourceMaps未启用或映射错误，条件表达式可能读到错误作用域的变量，表现为“变量名存在但值始终 undefined” - 调试控制台里能输
user.id看到值，不代表条件断点里也能用——后者受限于调试器对表达式求值的支持程度，尤其涉及 getter 或 Proxy 对象时
