类型开关必须用switch v := x.(type)格式，x须为接口类型，case中v自动转为对应类型，无default且不匹配会panic；fallthrough在类型开关中禁用，仅适用于值switch。
Go 类型开关怎么写才不报错
类型开关不是语法糖，是 Go 专门处理 interface{} 的运行时类型分支机制。写错最常见原因是把类型断言和类型开关混用，或者漏掉 default 导致 panic。
- 必须用
switch v := x.(type)格式，x必须是接口类型，不能是具体类型或指针（除非该指针实现了接口） -
case int:这类分支里，v自动转为对应类型，不需要再写v.(int) - 没有匹配到任何
case且没写default，会 panic —— 不是编译错误，而是运行时崩溃 - 如果
x是nil接口值，所有case都不匹配，只能靠default捕获
示例：
var i interface{} = "hello"
switch v := i.(type) {
case string:
fmt.Println("string:", v) // v 是 string 类型
case int:
fmt.Println("int:", v)
default:
fmt.Println("unknown type:", reflect.TypeOf(i))
}
fallthrough 在 switch 里到底能不能用
能用，但只在「普通 switch」中有效，在「类型开关」中完全无效 —— 编译直接报错 cannot fallthrough in type switch。很多人卡在这儿，以为是写法问题，其实是语义禁止。
- 普通 switch（基于值比较）中，
fallthrough会无条件跳到下一个case的语句块，不管条件是否成立 - 它不继承条件逻辑，也不做类型转换，就是纯粹“往下掉一行执行”
- 容易误用：在最后一个
case后加fallthrough，会触发编译错误cannot fallthrough final case - 性能上无影响，但可读性差，建议只在明确需要“范围穿透”的场景用（比如多个整数 case 共享逻辑）
示例：
switch n {
case 1:
fmt.Print("one ")
fallthrough
case 2:
fmt.Print("two ")
case 3:
fmt.Print("three")
} 输入 n=1 输出 "one two "；输入 n=2 输出 "two "。
类型开关 vs 类型断言：什么时候该选哪个
类型开关适合「不确定可能有哪些类型、需要分别处理」的场景；单次类型断言适合「大概率是某一种、失败就走兜底」的轻量判断。
- 连续写多个
if v, ok := x.(T); ok { ... }是反模式，既啰嗦又低效 —— 类型检查重复做了多次 - 类型开关一次完成类型识别 + 变量绑定，底层调用的是 runtime.convT2I 等优化路径，比嵌套断言快
- 如果只关心是否为某一种类型（比如只处理
error），用断言更直接；如果要区分string/[]byte/io.Reader等多种情况，必须用类型开关 - 注意：类型开关里的
v是新变量，作用域仅限当前case，不能跨 case 使用
嵌套 switch 和 fallthrough 的边界问题
Go 不允许在类型开关内部使用 fallthrough，但允许在普通 switch 里嵌套另一个普通 switch —— 这时候 fallthrough 只对最近一层生效，不会穿透外层。
立即学习“go语言免费学习笔记（深入）”；
-
fallthrough永远只影响同一级 switch 的下一个case，不会跳进内层 switch 或跳出外层 - 如果内层 switch 有
fallthrough，它只会落到内层的下一个case，和外层无关 - 真正容易出错的是变量遮蔽：内层 switch 用同名
v，会覆盖外层定义，但这是作用域问题，不是 fallthrough 导致的 - 调试时注意：IDE 或 go vet 不会警告 fallthrough 的逻辑风险，得靠人眼确认每个穿透是否符合预期
类型开关的分支本质是互斥的，而 fallthrough 是为值 switch 设计的线性流程控制 —— 这两者在语言设计层面就分属不同抽象，硬凑一起只会触发编译器拒绝。
