类型断言失败触发panic是Go的设计使然，非bug；应始终使用v, ok := i.(T)安全形式，ok为false时v为T零值，多类型分支则用type switch。
类型断言失败直接触发 panic，不是 bug 是设计使然——Go 要求你明确处理不确定性。解决的核心就一条：别用 i.(T)，改用 v, ok := i.(T)。
为什么 i.(T) 会 panic
Go 的类型断言是运行时检查，i.(T) 表示“我确定这个接口里装的就是 T”，一旦不匹配（比如接口里是 *string 却断言 string，或实际是 int 却断言 string），立刻崩溃。这不是异常未捕获，而是语义上“你承诺了却没做到”。
- 常见错误现象：
panic: interface conversion: interface {} is string, not int - 典型场景：从
map[string]interface{}或[]interface{}取值后直接断言，没验证类型 - 指针陷阱：接口中存的是
*MyStruct，却断言MyStruct—— 这俩是不同类型，必 panic
安全断言必须带 ok
用 v, ok := i.(T) 是唯一推荐的日常写法。它不假设、不承诺，只问“是不是”，返回两个值：值本身和布尔结果。
- 永远检查
ok，不要只声明v然后忽略ok -
ok为false时，v是T类型的零值（如""、0、nil），不能直接用 - 示例：
var i interface{} = 42 if s, ok := i.(string); ok { fmt.Println("是字符串:", s) } else { fmt.Println("不是字符串，实际类型是:", reflect.TypeOf(i)) // 可选调试 }
多个类型要判断？用 type switch
当接口可能为几种已知类型（如 int、string、bool），type switch 比一连串 if/else 更清晰、更高效。
立即学习“go语言免费学习笔记（深入）”；
- 语法固定：
switch v := i.(type)，每个case后直接写类型 -
v在每个case分支里自动具有对应类型，无需再断言 - 务必保留
default分支，否则遇到未列类型会静默跳过 - 示例：
func handleValue(i interface{}) { switch v := i.(type) { case int: fmt.Printf("处理整数: %d\n", v+1) case string: fmt.Printf("处理字符串: %q\n", v) default: fmt.Printf("不支持的类型: %T\n", v) } }
什么时候才考虑 recover？
极少情况需要——比如你封装一个通用反序列化函数，外部传入任意类型断言逻辑，且无法提前约束输入。这时 panic 是可控的，可用 defer + recover 拦截，但这是兜底，不是替代安全断言。
-
recover必须在defer函数内调用，且仅对当前 goroutine 有效 - 不要用它掩盖本该用
ok处理的常规断言场景 - 示例（仅作说明，不推荐日常使用）：
func safeAssert(i interface{}, t reflect.Type) (interface{}, error) { defer func() { if r := recover(); r != nil { // 注意：r 是 interface{}，需类型断言才能取 error if err, ok := r.(error); ok { // 处理 } } }() return i.(t), nil // 这里仍会 panic，由 defer 捕获 }
最常被忽略的一点：接口值本身可能是 nil，此时对任何非接口类型断言都会失败（ok 为 false）。但如果你断言的是接口类型（如 i.(io.Reader)），nil 接口也能成功——因为 nil 是所有接口类型的合法值。这点在写泛型或抽象层时特别容易踩空。
