是，Go中&&和||严格短路：左操作数可确定结果时，右操作数不执行；这是语义要求而非优化，常用于安全判空，但副作用逻辑不可依赖短路。
Go 里 && 和 || 真的会短路吗？
会，而且是语言层面强制保证的——只要左边能确定整个表达式结果，右边根本不会执行。这不是优化技巧，是语义要求。
常见错误现象：在 || 右边写有副作用的函数（比如 log.Print() 或数据库查询），结果发现它有时不被调用，还以为是 bug；其实是短路在起作用。
- 使用场景：常用于安全判空 + 访问，比如
ptr != nil && ptr.val > 0，避免 panic -
&&左边为false→ 跳过右边；||左边为true→ 跳过右边 - 性能影响：短路本身开销可忽略，但能避免不必要的计算或 I/O，尤其在条件复杂或副作用明显时很关键
- 注意：
&和|（按位与/或）不短路，且操作数必须是整数，别和&&/||混用
为什么 if a && b() { } 里 b() 有时根本不运行？
因为 a 是 false，&& 直接判定整个表达式为 false，连 b() 的函数调用都不会发生——Go 不会“预解析”或“预执行”右边。
这和 Python、JavaScript 行为一致，但和 C/C++ 宏展开或某些 DSL 不同，容易让习惯手动控制流程的人误判。
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 典型陷阱：把日志、埋点、状态更新写在短路表达式的右侧，导致漏触发
- 正确做法：副作用逻辑必须显式写出，不要依赖短路“顺便”执行，例如拆成
if a { if b() { ... } } - 调试时可在
b()开头加fmt.Println("b called")验证是否被跳过
!true 和 !!x 在 Go 里能用吗？
可以，但仅限于单个布尔值。Go 不支持对非布尔类型隐式转换，所以 !!x 如果 x 是整数或指针，直接编译报错。
错误信息类似：invalid operation: !x (mismatched types int and bool)。
-
!只接受bool类型操作数，不能像 JavaScript 那样“取反再取反”来转布尔 - 想把非布尔值转为布尔语义，必须显式比较，比如
x != 0、ptr != nil、len(s) > 0 - 没有
Boolean(x)这种函数，也没有 “falsy” 概念，Go 的真假判断永远显式、严格
多个条件连写时，&& 和 || 的优先级怎么算？
&& 优先级高于 ||，且都左结合。也就是说 a || b && c 等价于 a || (b && c)，不是 (a || b) && c。
容易踩的坑是凭直觉断句，尤其在混合使用时漏加括号，导致逻辑和预期不符。
- 建议：只要超过两个操作符，一律加括号，比如
(a || b) && c或a || (b && c) - 不推荐靠记忆优先级写
a || b && c || d这类表达式，可读性差，也难维护 - Go vet 不报这种问题，但代码审查时容易忽略，线上出错后很难回溯
短路本身很简单，难的是时刻意识到“右边可能不执行”。尤其当团队里有人来自弱类型语言，或者自己写惯了带副作用的条件表达式，这个意识一松，bug 就藏在看似无害的一行里。
