条件断点必须是纯布尔表达式，写语句（如console.log、赋值、if块）会导致静默失效；正确写法为i === 99、user?.id === "admin"等无副作用的JS风格表达式。
条件断点必须是纯表达式，写语句就失效
VSCode 的条件断点不是“加个 if 判断”，而是把输入内容当作 JavaScript（或对应语言）表达式求值。一旦写了 console.log()、i = 0、if (x) { } 这类语句，断点会静默失效——不报错、不提示、也不暂停。
常见错误现象包括：断点图标正常显示，鼠标悬停能看到你写的条件，但程序一路跑完也不停；或者只在第一次触发后就再无响应。
- ✅ 正确写法：
i === 99、user?.id === "admin"、"prod".includes(env) - ❌ 错误写法：
console.log(i)、i++、data.push(x)、myUtil.check(id)（函数调用含副作用） - ⚠️ 字符串比较务必加引号：
status === "error"，写成status === error会查未定义变量 - ⚠️ 可选链安全但非万能：
user?.profile?.age > 18可行，但user.profile.age在user.profile为null时直接报错导致断点跳过
命中次数断点比条件表达式更可靠
当你明确知道“第 N 次执行才要看”，用 >= 100 或 = 5 比写 i === 99 更稳——它不依赖变量名是否存在、是否在作用域内、是否被优化掉，也不触发表达式求值开销。
适用场景很具体：训练循环第 100 个 epoch、重试逻辑的第 3 次失败、大数组遍历中某次特定索引。
- 语法含义要记清：
> 10是第 11 次暂停，% 2是每次偶数次命中都暂停 - 注意它是累计命中次数：若断点在双重循环内，外层每迭代一次，内层每执行一行都算一次
- Java/Python/JS 项目通用，无需改语法；但 Node.js 需
node >= v14.18.0才支持服务端计算，旧版可能仅客户端过滤，漏停
Logpoint 替代 console.log，不中断、不污染代码
想看值又不想停？Log Message 断点是唯一真正“无侵入”的打点方式。它不暂停执行，只往 Debug Console 输出带变量插值的日志，且支持格式化（如 {loss:.4f}）。
和手写 console.log 相比，它不进 Git 历史、不需清理、不影响性能（实测高频打点开销极低），中文内容也完全支持。
- 右键断点 → “添加日志消息” → 输入类似
batch {batch_idx}: loss = {loss.item():.3f} - 变量必须真实存在且作用域可见，否则插值为空或显示
undefined - 不能写语句：
{print(x)}或{x.toString()}会失败；只允许读取型表达式 - 输出位置固定在 Debug Console，不混入浏览器控制台或终端，便于隔离排查
断点不触发？先查这三件事
90% 的“条件断点不生效”问题，根源不在表达式本身，而在环境对齐或作用域理解偏差。
- 确认调试器后端支持：Python 必须用
debugpy（非已弃用的ptvsd），Node.js 查node -v是否 ≥v14.18.0 - 检查 source map 映射：TS/JSX 项目若
launch.json中outFiles或sourceMaps配置错误，VSCode 实际在dist/下设断点，而你在src/上点的红点根本没注册过去 - 验证变量是否真在作用域：打开 Debug Console，手动输入
user看是否返回值；若报ReferenceError: user is not defined，说明它不在当前帧——可能是异步回调、闭包丢失，或变量声明在断点行之后
最易被忽略的是：条件断点求值发生在运行时语言环境中，不是在 VSCode 进程里执行。它无法访问任何外部上下文，也不能触发副作用——这点决定了所有“看起来合理但不工作”的写法，往往都越过了这个边界。
