类型断言失败会直接 panic 且 recover 捕获不到，必须使用双值断言 v, ok := i.(T) 避免崩溃；单值断言 i.(string) 失败时 goroutine 立即终止，defer 和 recover 均不执行。
类型断言失败会直接 panic，recover 捕获不到
Go 中 v := i.(string) 这种单值断言一旦失败，会立刻触发运行时 panic，且这个 panic 无法被 recover() 拦截——不是 recover 不管用，而是它根本没机会执行。因为 panic 发生在当前 goroutine 的普通语句执行阶段，而 recover() 只能在 defer 函数中、且 panic 正在传播时才生效；但单值断言失败是「同步崩溃」，连 defer 都来不及跑。
- 常见错误现象：
panic: interface conversion: interface {} is int, not string，程序直接退出，日志里看不到 recover 日志 - 使用场景：解析 JSON（
json.Unmarshal返回map[string]interface{}）、HTTP 请求体解包、反射取值、泛型容器取元素等 - 根本原因：Go 把不安全的类型断言设计为运行时 fatal 错误，而非可恢复错误，这是语言层面的取舍
必须用双值断言 v, ok := i.(T)
这才是唯一能避免 panic 的写法。它不抛异常，只做检查：成功则 v 是目标值、ok 为 true；失败则 v 是 T 的零值（比如 ""、0、nil），ok 为 false，控制流继续往下走。
- 别再写
if s := data["name"].(string) { ... }—— 这行就可能让服务挂掉 - 正确写法是：
if s, ok := data["name"].(string); ok { ... }，把判断和赋值合在 if 条件里 - 对嵌套结构（比如
data["user"].(map[string]interface{})["age"]）要逐层用双值断言，不能跳步 - JSON 数字默认是
float64，想转int得先断言float64，再用int(x)转换，别直接data["age"].(int)
recover 对类型断言 panic 完全无效，别白费力气
有人会在外层加 defer func() { recover() }() 试图兜底所有 panic，但这对类型断言失败毫无意义。recover 只能捕获「已开始传播但尚未终止 goroutine」的 panic，而类型断言失败属于「立即崩溃」，goroutine 状态直接变成 _dead_，defer 都不会触发。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
panic(nil)同样无法 recover，会直接终止程序 -
recover()有效场景仅限于：你主动调用panic()、或遇到空指针解引用、切片越界、并发写 map 等——但这些和类型断言无关 - 如果你真在日志里看到 recover 捕获到了类型断言 panic，那说明你捕获的是另一处 panic，只是恰好发生在同一函数里，别混淆因果
复杂结构建议用类型 switch 或封装校验函数
当要处理多种可能类型（比如 interface{} 可能是 string、int、bool 或 nil），硬写一串 if-else 双值断言容易漏判。这时候用 switch v := x.(type) 更清晰，而且每个分支天然就是安全断言。
立即学习“go语言免费学习笔记（深入）”；
- 类型 switch 本质就是编译器帮你展开成多个双值断言，语义更明确，不易出错
- 对高频使用的结构（如 HTTP 参数解析），建议封装成函数，例如
AsString(i interface{}) (string, bool)，内部统一做双值断言 + 判空，调用方不用重复写逻辑 - 注意：类型 switch 中的
default分支不是“兜底”，而是匹配所有未列出的类型，包括nil；如果想区分nil和其他类型，得单独加if i == nil判断
