真正有效的断点需满足两个条件：代码确实执行到，且作用域包含目标变量；同步逻辑在变量首次赋值后设，异步回调须设在回调体内，避免混淆代码中设断点。
断点设在哪才真正有效
断点不是随便点一行就能抓到问题的。比如你在 for 循环体外设断点，可能永远看不到循环内部变量的真实变化；又或者在异步回调前设断点，但调试器根本停不住——因为执行流早跳走了。真正有效的断点位置要满足两个条件：一是代码确实会执行到（排除被优化掉、被条件跳过、或尚未注册的回调），二是作用域里包含你想观察的变量。
实操建议：
- 对同步逻辑，在目标变量首次赋值后、首次使用前设断点，比如
let result = compute(x);这行之后立刻停，比在函数末尾看更可靠 - 对 Promise 或事件回调，断点必须落在回调函数体内，例如
.then(data => { /* 在这里设 */ console.log(data); }) - 避免在压缩/混淆后的代码里设断点——Atom 无法正确映射源码位置，容易停错行
“Scopes”面板里看不到变量？检查这三件事
Atom 调试界面左侧的 Scopes 面板本该列出当前作用域所有变量，但常出现空白或只显示 this、arguments。这不是插件坏了，而是变量根本没进入当前作用域，或调试器没拿到完整上下文。
常见原因和应对：
- 变量是
const或let声明，但当前执行点不在其块级作用域内（比如在if外看if内声明的变量） - 你正在调试的是打包后的代码（如 Webpack 输出），但没配好 source map 路径，Atom 无法还原原始变量名
- Node.js 版本太低（
）或启动时没加 <code>--inspect参数，导致 V8 调试协议不支持作用域枚举
验证方法：在断点暂停后，直接在调试控制台输入 console.log(yourVarName)，如果输出正常，说明变量存在，只是 Scopes 面板没刷新出来——这时可尝试重启调试会话。
监视表达式（Watch Expression）比看 Scopes 更准
当你需要跟踪一个深层嵌套属性、计算结果或临时组合值时，Scopes 面板基本没用。比如想确认 user.profile.settings.theme === 'dark' 是否成立，或观察 items.filter(x => x.active).length 的实时变化，就得靠监视表达式。
操作要点：
- 在调试面板中找到
Watch区域（通常在右上角），点击+添加新表达式 - 输入合法 JS 表达式，如
response?.data?.items?.length或new Date().toISOString()，Atom 会在每次暂停时重新求值 - 注意：表达式不能有副作用（比如
counter++），否则可能干扰程序逻辑；也不支持await，异步结果得靠回调内设断点 - 多个表达式之间无顺序依赖，但每个都独立执行，频繁写复杂表达式会影响调试响应速度
条件断点不是“高级功能”，而是避免手动重复按 F5 的刚需
当你要找第 17 次循环出错、或某个 ID 为 'usr_9b4x' 的对象处理异常时，手动单步 16 次再看第 17 次，效率极低且易出错。条件断点就是为这种场景存在的。
设置方式（以 atom-ide-debugger-node 插件为例）：
- 右键已设断点的行号 → 选择
Edit Breakpoint - 在弹出框中填入布尔表达式，例如：
i === 17、user.id === 'usr_9b4x'、error != null - 表达式里能访问当前作用域所有变量，但不能调用未定义函数或读取未初始化的引用（否则断点直接失效，调试器跳过）
- 若条件含异步内容（如
await checkPermission()），它不会等待，而是直接判为 false —— 条件断点只支持同步判断
容易忽略的一点：条件断点的表达式本身也会被反复执行，如果里面写了 console.log 或修改了状态，可能掩盖真实问题。上线前务必删掉调试用的条件日志。
