go类型断言a.(t)失败会panic而非返回error，因其语义是“确信为t”，失败即逻辑矛盾；应优先用v, ok := a.(t)安全判断，单值断言仅用于100%可控且失败即bug的场景。
类型断言失败为什么会 panic 而不是返回 error
Go 的类型断言 a.(T) 在运行时发现 a 实际不是 T 类型时，直接触发 runtime.panic，而不是像其他语言那样返回错误或布尔值。这不是设计疏漏，而是语义选择：它表示“我确信这是 T”，一旦不成立，程序逻辑已处于不可恢复的矛盾状态。
常见错误现象：panic: interface conversion: interface {} is string, not int —— 这类错误往往出现在从 map[string]interface{} 或 json.Unmarshal 后盲目断言时。
- 安全做法永远优先用双值形式：
v, ok := a.(T)；ok为false时不 panic，可分支处理 - 单值断言
a.(T)应只用于你 100% 控制上游类型、且失败即代表 bug 的场景（如内部状态机断言） - 不能用
recover捕获单值断言 panic 来“兜底”——这会让错误流隐蔽，调试困难
interface{} 到具体类型的断言失败典型场景
最常出问题的地方是 JSON 解析后对字段做硬断言。比如 json.Unmarshal 把数字解析成 float64，但代码却写 data["age"].(int)。
使用场景：HTTP API 返回 JSON，结构体字段用 interface{} 接收，后续按业务规则转成具体类型。
立即学习“go语言免费学习笔记（深入）”；
-
json.Number是更稳妥的中间类型，支持.Int64()/.Float64()显式转换，避免误断言 - 如果必须用
interface{}，先用fmt.Printf("%T", v)看实际类型，再决定断言目标（常见有float64、string、bool、nil） - 嵌套 map/slice 里的值也要逐层检查，
data["user"].(map[string]interface{})["name"].(string)这种链式断言极易在任意一环失败
空接口 nil 和底层类型 nil 的区别导致的断言陷阱
一个 interface{} 变量值为 nil，不代表它里面装的底层类型也是 nil；反过来，底层类型为 nil（比如 *MyStruct(nil)），其 interface 值也不等于 nil。这个差异会让 if v == nil 判断失效，进而让断言意外 panic。
示例：var p *bytes.Buffer; var i interface{} = p; fmt.Println(i == nil) // false，但 i.(*bytes.Buffer) 会成功（得到 nil 指针），而 i.(*strings.Builder) 才真正 panic。
- 判断 interface 是否为空，必须用双值断言 + 检查底层值：
if v, ok := i.(*T); !ok || v == nil - 函数返回
interface{}时，不要返回未初始化的指针变量（如var t *T），应显式返回nil或构造好再装入 - 单元测试里特别注意 mock 返回值是否真的为
nil interface{}，还是非 nil 但底层为 nil 的 interface
panic 后 recover 不起作用的常见原因
很多人试图用 defer + recover 拦截类型断言 panic，但经常失败。根本原因是：recover 只在 defer 函数执行期间有效，且仅对当前 goroutine 的 panic 生效；一旦 panic 发生在别的 goroutine，或者 recover 写在了错误的位置，就捕获不到。
- recover 必须写在 defer 的匿名函数里，且该 defer 必须在 panic 发生前已注册（不能在 if 分支里动态 defer）
- HTTP handler 中 panic 会被
http.Server自动捕获并返回 500，但不会进你的 recover —— 因为 net/http 已经包了一层 - goroutine 里发生的 panic 无法被外层 recover 捕获，必须在 goroutine 内部自己 defer recover
- recover 不是错误处理机制，它是最后防线；靠它来掩盖断言错误，说明类型契约没理清
类型断言的边界很硬，没有模糊地带。写的时候多打一个问号：我真能保证这个 interface 里装的就是这个类型吗？比加 recover 更省事。
