java 14起nullpointerexception默认显示具体变量名，如“cannot invoke 'string.length()' because 's' is null”；由-xx:+showcodedetailsinexceptionmessages控制，java 15+强制启用；仅对方法调用和字段访问生效，不适用于显式throw、反射、lambda及android。
NullPointerException堆栈里终于有变量名了
Java 14 开始，NullPointerException 的默认报错信息变“聪明”了——它会告诉你到底是哪个变量为 null，而不是只甩给你一行“at MyClass.doSomething(MyClass.java:23)”。前提是没关掉这个特性（默认开启）。
常见错误现象：升级到 Java 14+ 后，发现同样的空指针代码，报错信息突然多了一段类似 “Cannot invoke \"String.length()\" because \"s\" is null” 的描述。这不是 IDE 插件干的，是 JVM 自带的。
- 该行为由 JVM 参数
-XX:+ShowCodeDetailsInExceptionMessages控制（Java 14 默认true，Java 15+ 强制启用，不可关闭） - 仅对
NullPointerException生效，其他异常如ArrayIndexOutOfBoundsException不受影响 - 不依赖源码调试信息（
.class文件无需-g编译），但要求字节码中保留局部变量表（现代javac默认保留） - 如果用 ProGuard / R8 混淆且开启了
allowaccessmodification或裁剪了调试信息，可能退化为老式报错
链式调用 a.b.c.d() 报错时，到底哪个环节是 null？
这是增强机制最实用的场景。以前只能靠断点或日志猜，现在 JVM 能定位到具体字段或临时变量。
使用场景：Spring 中写 user.getAddress().getCity().toUpperCase()，报错不再笼统说“空指针”，而是明确指出 “Cannot invoke \"Object.toString()\" because \"user.getAddress().getCity()\" is null”——注意，它甚至还原了表达式片段。
立即学习“Java免费学习笔记（深入）”；
- 只对“方法调用”和“字段访问”操作生效（
a.b、a.m()），数组访问a[i]和强制类型转换(String) o不参与推导 - 如果中间某步是
return null的方法调用（比如getUser().getName()返回null），JVM 能识别出getUser()的返回值为null，但不会进一步追溯getUser方法内部逻辑 - 涉及自动拆箱（如
int i = obj.getValue();，而getValue()返回null的Integer）也会被标注为 “Cannot unbox because \"obj.getValue()\" is null”
为什么有些 null 报错还是没变量名？
不是所有 NullPointerException 都能精准定位。关键看抛异常的位置是否落在 JVM 可分析的字节码模式内。
常见失效情况：
- 手动
throw new NullPointerException()—— 这属于显式抛出，不触发增强逻辑 - 通过反射调用（
Method.invoke()）触发的空指针，JVM 无法还原原始表达式 - lambda 表达式内部、方法引用（
String::length）中发生的空指针，受限于字节码结构，可能只显示 “Cannot invoke \"String.length()\" because \"<parameter>\" is null</parameter>”，其中<parameter></parameter>是占位符，非真实变量名 - Android（Dalvik/ART）不支持该特性，即使编译成 Java 14+ 字节码也无效
生产环境要不要关掉这个特性？
不需要，也不建议关。它不增加运行时开销，只在异常实际抛出时才生成额外文本，且字符串拼接开销极小。
但要注意兼容性边界：
- Java 14 必须显式加
-XX:+ShowCodeDetailsInExceptionMessages（部分旧版容器镜像默认未开启） - Java 17+ 完全移除了该开关，强行加参数会警告并忽略
- 某些安全审计工具或日志解析系统若硬编码匹配旧式堆栈格式（例如正则匹配 “
NullPointerException” 后固定跳过几行），可能因新增描述文本导致解析失败 - 如果应用自己捕获
NullPointerException并重抛为自定义异常（如throw new ServiceException(e)），原始增强信息会丢失——这时候得在包装前读取e.getMessage()并透传
真正容易被忽略的是：增强信息依赖 JIT 编译后的字节码结构，刚启动时（特别是 `-Xint` 解释执行模式下）偶尔出现降级，等热点代码编译后就恢复正常。别一上来就怀疑配置错了。
