条件断点是调试高频循环或复杂状态的刚需，需在作用域内用纯js布尔表达式（如i === 42）、命中次数（> 9）或日志点（{user.id}）实现，避免副作用与作用域错误。
条件断点不是“高级功能”，而是调试高频循环或复杂状态时的刚需——不用它，你大概率会手动按 50 次 F5。
表达式条件断点：只在变量满足布尔条件时暂停
这是最常用也最容易出错的一类。关键在于：表达式必须在断点所在行的作用域内可求值，且不能有副作用（比如调用 console.log() 或修改变量）。
- 正确写法：
i === 42、user?.id === "admin"、response.status >= 400 - 错误写法：
console.log(i); i === 42（调试器不支持多语句，且副作用会导致行为不可预测） - 注意 null/undefined 安全：用可选链
user?.role === "vip"比user.role === "vip"更稳妥 - 字符串比较别漏引号：
status === "loading"不是status === loading
命中次数断点：跳过前 N 次执行，直击目标迭代
适合处理数组遍历、事件重复触发、初始化后第 N 次调用等场景。VS Code 支持的语法直接写在条件框里，不需额外关键字。
-
> 9→ 第 10 次执行该行时暂停（跳过前 9 次） -
= 1→ 仅第 1 次执行时暂停 -
% 2→ 所有偶数次执行（第 2、4、6…次）都暂停 - 实际效果取决于“执行该行”的次数，不是函数调用次数——比如在
for循环体第一行设= 5，就是第 5 次进入循环体时停
日志点（Logpoint）：不暂停，只输出，替代临时 console.log
它不是断点，是“带变量插值的 printf”。调试控制台会实时打印，代码继续跑，完全无侵入。
- 写法：
用户 {user.id}，状态 {status}，耗时 {Date.now() - start} - 变量名必须用大括号包裹，且必须在当前作用域存在；不支持表达式如
{user.id.toString().toUpperCase()} - 适合性能敏感场景：你想看每轮循环的
i值，又不想打断执行节奏 - 注意：日志点输出在「调试控制台」，不是「终端」或「问题面板」
条件断点失效？先检查这三件事
条件断点不触发，90% 是环境或作用域问题，不是 VS Code bug。
- 确认调试器已启动对应环境：Node.js 项目要用
node调试配置，前端用chrome或pwa-chrome，Jupyter 单元需启用 Jupyter 扩展调试模式 - 确认变量在该行确实“可见”：比如在
if块内设断点，条件里用data，但data是else分支声明的——它此时未定义，表达式恒为 false - 避免在异步回调或闭包中依赖外部变量名冲突：若外层有
id，回调里又声明了const id = ...，条件里的id默认取最近作用域，容易误判
真正难的不是设置，而是判断“该在哪一行设、用哪种条件、变量是否就绪”——这些没法靠菜单点出来，得看代码上下文和运行时数据流。
