第3行报错，堆栈第行鼠标点上去，溢出红色波浪线下面藏着一句“NullPointerException”。位置你盯着屏幕，解决脑子里就一个念头：这行代码明明只是堆栈第行调了个方法，怎么就空了？溢出

先别急着改。把第3行前后各看五行。位置很多时候，解决问题根本不在报错那一行，堆栈第行而在它上面两行的溢出赋值。比如你写了String name = user.getName()，位置报错在第3行，解决但user是堆栈第行null。你查了数据库，溢出查了接口返回，位置查了配置文件——都没问题。那user从哪来的？从上一个方法传进来的。上一个方法又是从哪拿的？从缓存里。缓存里没有，返回了null。你看，绕了一大圈，根子在第1行那个没判空的缓存读取。

我见过最离谱的一次，同事调了三天，最后发现是第3行调用的工具类里，静态变量被某个测试用例清空了。他死活想不通，因为本地跑得好好的，一上测试环境就炸。你猜怎么着？测试环境多个服务共享同一个JVM，另一个服务的定时任务把那个静态Map给clear了。这种跨模块的“幽灵null”，靠肉眼根本看不出来。

所以我的建议是：第一步，在报错行打上断点，用Debug模式跑一遍，看看到底是哪个对象是null。别嫌麻烦，这一步能过滤掉80%的假象。第二步，如果断点显示对象确实有值，那问题出在方法内部的并发修改上——比如有两个线程同时操作同一个list，一个在遍历，另一个在remove，第3行正好是遍历到被删掉的那个元素。这种时候，把for循环改成Iterator，或者加个同步锁，立刻就好。

还有一种情况，第3行是return list.get(0)，你明明用if (list != null && list.size() > 0)做了判断，但还是报错。那问题出在list本身是个代理对象，比如MyBatis返回的List，它的size()方法可能触发懒加载，而懒加载的session已经关了。这时候你看到的“第3行报错”其实是假象——真正的异常在size()方法内部被吞了，然后抛了个莫名其妙的IndexOutOfBounds。解决办法也简单：在获取list之前，先强制触发一次加载，比如调用list.size()，或者把session的生命周期延长。

最后说个偏方。如果你实在找不到原因，把第3行拆成两行。比如int result = a / b报错，你改成int temp = b; int result = a / temp;。很多时候，拆开之后编译器会给出更精确的提示，或者你会在拆的过程中突然发现——哦，原来b是Integer，自动拆箱的时候是null，所以报的是NullPointerException而不是ArithmeticException。这种低级错误，新手常犯，老手偶尔也会栽。

堆栈不会骗人，但它只告诉你“在哪”，不告诉你“为什么”。第3行只是个坐标，你得顺着坐标往前挖。挖到第1行，挖到方法调用处，挖到数据源头。多数时候，答案就在你眼皮底下，只是你盯着报错那一行看太久，忘了抬头看看周围。