短路与或提升条件判断性能技巧

短路运算符（&&和||）并非自动性能优化工具，而是依赖左操作数结果强制跳过右表达式执行的逻辑机制——只有当左操作数稳定、快速、分布合理（如高失败率条件用于&&、高成功率条件用于||）时，才能真正提升性能并避免副作用；但若左侧存在异常风险、耗时操作或隐式副作用，不仅无法获益，反而引发崩溃、行为不一致或调试陷阱；更需警惕闭包捕获等“隐形开销”，以及误用位运算符&/|替代逻辑短路带来的安全隐患，正确用法始终是：左侧守门、右侧承重，复杂逻辑显式拆解为if语句，让意图清晰、安全可控。

短路运算符能跳过右边表达式，但只在特定条件下生效

短路不是“自动优化”，而是由左操作数的值强制触发的执行跳过行为：&&在左操作数为false时跳过右操作数；||在左操作数为true时跳过右操作数。这意味着：左边必须先求值，且它的结果决定了右边是否运行。

常见误解是认为“写成链式就一定省事”，但若左边总为true（如flag == true && expensiveCall()），右边永远执行，毫无短路收益。

• &&适合把“高失败率、低开销”的条件放左边（如obj != null、list.size() > 0）
• ||适合把“高成功率、低开销”的条件放左边（如isCached()、config.isDebug()）
• 非布尔类型参与时（如 JavaScript 中str && str.trim()），短路仍生效，但返回的是值而非true/false，需注意逻辑一致性

把耗时操作放右边，但得确保左边真能拦住它

很多人把file.exists() && readFile(file)当范例，却忽略file.exists()本身也可能抛异常（如权限不足、路径非法），此时短路失效，readFile()不会被跳过，但程序已在前一步崩溃。

真正起效的前提是：左边表达式足够稳定、执行快、且结果分布利于提前终止。

• 避免把可能抛异常的检查放左边，除非你明确捕获并处理——比如Files.exists(path)比path.toFile().exists()更健壮
• 数据库查询、HTTP 调用、正则匹配这类操作，绝不能放在左边；即使加了缓存，也要确认缓存命中率足够高
• 循环内慎用短路链：JIT 可能因分支预测失败而降级，实测a && b && c && d()不如拆成两个if清晰且高效

副作用藏在右边时，逻辑会悄无声息地坏掉

短路最隐蔽的坑不是性能，而是行为不一致。当你写isValid() && counter++ > 0，counter++根本不会执行——这不是 bug，是语言规范。但调试时断点打在counter++上永远不会命中，容易误判逻辑漏执行。

类似情况还包括日志打印、状态标记、资源申请等隐式变更。

• 含副作用的表达式一律不要塞进短路右侧，哪怕它“看起来很轻”
• 需要条件触发副作用时，显式写出if (isValid()) { counter++; ... }
• 函数调用本身有副作用（如logAndReturn(true)）也属于高危，应视为“不可短路依赖”

Java 里别用&和|替代&&和||来“强制求值”

有人为了确保右边一定执行，改用&或|，这是危险操作：它们不光取消短路，还会改变求值顺序语义，且在布尔上下文中失去可读性。

例如obj != null & obj.getName().length() > 0，一旦obj为null，直接NullPointerException；而&&版本天然安全。

• &和|应仅用于位运算（如flags & READ_PERMISSION）或明确需要两边都执行的布尔场景（极少见）
• 若真需要“无论怎样都执行右边”，用分号隔开：先算左边，再根据结果决定是否执行右边，意图清晰、无歧义
• 静态分析工具（如 SpotBugs）通常会对boolean & boolean发出警告，把它当成潜在缺陷

本篇关于《短路与或提升条件判断性能技巧》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！