单步调试 vs 单步进入：搞懂这两个操作，Debug少走一半弯路

写代码时遇到 bug，打开调试器，鼠标悬停在“Step Over”和“Step Into”按钮上——它们图标差不多，名字只差一个词，但点错了，可能直接跳进 JDK 源码里绕半天，或者漏掉关键函数里的逻辑错误。这俩不是同义词，是两套完全不同的执行策略。

单步调试（Step Over）：跳过函数体，只看当前行

你写了一行 result = calculateTotal(price, taxRate);，按了 Step Over，调试器会把整个 calculateTotal 当作“一个原子操作”跑完，然后停在下一行。它不关心函数内部怎么算的，只保证这行执行完了，变量 result 已更新。

适合场景：你确认这个函数没问题，或者暂时不想深入——比如调用的是 System.out.println()、工具类 StringUtils.trim()，或你自己刚测过的稳定方法。

单步进入（Step Into）：钻进去，逐行看函数里发生了什么

同样那行 result = calculateTotal(price, taxRate);，按 Step Into，调试器立刻跳进 calculateTotal 方法的第一行，开始一行一行执行它的内部逻辑：

public double calculateTotal(double price, double taxRate) {
    double base = price * 0.9; // ← 停在这里
    return base + (base * taxRate);
}

这时候你才发现，原来折扣写成了 * 0.9，但需求其实是满 100 减 10……这种隐藏在函数内部的错，Step Over 根本发现不了。

一个真实踩坑例子

同事排查支付失败，断点打在：

if (validateOrder(order) && processPayment(order)) {
    sendSuccessNotice(order);
}

他一直用 Step Over，看到 validateOrder() 返回 true，processPayment() 也返回 true，就以为没问题。结果反复失败。后来换成 Step Into，才发现在 processPayment() 里，第三行有个 getAccountBalance(userId) 调用，里面因为缓存 key 拼错，始终返回 null，后续空指针静默吞掉了异常——Step Over 直接跨过了这个致命细节。

小技巧：别硬记图标，看光标位置

IntelliJ 和 VS Code 的图标确实容易混。更可靠的办法是看当前高亮行：如果光标停在函数调用处（比如 getData(); 这整行），按 Step Into 就会进；如果光标已在函数内部某行（比如 return list.size();），再按 Step Into 就继续往下走。而 Step Over 在哪一行，都只执行当前行并停在下一行——它不“选择性深入”，只“机械推进”。

顺手提一句：还有两个常搭档

Step Out（跳出）：你在 calculateTotal 里走了 5 行，突然想快进到它执行完、回到调用它的地方，就按这个；
Force Step Into：某些框架做了代理或字节码增强（比如 Spring AOP），普通 Step Into 可能跳不过去，这时就得用它强行钻进目标方法。