三元运算符与if-else在高频计算中性能差异极小，现代编译器通常将其优化为相似指令；真正影响性能的是逻辑复杂度、内存分配、分支预测及数据局部性。
三元运算符和 if-else 在高频计算节点中性能差异极小，现代编译器或 JIT（如 JVM、.NET CLR、V8）通常会将二者优化为几乎一致的底层指令。压测意义不大，真正影响性能的是逻辑结构、数据局部性、分支预测成功率，以及是否引入副作用或对象分配。
先看真实瓶颈在哪高频计算节点的慢，90% 不是因为用了 if-else 而不是三元，而是因为：条件判断本身涉及复杂计算（比如反复调用 Math.sqrt() 或字符串正则匹配）
分支结果触发了内存分配（如 new Object()、字符串拼接、装箱）
条件分布严重倾斜但未适配（例如 99% 走 else 分支，却把高开销逻辑放在 if 块里）
循环内存在缓存不友好访问（跨页读取、非连续数组索引）
压测时必须控制的关键变量若仍需实测对比，请严格统一以下要素，否则结果无参考价值：关闭预热干扰：JVM 需 -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly 确认热点已编译；.NET 启用 TieredCompilation=false固定条件分支概率：用固定输入（如 num = 1000）、避免随机数导致分支预测失效禁用无关优化干扰：确保 expr1 / expr2 是纯计算（无方法调用、无 I/O、无锁），且类型完全一致（避免隐式提升引发额外转换）
测量粒度合理：单次执行纳秒级差异不可靠，应测百万次以上并取中位数，排除 GC 暂停抖动什么场景下三元确实更稳？
不是“更快”，而是“更可控”——尤其在 CPU 流水线敏感路径中：简单标量赋值（int/double/bool）且条件稳定：如value = flag ? a : b;更易被编译为 CMOV 指令，规避分支预测失败惩罚作为表达式嵌入函数调用：如log(level > DEBUG ? "DEBUG" : "INFO", msg);避免 if 块带来的作用域与控制流开销数组/集合索引选择：如arr[isLeft ? i : j] = x;比 if + 两行赋值更紧凑，利于向量化识别什么情况千万别硬套三元
强行替换反而引入新问题：
涉及方法调用且有副作用：如flag ? doA() : doB();—— 三元要求两边都求值（部分语言如 JS 允许，但语义已偏离直觉）
类型不兼容需隐式转换：如cond ? 1 : 1.0在 Java/C# 中会升为 double，可能引发意料外精度丢失或装箱嵌套超过两层：如a ? b : c ? d : e ? f : g可读性骤降，调试器难以断点，静态分析工具易误报需要 early-return 或异常抛出：三元无法 throw new Exception() 或 return，强行塞进去会破坏控制流优化高频计算节点，重点不在 if 和 ? 之间选一个符号，而在于让条件本身更廉价、让分支更可预测、让结果复用更充分。写清楚，再谈压测；理清数据流，再谈指令级优化。