条件断点必须设在变量i声明并活跃的循环体内代码行，如console.log(i)处；Node.js需≥v14.18.0、启用sourceMaps且变量在当前作用域；禁用赋值、函数调用、可选链等非常规表达式。
条件断点怎么写才在循环里真正生效
直接写 i === 100 很可能不触发——不是语法错，而是变量作用域或执行时机不对。循环体内的 let i 是块级作用域，但如果你把断点设在 for 外部、或异步回调里，i 根本不可见。
常见错误场景：
- 在
setTimeout(() => { console.log(i); }, 100)里设i > 90：外层循环早已跑完，i值固定为100，条件恒假 - 用
var i声明却在闭包外设断点：变量提升导致作用域混乱，调试器读到的可能是上一轮残留值 - TS 编译后变量名被压缩（如
_a），但你仍按源码写user.id：source map 映射失败时，调试器找不到对应符号
正确做法是：断点必须打在 i 真正声明并活跃的那行代码上，比如 console.log(i); 这一行，并确保该行属于当前循环体内部。
Node.js 项目里条件断点不触发？先查这三件事
VSCode 的条件断点依赖 Node.js 的 V8 Inspector 协议，低于 v14.18.0 的版本会静默忽略条件表达式，只当普通断点用。
- 运行
node --version，确认 ≥v14.18.0 - 检查
launch.json中"sourceMaps": true已启用，且项目生成了有效的.js.map文件（TS/JSX 项目必开） - 打开 Debug Console，输入条件中用到的变量名（如
i），如果返回ReferenceError，说明它不在当前帧作用域，断点位置错了
另外，ts-node 启动时若没配 sourceMaps: true，断点会绑到编译后 JS 上，而你编辑的是 TS 源码——此时加的条件表达式根本没机会求值。
比条件断点更稳的“第 N 次触发”方案
想停在第 5 次 API 响应处理？别硬靠 hitCounter === 5。Hit Count 断点（右键 → Hit Count → 输入 5）看似简单，但在 Promise.all、事件监听器、多线程调用路径下，计数器是全局累计的，不区分来源，极易误判。
推荐手动加计数逻辑，明确可控：
let hitCounter = 0;
fetch('/api/data').then(response => {
hitCounter++;
if (hitCounter === 5 && response.status === 200) {
debugger; // 此处必停，无需依赖调试器计数机制
}
return response.json();
});
这种写法绕过 source map 映射、跨文件调用、异步调度顺序等所有干扰项，适合调试关键路径。复杂条件（如 “第 5 次且用户角色为 admin”）也只需扩展 if 判断，不增加调试器负担。
表达式里哪些东西绝对不能写
VSCode 条件断点底层用 JS 引擎求值，但仅支持纯表达式，任何带副作用或需运行时支持的语法都会让断点变灰、失效。
- 不能写赋值语句：
i = 5（这是语句，不是表达式） - 不能调用函数：
Array.isArray(arr)或isValid()，多数 Node.js 调试环境报ReferenceError - 不能用可选链：
user?.id === 123，旧版 V8 不支持，改用user && user.id === 123 - 字符串必须加引号：
status === "done"，写成status === done会被当变量查 - 正则字面量无效：
/error/.test(msg)不工作，改用msg.includes('error')
最安全的写法是：只用当前作用域变量 + 简单比较运算符 + 逻辑与/或，其余全靠手动 debugger 或日志兜底。
