写代码的时候，谁还没被 bug 折磨过。这时候调试工具就成了救命稻草，而断点就是最常用的手段之一。但你可能只知道点一下就能暂停程序，其实断点也有不同类型，最常见的就是行断点和方法断点。它们看起来差不多，用起来差别却不小。
行断点：精准定位到某一行
行断点应该是大家最熟悉的，就是在代码编辑器的行号边上点一下，出现一个红点，表示程序运行到这里会停下来。比如你在调试一段计算逻辑：
int a = 10;
int b = 20;
int result = a + b; // 在这行设了行断点
System.out.println(result);程序执行到 int result = a + b; 这一行之前就会暂停，你可以查看此时 a 和 b 的值是不是符合预期。这种断点适合你已经怀疑某段具体代码出了问题，想一步步看变量变化的情况。
方法断点：关注的是“入口”而不是“某行”
方法断点不一样，它不是打在某一行上，而是打在整个方法上。比如你在一个类里右键某个方法名，选择“Toggle Method Breakpoint”，就会看到断点符号出现在方法定义的那一行，但它的作用范围是整个方法的入口。
举个例子，有这样一个方法：
public void saveUser(User user) {
if (user == null) return;
validate(user);
userRepository.save(user);
}如果你在这个方法上设了方法断点，那么只要有人调用了 saveUser，不管从哪个地方调的，程序都会停下来。你不需要关心方法内部哪一行代码先执行，只要调用发生，就触发断点。
底层机制不同，性能影响也不同
行断点是 JVM 直接支持的，属于“行级断点”，实现效率高，几乎不影响运行速度。而方法断点依赖的是 JVM 的方法进入/退出事件，底层是通过类加载时织入监控来实现的，开销更大一些。
特别是在频繁调用的方法上设方法断点，比如一个被循环调用的 toString() 方法，程序可能会频繁中断，调试体验会变得很卡。这时候不如直接用行断点，或者加上条件判断再中断。
什么时候用哪种？看场景
你想查一个参数是怎么一步步变成错误结果的，从哪一步开始出问题，行断点更合适。它可以精确控制停在哪一行，配合单步执行（Step Over/Into）一点一点跟进。
但如果你不确定是谁调用了某个方法，或者这个方法被多个地方调用，你想看看调用栈是什么样的，方法断点就方便多了。比如你发现用户数据莫名其妙被保存了两次，怀疑是 saveUser 被误调了多次，直接给它加个方法断点，跑一遍就知道是谁在作怪。
IDE 中的表现也有区别
在 IntelliJ IDEA 或 Eclipse 里，行断点就是一个红色圆点，而方法断点通常显示为一个红色菱形或者带图标的标记。鼠标放上去还能看到提示，告诉你这是方法断点。右键点击断点还能设置条件、是否启用、命中次数等高级选项，不管是哪种断点都支持。
有时候你会发现打了断点却没停下，可能是编译后的字节码和源码不匹配，或者断点所在行没有实际可执行代码（比如空行或注释行）。方法断点还可能出现一种情况：类还没加载进来，断点暂时无效，等类加载后才生效。
掌握这两种断点的差异，能让你在排查问题时少走弯路。别再一上来就在第一行打个红点然后一路 F8 了，合理使用方法断点，能更快锁定调用源头。