条件断点必须是纯表达式而非语句，VSCode调试器仅求值不执行语句；正确写法如i === 99，错误写法如console.log()；应通过“编辑断点”而非“添加条件断点”设置以确保作用域正确。
条件断点必须是纯表达式，不是语句
VSCode调试器在命中断点时，会把输入内容当作对应语言的表达式求值——它不执行语句，也不允许副作用。写错类型，断点直接静默失效，连报错都不会有。
常见错误现象包括：断点图标没变化、悬停看不到条件、程序从不暂停。根本原因往往是用了console.log()、i = 0、if (x) { }这类语句结构。
- ✅ 正确写法：
i === 99、user?.id === "admin"、"prod".includes(env) - ❌ 错误写法：
console.error("hit")、data.push(item)、return false - Java 用户注意：
userId.equals("admin")可用，但userId == "admin"几乎总为false（字符串引用比较） - Python 用户注意：表达式语法就是 Python 本身，如
len(items) > 5、"error" in log_msg，变量必须在当前作用域真实存在
右键“编辑断点”才是正路，不是“添加条件断点”
很多人卡在这一步：在空白行号区右键，选了“添加条件断点”，结果输完条件没反应。其实这是快捷入口，底层逻辑和“编辑断点”完全一致，但容易因上下文缺失导致表达式校验失败或作用域不可见。
真正可靠的操作路径只有一条：先左键点出行号旁红点设普通断点 → 再右键该红点 → 选“编辑断点”。这时调试器能准确绑定当前行的作用域，变量名、this、局部状态都可被正确解析。
- 编辑后，断点图标外观不变，但鼠标悬停会显示你写的条件，比如
i === 99 - 禁用断点时图标变灰；要删除，得再点一次红点，或右键选“删除断点”
- 如果悬停没显示条件，说明表达式未通过校验——大概率是语法错误或变量不可访问
命中次数断点比条件表达式更轻量、更可靠
当目标明确是“第 N 次执行才看”，比如遍历大数组、训练第 100 个 epoch、重试逻辑中第 3 次失败时介入，用 Hit Count 比写i === 99更安全。
它不依赖变量是否存在、是否命名一致、是否在作用域内，也不触发表达式求值开销。调试器只做计数，无额外运行时负担。
- 设置方式：右键断点 → “编辑断点” → 在弹出框里填数字，如
100（表示第 100 次命中时暂停） - 注意：
Hit Count是累计命中次数，不是“当前循环索引”。若断点在嵌套循环内，外层每次迭代都会计入 - 适用场景优先级：确定次数 > 确定变量值 > 复杂布尔组合。越简单，越不容易因环境差异失效
Log Message 断点适合高频观测，但插值变量必须真实存在
想看值又不想中断？Log Message 断点是唯一不暂停的“断点”类型，输出进 Debug Console，支持变量插值，且不污染源码。
但它对变量名极其敏感：插值{user.id}要求user非 null 且有id属性；{undefined_var}只会输出undefined，不会报错，容易误判。
- 设置方式：右键断点 → “添加日志消息” → 输入类似
batch {i}: loss = {loss:.4f} - 中文内容完全支持，如
用户 {user.name} 登录失败，但{}内仍需合法表达式 - 性能影响极小，适合每轮循环都打点；但若变量在某次执行中突然不可见（比如作用域退出），插值结果为空或
undefined，这点极易被忽略
i === 99，在 for 循环内有效，在异步回调里可能根本找不到i；同一个user.id，在 Log Message 里显示正常，在条件断点里却报“无法解析”，往往只是因为那一帧里user还没初始化。 
