三元运算符仅适用于简洁赋值场景，因其是表达式且必须返回兼容类型的值；禁止用于副作用操作、多分支逻辑或嵌套过深，类型推断取决于分支表达式而非条件本身，性能与if-else无差异。
三元运算符适合赋值场景，不适合多分支或副作用逻辑
Java 三元运算符 ? : 的本质是**表达式**，它必须返回一个值，且两个分支（true 和 false 分支）的类型需兼容（可统一为某共同类型）。这意味着它天然适合「根据条件决定一个变量该取什么值」这种简洁赋值场景，而不是替代 if-else 块做流程控制。
- ✅ 推荐：给变量、方法参数、返回值直接赋条件结果，比如
String status = isActive ? "ON" : "OFF"; - ❌ 避免：在分支中调用带副作用的方法（如
log.warn()、saveToDB()），因为可读性差且难以调试 - ⚠️ 警惕嵌套：
a ? b : c ? d : e看似省行，但可读性陡降，JVM 也无性能优势；超过一层嵌套就该换if-else
类型推断规则决定能否编译，不是看 boolean 表达式本身
很多人以为只要条件是 boolean 就能用三元，其实关键在两个分支表达式的类型是否可统一。Java 编译器会尝试找最小公共类型（如 String 和 null → String；Integer 和 Long → Long），失败则报错。
- 常见报错：
Type mismatch: cannot convert from int to String，源于"yes" : 123—— 字符串和数字无公共引用类型 - 修复方式：显式转型，如
"yes" : String.valueOf(123)或统一为包装类String.class : Integer.class不行，但Object.class可以（不推荐） - 注意自动装箱：
int和Integer混用通常能推导，但int和long会升为long，可能引发意料外的精度或比较问题
与 if-else 性能无差异，但过度简化反而增加维护成本
JVM 对三元和等效 if-else 生成的字节码几乎一致（都是条件跳转 + 栈操作），不存在「三元更快」的说法。真正影响性能的是分支内逻辑本身，而非语法形式。
- 真实瓶颈常来自分支里的 IO、计算或锁，和写法无关
- 团队协作中，复杂三元（尤其含方法调用或嵌套）会让 Code Review 更难定位逻辑边界
- IDE 重构支持：现代 IDE（IntelliJ）能一键把简单三元转
if，但反过来不总可靠；别为了“炫技”牺牲可维护性
String getDisplayName(User user) {
// ✅ 清晰：纯数据选择，无副作用
return user != null ? user.getName() : "Anonymous";
// ❌ 危险：副作用 + 类型风险（getName() 可能为 null，而 "Guest" 是 String）
// return user != null ? user.getName() : log.warn("User missing") == null ? "Guest" : "Guest";
}
三元运算符的边界很清晰：它只负责「选一个值」。一旦你发现自己在括号里写分号、调用 void 方法，或者需要加注释解释「为什么这里用三元」，那就已经越界了。 
