短路优化应将高概率终结判断的条件放左侧：&&用高失败率条件，||用高成功率条件；用于安全防护可避运行时错误；需警惕隐式真假值、副作用及复杂嵌套导致的性能与可读性问题。
把轻量、高确定性的判断放左边，把耗时或易出错的操作放右边，才能真正让短路特性起作用。
优先安排“决定性”条件
短路只跳过右侧表达式，左侧永远执行。所以关键不是“哪个条件更重要”，而是“哪个条件最可能提前终结整个判断”：
- 对 &&：把失败概率高的条件放左（如
obj != null、arr.length > 0），一旦为假，后续不执行 - 对 ||：把成功概率高的条件放左（如
isCached()、user === 'admin'），一旦为真，后续跳过 - 避免反模式：比如
getApiData().length > 0 && isValid()—— 每次都调 API，短路完全失效
用短路做安全防护，不止是省性能
它天然适合规避运行时错误，尤其在操作不确定对象或资源时：
- 防空指针：
user && user.profile && user.profile.avatar - 防除零：
divisor !== 0 && value / divisor > 2 - 防越界：
i >= 0 && i 10 - 防文件异常：
fs.existsSync(path) && fs.readFileSync(path).includes('target')
警惕隐式真假值和副作用陷阱
短路依据的是真值（truthy）/假值（falsy）判断，不是 === true/false：
-
[]、{}、42是 truthy；0、''、null、undefined、NaN是 falsy - 别依赖
flag && doSomething()做逻辑分支——可读性差，且doSomething()若有状态变更或日志，可能被意外跳过 - 含副作用的表达式（如
i++、console.log()、sendMetric()）放在右侧时，执行与否不可控，应拆到 if 块中显式处理
别高估短路，复杂逻辑该拆就拆
短路不是万能加速器：
- 它跳过的是「执行」，不是「解析」或「闭包创建」——像
cond && (() => heavy())()，函数体仍会被构造 - 嵌套太深（如
a && b && c && d && e()）会影响 JIT 编译，实测有时不如分步 if 判断清晰高效 - 涉及 await 时，
await a() && await b()不会异步短路——a() 总是先 await 完，再判断是否执行 b() - 真正高频或业务复杂的判定，建议封装成独立函数，再用短路组合调用，兼顾可读与可控
