Java中利用短路特性提升性能的核心是将轻量高确定性条件置于&&或||左侧，使右侧高成本或高风险操作被真正跳过；需规避隐式转换、副作用及过度嵌套等陷阱。
Java 中利用逻辑运算符的短路特性提升性能，核心是让高确定性、低开销的条件控制是否执行右侧高成本或高风险操作。关键不在“写得更短”，而在“让不该跑的代码真不跑”。
把轻量且易失败的条件放 && 左侧
&& 的短路规则是：左侧为 false 时，右侧整个表达式跳过执行。因此适合把空检查、状态判断等低成本但大概率中断流程的条件放在左边：
- user != null && user.isActive() —— user 为 null 时，isActive() 根本不调用
- list != null && !list.isEmpty() && list.get(0) > 0 —— 前两个条件为假，list.get(0) 不会触发索引越界
- config.isFeatureOn() && loadExpensiveResource() —— 功能关闭时，资源加载完全绕过
把高成功率条件放 || 左侧做兜底优化
|| 的短路规则是：左侧为 true 时，右侧不执行。适合用于缓存命中、默认值就绪等“能快速给出答案”的场景：
- cache.get(key) != null || fetchFromDatabase(key) —— 缓存存在，数据库查询不触发
- isValidInput(str) || fallbackValidate(str) —— 主校验通过，备用逻辑不运行
- isLocalEnv() || sendMonitoringMetric() —— 本地环境跳过监控上报，避免干扰开发
避开常见陷阱，确保短路真正生效
短路不是万能加速器，很多写法看似用了 && 或 ||，实际根本没跳过耗时操作：
立即学习“Java免费学习笔记（深入）”；
- 别把耗时函数写在左侧：getRemoteConfig() && isValid() 每次都远程拉配置，短路失效
- 警惕隐式真假值：count && processItems() 中，count 是 0 就短路，但 0 可能是合法业务值，应改用 count > 0 && processItems()
- 副作用别藏在右侧：flag && log("hit") 看似简洁，但日志是否输出不可控，调试困难，应显式用 if (flag) log("hit")
- 复杂链式判断慎用：a && b && c && d && e() 超过三层后，JIT 编译可能放弃优化，反而不如分步 if 清晰高效
与非短路运算符 & 和 | 明确区分
Java 提供了非短路版本 & 和 |，它们**总是计算两侧表达式**。仅在需要强制执行两边（比如位运算或必须触发副作用）时才使用：
- if (methodA() & methodB()) → 即使 methodA() 返回 false，methodB() 仍执行
- 日常条件判断中，几乎永远该用 && 和 ||，除非你明确需要两边都执行
- 混淆 == 和 =、& 和 && 是新手高频编译错误来源，IDE 通常会高亮警告
