Go中if条件报“non-bool used as if condition”错误，因Go不支持隐式转换和truthy/falsy语义，必须显式比较如len(s)>0、err!=nil；bool默认值false语法安全但业务易误用，推荐显式初始化；多值返回需显式判error；&&/||短路可防panic并优化性能；bool不可用>、
if 条件里为什么报错 “non-bool used as if condition”？
因为你传了非 bool 类型的值给 if，比如 len(s)、err、ptr 或 nil——Go 不允许隐式转换，也不接受“truthy/falsy”语义。
- ✅ 正确写法：
if len(s) > 0 { }、if err != nil { }、if ptr != nil { } - ❌ 错误写法：
if len(s) { }、if err { }、if ptr == nil { }（漏了==就是语法错误） - ⚠️ 注意：
if flag == true合法但冗余，直接写if flag；if flag != true应写成if !flag
声明 bool 变量时默认值是 false，这安全吗？
语法上安全，但业务上常埋雷：未初始化的 var isActive bool 自动为 false，可它本意可能是“尚未设置”，而非“明确关闭”。
- 显式初始化更可靠：
isActive := false或isEnabled = true - 结构体中若需区分“未设置”和“设为 false”，别用
bool，改用*bool或sql.NullBool - 函数返回多值时，
error必须显式判!= nil，不能省略——这不是啰嗦，是类型强制兜底
&& 和 || 的短路行为怎么影响逻辑和性能？
短路不是语法糖，是防止 panic 和提升效率的关键机制。左侧结果能确定整体真假时，右侧根本不会执行。
- 安全访问：
if s != "" && s[0] == 'x' { }—— 空串时s[0]不会触发 panic - 性能建议：把开销小、失败快的判断放左边，如
if isValidFormat(input) && isUserAllowed(uid) - ⚠️ 副作用陷阱：如果右侧有日志、计数或网络调用，放在
||右侧可能被跳过，务必确认是否符合预期
为什么不能对 bool 用 >、
Go 把 bool 当作纯逻辑类型，不参与数值比较或位运算——这是设计选择，不是限制。
立即学习“go语言免费学习笔记（深入）”；
-
==和!=是唯二支持的比较操作符；>、直接编译报错 -
&、|只用于整数，true & false会提示invalid operation；要用逻辑与/或，必须用&&/|| - 需要转数字？自己封装：
func btoi(b bool) int { if b { return 1 }; return 0 }；反之用i != 0
if done == true 或把 err 当 bool 用，就说明类型契约正在松动。 
