是，go 中 && 和 || 必须短路求值；左边结果确定时右边不执行，如 false && b() 中 b() 完全不调用，用于防御检查但需警惕副作用被跳过。
Go 里 && 和 || 真的会跳过右边表达式吗
会，而且必须跳过——这是 Go 语言规范强制要求的行为，不是优化技巧。只要左边已能确定整个表达式结果，右边根本不会求值。
比如 a && b()，当 a 为 false 时，b() 完全不执行；a || b() 中若 a 为 true，b() 同样被跳过。
- 常见错误现象：在右边放有副作用的操作（如日志、修改变量、HTTP 调用），却没意识到它可能根本不运行
- 典型使用场景：防御性检查，比如
ptr != nil && ptr.field > 0，避免空指针 panic - 注意：短路只发生在布尔类型之间；如果某一边不是
bool（比如误写成整数），编译直接报错：invalid operation: …… (mismatched types int and bool)
为什么 if err != nil || len(data) == 0 可能出问题
这不是语法错误，但逻辑容易翻车——因为 || 短路，一旦 err != nil 为 true，len(data) 就不求值。这本身没问题；但如果你本意是“无论 err 是否为空，都要检查 data”，那就错了。
- 真实坑点：把短路当成“顺序执行保障”，结果漏掉必要校验或初始化
- 更隐蔽的情况：右边表达式含函数调用且有副作用，例如
validate() || log.Fatal("fail")，log 不一定触发 - 参数差异：和 Python 的
or、JavaScript 的||行为一致，但 Go 不支持非布尔值隐式转换，所以不会出现“0 || ‘default’”这类陷阱
性能上，短路真的值得依赖吗
值得，但仅限于避免代价高的操作；别指望靠它省几个纳秒的整数比较。
立即学习 “go 语言免费学习笔记（深入）”；
- 典型收益场景：右侧是数据库查询、文件读取、正则匹配等 I/O 或 CPU 密集型操作
- 兼容性无影响：所有 Go 版本（1.0+）都保证该行为，不存在跨版本差异
- 反模式示例：用
slowCheck() && fastCheck()试图“优化”，其实违背了可读性——应把慢操作放在右边才符合直觉和短路初衷 - 小提醒：短路不改变运算符优先级，
a || b && c等价于a || (b && c)，括号该加还得加
调试时怎么确认右边真被跳过了
不能靠 print 看输出，得看执行流是否进入右侧代码块。最简单的方法是加断点或用 defer 配合计数器。
- 快速验证方式：在右边放个带副作用的函数，比如
func() bool { fmt.Println("right eval"); return true }，观察输出是否缺失 - 常见误判：以为 panic 出现在右边就是“执行了”，其实 panic 可能来自左边表达式内部（比如
arr[0] && ……中索引越界） - 注意：go test + -gcflags=”-l” 无法禁用短路——它是语义层强制行为，不是编译器优化开关
短路求值不是语法糖，是 Go 控制流程的基础设施。真正容易被忽略的是：它让“表达式求值”变成有条件的分支，而很多人仍把它当成纯数学运算来看待。
