Go里&&真会短路，但别靠它写副作用逻辑
Go的&&确实短路：左边为false时，右边表达式根本不会执行。这是语言规范保证的行为，不是优化技巧，而是语义本身。
常见错误是把err != nil && handleError(err)这类写法当“安全兜底”，结果handleError带状态修改（比如记录日志、发告警），一旦左边为false，这些操作就静默丢失——因为压根没调用。
- 只在右边是纯判断（如
ptr != nil && ptr.field > 0）或无副作用函数（如isValid(x) && isInRange(x)）时，才放心用&&串联 - 如果右边有必须执行的逻辑，拆成
if语句，别贪一行 - 静态检查工具（如
staticcheck）能捕获部分带副作用的短路误用，建议接入CI
用&&替代嵌套if时，注意可读性断层
很多人把if a { if b { ... } }直接改成if a && b { ... }，看起来更紧凑。但当a和b本身是复杂表达式（比如带函数调用、多层字段访问），单行条件会迅速变得难扫读。
典型反例：if user != nil && user.Profile != nil && user.Profile.Settings != nil && user.Profile.Settings.Theme != ""——这不是优化，是把控制流藏进表达式里，调试和加断点都变困难。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 超过3个操作数或任意子表达式含函数调用，优先考虑提前
return或拆成多个if - 如果必须链式判断，提取中间变量（如
settings := user.Profile.Settings），再用&& - IDE对长
&&条件的断点支持不一致：有些只允许在整行设断，无法单独停在某个子表达式
&&左右两边的求值顺序和性能影响
Go严格从左到右求值，且短路后完全跳过右边。这意味着：左边越快失败，整体越省；但若左边总是true，右边就必然执行——这时候它的耗时就变成关键路径。
常见踩坑是把数据库查询、HTTP调用、正则匹配等重操作放在&&右边，以为“前面挡着呢”，结果发现if cacheHit && dbQuery()里cacheHit几乎总为true，dbQuery反而成了性能瓶颈。
- 把高概率为
false、低开销的判断放左边（如len(s) == 0、id ） - 避免在
&&右边放任何可能阻塞或panic的调用；万一左边为true，它就会暴露出来 - 基准测试时注意：
go test -bench默认不模拟短路分支，要手动构造true/false比例来测真实场景
和||混用时，优先级和括号不是可选项
&&优先级高于||，但人脑不记优先级。写a || b && c等于a || (b && c)，可一旦加了否定（!a || b && c），多数人第一反应其实是(!a || b) && c——这就错了。
错误现象很隐蔽：逻辑看似成立，但线上偶发不符合预期，尤其当b或c是带状态的函数时，执行与否取决于是否被括号包裹。
- 所有混合
&&和||的表达式，一律加括号，哪怕你觉得“没必要” -
!a && b || c这种，至少写成(!a && b) || c或!(a || !b) || c（后者更糟，别学） - Go vet不报这种问题，但
gofmt也不会帮你加括号——得靠代码审查或自定义linter
短路本身没问题，问题总出在人对“什么时候该执行”的预期和实际执行之间的偏差。越想省代码，越得盯紧求值时机和副作用边界。
