三目运算符是表达式而非语句，仅适用于返回值场景；嵌套过深易引发可读性与空指针问题；boolean包装类参与时需防自动拆箱异常；性能不优于if-else，关键在避免重复计算。
三目运算符的语法结构和基本用法
Java 里的 ? : 不是万能替代品，它只适用于「返回值」场景，不能执行语句。比如你不能在分支里调用 System.out.println() 或给多个变量赋值，否则编译直接报错：not a statement。
它的本质是表达式，必须有明确的返回类型，且两个分支的结果类型要能统一（自动提升或存在共同父类）。常见写法是配合变量赋值或 return 使用：
String status = score >= 60 ? "pass" : "fail";
注意：如果 "pass" 是 String，而 "fail" 是 Object（比如误写了 new Object()），编译器可能推导出 Object 类型，后续调用 .length() 就会报错。
嵌套三目运算符容易引发的可读性与空指针问题
嵌套三层以上就该警惕了——不是语法不允许，而是人眼很难快速判断逻辑走向，而且一旦某个中间表达式为 null，整个链式调用就崩了。
立即学习“Java免费学习笔记（深入）”；
比如这个写法看着紧凑，实则危险：
String name = user != null ? user.getProfile() != null ? user.getProfile().getName() : "anonymous" : "anonymous";
更稳妥的做法是拆成局部变量，或者用 Optional：
- 优先用
Objects.requireNonNullElse()处理默认值 - 避免在条件部分调用可能抛
NullPointerException的方法（如user.getProfile().getName()） - 如果真要用嵌套，确保每个 ? 前的表达式都已判空，或提前 guard 掉 null 情况
布尔类型与包装类混用时的自动拆箱陷阱
当你把 Boolean 包装类对象放进三目运算符，比如 flag != null ? flag : false，表面看没问题，但若 flag 是 null，JVM 会在比较前尝试拆箱，触发 NullPointerException。
这不是三目运算符的问题，而是 Java 对包装类在数值/布尔上下文中的隐式拆箱机制导致的。正确写法是显式判空：
boolean result = (flag != null && flag) ? true : false;
或者更简洁地：
boolean result = flag != null ? flag : false;
关键点在于：只要三目运算符的两个分支都是 boolean 基本类型，就不会触发对 flag 的拆箱；但如果写成 flag ? true : false，flag 就必须先拆箱，null 就挂了。
性能和字节码层面的真相：它并不比 if-else 快
别被“简化”二字误导——三目运算符生成的字节码和对应 if-else 几乎一样，JIT 编译器也基本会做相同优化。所谓“性能优势”纯属误解。
真正影响性能的是表达式本身的复杂度，比如在条件分支里反复调用耗时方法：
- 错误示范：
val > 0 ? expensiveCalc() : expensiveCalc() * -1→ 算两次 - 正确做法：先存结果，再用三目选值：
int tmp = expensiveCalc(); val > 0 ? tmp : -tmp
另外，某些老旧 Android 版本（API incompatible types，这时候老老实实用 if-else 反而更稳。
三目运算符最常被忽略的其实是类型收敛规则——当两个分支类型不一致时，Java 会按固定规则向上找最小公共类型，有时结果不是你预期的 String 而是 Object，尤其在涉及字符串拼接、lambda 表达式或泛型方法调用时，编译错误信息还特别绕。遇到报错先检查分支类型的隐式转换路径，比硬调更容易定位。
