条件断点表达式必须是纯布尔表达式，仅支持求值为true/false的无副作用表达式；Hit Count适合跳过前N次执行；Log Message可替代console.log输出格式化日志；断点失效应优先排查source map映射问题。
条件断点的表达式必须是纯布尔表达式
VSCode 的 Expression 条件断点只接受能求值为 true 或 false 的表达式，任何副作用或语句都会被拒绝，调试器会静默忽略该条件甚至不触发断点。
常见错误现象包括：断点图标变成灰色、F5运行后完全不暂停、Debug Console 里毫无提示。
-
user.getId() == 1001✅ 安全，调用 getter 无副作用 -
i % 10 == 0✅ 简单计算，性能无压力 -
"dev" in mode✅ 字符串成员判断，开销极低 -
print("hit")❌ 语句，直接失效 -
data.append(1)❌ 修改状态，禁止且危险 -
if x > 5: return True❌ 控制流语法不支持
Java/Python/TypeScript 等语言下规则一致——你写的不是“代码”，而是“条件快照”。调试器每次走到这行，就现场求一次值，不执行、不赋值、不打印。
命中次数（Hit Count）适合跳过前 N 次循环
当你要调试第 1000 次迭代但不想手动点 999 次 F5，Hit Count 是最稳的选择。它不依赖变量状态，只数执行次数，天然规避了表达式求值失败或变量未初始化的问题。
使用场景集中在：大数据遍历、训练 epoch 中后期、重试逻辑的第 N 次失败。
- 右键断点 →
Hit Count→ 输入1000：程序前 999 次路过该行直接跳过，第 1000 次才暂停 - 输入
== 50：仅在第 50 次命中时触发（注意语法支持==、>=、% 5 == 0等） - 输入
> 100：从第 101 次开始每次都停（慎用，可能卡死）
相比表达式条件，Hit Count 在高频循环中更可靠，但无法关联业务逻辑（比如“当 user.status 为 'pending' 时第 3 次”就得回退到表达式 + 计数变量）。
Log Message 不暂停，但能替代 90% 的 console.log
Log Message 本质是“带插值的调试日志”，它不中断执行，却能在 Debug Console 实时输出变量快照，比硬编码 console.log 干净得多，也避免污染生产构建。
典型用法是监控训练循环、HTTP 请求头、状态机流转等无需暂停的上下文。
- 右键断点 →
Log Message→ 输入Batch {batch_idx}: loss = {loss.item():.3f} - 支持格式化：
{x:.2e}、{name?.length || 0}（只要表达式合法） - 中文没问题：
用户 {user.name} 登录失败，错误码 {err.code} - 不能写
console.log(...)或if，否则整个 logpoint 失效
注意：它只在调试会话中生效，打包后自动剔除，不影响运行时性能——这点比埋点式 console.log 安全得多。
条件断点失效时优先检查 source map 和断点位置
断点没反应？大概率不是条件写错了，而是 VSCode 根本没把代码行和实际执行位置对上。
尤其在 TypeScript、Webpack/Vite 构建项目、Jupyter Notebook 中，source map 错位或缺失会导致断点“悬空”——红点还在，但调试器找不到对应位置。
- 确认
tsconfig.json中"sourceMap": true已启用 - 检查
.vscode/launch.json是否配置了正确的outFiles或sourceMapPathOverrides - 在 Debug Console 手动输入变量名，看能否取到值：取不到 → 源映射失败；取得到但断点不触发 → 条件表达式问题
- 前端项目注意：Chrome DevTools 里能看到断点灰掉，说明 source map 加载失败
真正难调的从来不是条件怎么写，而是“调试器到底有没有看到这行代码”。先验真这个前提，再折腾表达式。
