条件断点在断点所在行即将执行前求值，因此arr.push(item)行的arr.length>5判断的是push前的状态；必须设在能访问目标变量的行上，仅支持返回布尔值的单个表达式，不支持语句或赋值。
条件断点不是“加个判断就行”，它依赖当前执行上下文实时求值，写错表达式会导致断点完全不触发，或在错误位置暂停。
条件断点必须写在能访问目标变量的行上
很多人把条件断点加在 for 循环第一行，但实际想监控的是循环体内的 item 或 i。如果该行作用域里还没有声明这些变量，表达式会报 ReferenceError，断点静默失效——你根本看不到任何提示。
- 正确做法：右键点击循环体内某一行（比如
processItem(item)所在行），再选Add conditional breakpoint - 表达式可直接用
i === 8、item.id === "abc123"，无需加var或let - 若变量是闭包内或异步回调中定义的，确保断点设在该回调执行路径上，否则无法访问
条件表达式里不能写语句，只能写单个表达式
常见错误是输入 if (i === 5) debugger; 或 console.log(i); i === 5，这会导致断点创建失败，Chrome 会忽略整个输入框内容，断点变成普通蓝色断点（无条件）。
- 只允许返回布尔值的表达式：
i > 100 && data.length > 0、response?.status === 401 - 支持可选链和空值合并：
user?.profile?.role === "admin" - 不支持赋值、函数调用（除非明确用于判断，如
validate(item) === true）、debugger语句
调试异步逻辑时，条件断点要配合调用栈看执行时机
比如在 fetch().then(() => { ... }) 块里设条件断点，你以为它会在第 3 次请求后停，结果发现根本没触发——很可能因为 Promise 已 resolve，代码早已执行完毕，断点被跳过。
- 优先考虑在 Promise 链的起点设断点，比如
fetch(url)调用行，再用条件url.includes("api/order") - 若需监控多次异步响应，用计数器变量（需全局或外层作用域声明）：
window.requestCount = (window.requestCount || 0) + 1; window.requestCount === 3 - 注意：条件表达式每次都会重新执行，副作用（如自增）会真实发生，可能干扰业务逻辑
断点颜色和禁用状态容易误判
Chrome 用不同颜色区分断点类型：蓝色 是普通断点，金黄色带问号 是有效条件断点，灰色 表示被禁用。但如果你改了代码导致行号偏移，或者 SourceMap 未正确加载，金黄色断点可能挂载到错误行，甚至不生效。
- 每次刷新页面后，检查断点是否还在原位置；若文件来自打包产物，确认已启用
Authored视图并加载了正确的 SourceMap - 禁用断点别只靠点击行号——右键菜单里的
Disable breakpoint更可靠，避免误删 - 批量管理：在
Sources面板右侧Breakpoints区域，勾选/取消勾选复选框可一键启停全部断点
最常被忽略的一点：条件断点的表达式是在断点所在行「即将执行前」求值的，所以它看到的是该行开始执行前的状态。如果你在 arr.push(item) 这行设条件 arr.length > 5，那它判断的是 push 之前还是之后？答案是之前——这点决定了你该把断点设在 push 前还是后。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
