Go 的 && 和 || 一定短路，因语言规范明确定义：&& 在左操作数为 false 时跳过右操作数，|| 在左操作数为 true 时跳过右操作数，运行时确定性生效，无例外。
Go 语言的 && 和 || 天然支持短路求值，不需要额外实现——只要写法合规，运行时自动生效。
为什么 Go 的 && 和 || 一定短路？
这是 Go 语言规范明确定义的行为：&& 在左操作数为 false 时跳过右操作数；|| 在左操作数为 true 时跳过右操作数。底层不生成冗余调用，也无编译器开关可关闭。
- 函数调用作为操作数时，未被短路的部分根本不会执行（比如
f() || g()中f()返回true，则g()完全不调用） - 短路发生在运行时，但属于确定性行为，和 CPU 分支预测无关
- 不存在“可能不短路”的例外场景（不像某些宏展开或反射调用）
常见误用：把副作用塞进条件表达式
开发者有时会依赖短路来控制函数执行顺序，例如：
if valid(id) && saveToCache(id) {
// ...
}
这种写法看似简洁，但有隐患：
-
saveToCache(id)是业务逻辑，不是纯布尔判断，语义混淆 - 后续维护者可能误以为该函数只返回
bool，实际它还修改状态或触发 I/O - 一旦
saveToCache改为返回error，整个表达式就编译失败 - 单元测试难以 mock 或覆盖分支（比如想测
saveToCache失败路径，但被短路拦住了）
更清晰的替代写法：显式控制流
用 if 块代替嵌套布尔表达式，可读性和可测性都更好：
if !valid(id) {
return
}
if err := saveToCache(id); err != nil {
log.Printf("cache save failed: %v", err)
return
}
// 后续逻辑
这种结构的优势：
- 每个函数职责单一，不混杂判断与副作用
- 错误处理自然落地，无需靠
ok, err := saveToCache(id); ok这类变通 - 调试时断点位置明确，不会因短路跳过关键行
- 静态分析工具（如
staticcheck）更容易识别潜在 panic 或资源泄漏
性能影响几乎可以忽略，但要注意逃逸分析
短路本身零开销，但若右操作数含局部变量构造（尤其是大结构体或切片），短路虽跳过执行，却可能让编译器无法优化其内存分配：
if cond {
// ...
} else if heavyComputation() > 0 { // heavyComputation 内部 new 了大 slice
// ...
}
此时即使 cond 为 true，heavyComputation 不调用，但它的栈帧布局仍可能影响外层函数的逃逸判定。真正影响性能的是函数内部实现，不是短路机制本身。
复杂点在于：短路是可靠的，但人容易把它当成控制流工具来用——而 Go 的控制流应该由 if/return 显式表达，不是靠布尔运算符的副作用隐式承载。
