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 显式表达，不是靠布尔运算符的副作用隐式承载。