type switch 的高效源于编译期静态生成跳转逻辑：小类型链式比较、中等规模二分查找、大量类型用跳转表，零分配无反射；nil 接口值需显式 case nil: 捕获，不可用 fallthrough，case 后仅允许具体类型字面量（error 除外）。
type switch 的匹配效率到底靠什么撑住
它不是靠反射，也不是运行时查表，而是编译器在生成代码时就决定好跳转路径——对小数量类型（通常 ≤5），生成链式比较；类型稍多（比如 6–20），转成二分查找；再多就用跳转表。整个过程零分配、无反射调用、不触发 GC。
常见错误现象：switch v := x.(type) 里 x 是 nil 接口值，但没写 case nil:，结果所有 case T 都不匹配，直接跳过逻辑，静默失效。
- 接口值为
nil时，v也是nil，但类型信息丢失，case string:这类分支完全不命中 - 想捕获
nil必须显式写case nil:，这是唯一合法且语义明确的方式 - 不要试图用
case *T:来“覆盖”nil *T—— 它确实会命中，但后续解引用立刻panic - 如果业务允许
nil输入，优先在switch前加if x == nil预判，比塞进case nil更清晰
为什么不能在 type switch 里用 fallthrough
type switch 的每个 case 对应一个互斥的底层类型，编译器据此生成不可重叠的类型检查序列。加 fallthrough 不仅语法报错 cannot fallthrough in type switch，更违背设计本意：类型分发必须是确定性的，不能靠“穿透”来模拟类型继承或组合关系。
使用场景：当你发现多个 case 块重复相同逻辑（比如都调用 log.Printf），这不是 fallthrough 的信号，而是提取函数的信号。
立即学习“go语言免费学习笔记（深入）”；
- 正确做法：把共用逻辑抽成独立函数，各
case分别调用 - 错误迁移习惯：从 C/Java 的
switch带来的fallthrough直觉，在type switch中完全不适用 - 泛型还没普及前，若真需“一类类型共享行为”，考虑定义新接口并让多个具体类型实现它，再用普通
switch+ 接口方法分发
case 后面能写哪些类型，边界在哪
case 右侧只能是编译期已知的具体类型字面量，不能是变量、别名（除非显式声明为新类型）、接口或表达式。Go 把这当成硬性语法约束，而非运行时校验。
典型误用：case io.Reader: 编译直接失败，因为 io.Reader 是接口类型，不是具体类型；case MyInt: 若 type MyInt int，它和 int 是两个独立类型，不会自动合并。
- ✅ 允许：
case string:、case []byte:、case *http.Request:、case map[string]interface{}: - ❌ 禁止：
case fmt.Stringer:（接口）、case reflect.Type:（反射类型）、case someVar:（变量） - ⚠️ 注意：
case error:是合法的，因为error是接口，但 Go 特殊允许它——仅此一例，其他接口不行 - 复合类型支持完整，包括函数类型
case func(int) string:和 channel 类型case
比起 reflect.TypeOf，type switch 慢在哪里、快在哪里
快在编译期固化路径、零反射开销、可内联；慢在必须提前枚举所有可能类型，无法应对未知类型。这不是性能高低问题，而是适用边界的划分。
错误信号：你开始写 if reflect.TypeOf(v).Name() == "MyStruct" 或一堆 reflect.ValueOf(v).Kind() == reflect.Struct 判断，说明该换 type switch 了。
-
type switch编译后是紧凑的汇编跳转，基准测试中比reflect.TypeOf快 10–100 倍（取决于类型数量） -
reflect.TypeOf必须构造reflect.Type对象，涉及内存分配和运行时类型系统查询 - 真正难处理的不是“性能”，而是类型漏判：
type switch配合default能强制你面对未覆盖类型；reflect方案容易漏掉拼写错误或新类型，上线才暴露 - 如果你的输入类型集合会动态扩展（如插件系统），
type switch就不该是第一选择，而应建注册表 + 显式映射
type switch 的“静态契约”属性：你写的每一个 case，都在向编译器承诺“这些就是全部可能类型”。一旦现实超出这个范围，default 不是兜底，而是警报——它提醒你契约已破，而不是帮你擦屁股。 
