go的switch支持任意可比较类型，但浮点数因精度问题不建议用于case；interface{}需用type断言；fallthrough极少使用，仅适用于连续整数的特殊逻辑共享。
switch 语句能直接比较非整数类型吗
能，Golang 的 switch 不限于 int，支持任意可比较类型（string、bool、nil、自定义类型只要实现 == 和 != 即可），但注意：浮点数（float64、float32）虽然语法允许，实际比较时极易因精度问题出错，不建议直接用于 case 判断。
常见错误现象：switch x { case 0.1: ... } 看似合理，但 x 是 0.1 计算结果时大概率不匹配——浮点数不是精确值。
- 字符串判断最常用，也最安全：
switch status { case "pending": ... case "done": ... } -
interface{}类型需用类型断言写法（见下一条），不能直接写case someInterfaceValue: - 空
switch（即switch {）本质是if else if else的替代，条件写在case后面，此时每个case是布尔表达式
case 中怎么处理 interface{} 类型的值
不能直接拿 interface{} 值去匹配具体类型字面量，必须用类型断言形式：case string:、case int:，这是 Go switch 的「类型切换」模式。
使用场景：解析 JSON、RPC 返回值、反射结果等不确定具体类型的输入。
示例：
switch v := data.(type) {
case string:
fmt.Println("string:", v)
case int, int64:
fmt.Println("number:", v)
case nil:
fmt.Println("nil")
default:
fmt.Println("unknown type")
}
- 必须用
v := data.(type)这种语法，type是关键字，不能换成变量名 - 一个
case可以列多个类型，用逗号分隔，但所有类型必须属于同一底层类型族（比如int和int64允许，int和string就不行） - 漏掉
default且没覆盖全类型时，运行时不会报错，但未匹配分支会被跳过——容易埋逻辑漏洞
fallthrough 什么时候真有用
绝大多数时候没用，Go 的 switch 默认不穿透，fallthrough 是显式向下执行下一个 case 的唯一方式，但它只作用于当前 case 块末尾，且下一个 case 的条件**不会被重新判断**。
性能/兼容性影响：它破坏了 switch 的逻辑隔离性，阅读和维护成本高，Go 官方文档也明确说“几乎从不需要”。
- 唯一合理场景：连续整数范围的特殊处理，比如
case 1,2,3:写法更清晰，但若某几个相邻值需要共享一部分逻辑 + 各自额外逻辑，才考虑fallthrough - 错误用法：在
case "a": fallthrough后接case "b":，指望它像 C 那样“满足 a 就顺带执行 b”，但 Go 要求fallthrough必须是块内最后一行，且下一个case必须存在——稍不注意就编译失败 - 替代方案优先用
if套switch或提取公共函数，比fallthrough更易懂
空 switch（switch {}）和 if else 的性能差异大吗
几乎没有。编译器对两者都做了充分优化，生成的汇编指令长度和分支预测行为基本一致。别为这点微小差异选型，关键看可读性。
使用场景：当条件逻辑复杂、嵌套深、且分支多于 4–5 个时，空 switch 比一长串 if else if else 更易定位和修改。
- 示例：
switch { case x > 0 && y - 注意：每个
case是独立布尔表达式，不共享变量作用域；:=在case中声明的变量只在该case块内有效 - 容易踩的坑：忘记写
break（其实根本不需要），或误以为case会按书写顺序“从上到下优先匹配”——它确实如此，但这是规范行为，不是 bug
真正容易被忽略的是：空 switch 的 case 表达式会在每次进入 switch 时重新求值，如果里面包含函数调用或耗时操作，可能重复执行多次——这点比 if else 更隐蔽。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
