三目运算符是表达式而非简化if，必须有明确返回类型，两分支需兼容或可隐式转型；嵌套易出错且可读性差；禁止副作用、避免null拆箱异常；无作用域限制。
三目运算符的语法结构必须严格匹配类型
Java 三目运算符 ? : 不是“简化 if”，而是表达式，它必须有明确的返回类型。编译器会尝试推导两个分支（? 后和 : 后）的公共类型，一旦类型不兼容，就会报错——比如一边是 int，另一边是 String，连编译都过不去。
常见错误现象：Type mismatch: cannot convert from String to int 或 Incompatible types。
- 两个分支必须能归到同一个类型，或存在隐式向上转型（如
int和long→long） - 避免混用基本类型与包装类（如
int和Integer），尤其在泛型上下文中容易触发自动拆箱异常 - 如果分支之一是
null，需显式指定类型，例如(flag ? "a" : (String) null)，否则可能推导为Object导致后续调用失败
嵌套三目运算符极易引发可读性与逻辑陷阱
嵌套写法像 a ? b : c ? d : e ? f : g 看似省代码，实则难调试、易出错。Java 按右结合解析（即等价于 a ? b : (c ? d : (e ? f : g))），但人眼习惯左读，稍不留神就理解反了。
使用场景：仅适合单层、逻辑清晰的简单判断，比如状态映射、默认值兜底。
立即学习“Java免费学习笔记（深入）”；
- 超过一层嵌套，立刻改用 if-else；IDE 警告 “Nested conditional operator” 不是矫情，是真实维护成本信号
- 注意短路行为：只有被选中的分支才会执行，但两个分支若含方法调用（如
flag ? getValue() : getDefault()），未选中分支不会触发，这点和 if 一致 - 不要指望靠括号强行“修复”可读性，
(a ? b : (c ? d : e))仍比 if 多两层视觉嵌套
自动拆箱导致的 NullPointerException 隐形雷
当三目运算符用于包装类型（如 Integer）且某一分支为 null 时，若结果被赋给基本类型变量，运行时会炸——因为 Java 试图对 null 执行自动拆箱。
错误示例：int x = flag ? 123 : null; 编译通过（JDK 8+ 允许推导为 Integer），但运行时报 NullPointerException。
- 根本原因是：编译器将整个表达式推导为
Integer，赋值给int时触发null.intValue() - 修复方式：显式处理 null，如
int x = flag ? 123 : Objects.requireNonNullElse(defaultObj, 0);，或直接用 if - Map.get() 后接三目尤其危险，例如
map.get("key") != null ? map.get("key") : 0实际查了两次，还可能因并发修改导致结果不一致
性能差异几乎可以忽略，但语义误用代价很高
有人说三目比 if 快，其实 JVM 对两者优化程度基本一致；真正影响性能的是表达式内部逻辑，不是语法形式本身。但语义错用——比如把有副作用的操作（日志、计数、IO）塞进三目分支里——会让代码变成定时炸弹。
典型反模式：result = isValid() ? logAndReturn(true) : logAndReturn(false);，看似简洁，实则把控制流和副作用耦合在一起，难以单元测试，也违背表达式应无副作用的直觉。
- 三目只该用于纯计算、无状态、无 IO、无修改的场景
- 一旦分支中出现
System.out.println、counter++、service.update()，立刻重构为 if - 静态分析工具（如 SonarQube）通常会标记这类用法为 “Avoid side effects in conditional operator”
最常被忽略的一点：三目运算符没有作用域，所有变量必须在外部声明好；而 if 块内可定义局部变量，这个限制在需要临时对象或资源管理时会突然卡住你。
