recover无法捕获非法类型转换异常，因其属于编译期错误；唯一可panic的类型相关操作是失败的非安全类型断言，但应优先使用v, ok := val.(T)处理。
recover 不能解决非法类型转换异常，它根本捕获不到这类错误。
非法类型转换在 Go 中属于编译期错误，不是 panic
Go 是静态类型语言，像 int 强转 string、interface{} 直接转成不匹配的具体类型（如 v.(string) 但实际是 int）这类操作，如果写法不符合类型断言或转换规则，根本过不了编译。例如：
var x int = 42 s := string(x) // 编译错误：cannot convert x (type int) to type string
这类报错是 invalid operation: cannot convert，发生在 go build 阶段，recover 完全不参与——它只对运行时 panic 有效。
真正可能触发 panic 的类型相关操作只有类型断言失败
唯一能在运行时因类型问题 panic 的，是「非安全类型断言」.(T) 在值不满足类型时崩溃。比如：
立即学习“go语言免费学习笔记（深入）”；
-
val := interface{}(42); s := val.(string)→ 触发panic: interface conversion: interface {} is int, not string - 这种 panic 才能被
recover捕获，但这不是“解决”异常，只是防止崩溃
正确做法是用「安全类型断言」v, ok := val.(string)，它不会 panic，而是返回 (zero value, false)。这才是 Go 推荐的处理方式。
为什么在 defer + recover 里 catch 类型断言 panic 是坏主意
即使你硬要用 recover 拦住 .(T) panic，也会带来严重问题：
- 无法区分是类型断言失败，还是其他任意 panic（比如空指针、越界），错误信息混杂
- 原函数已退出，
val.(string)后面的逻辑全部跳过，状态可能不一致 - 掩盖了本该用
_, ok :=显式检查的设计意图，让代码更难维护 - 性能上无必要开销：一次类型断言失败的开销远小于启动 defer + recover 机制
真正该做的：用 ok-idiom 替代 recover
所有可能失败的类型转换，都应使用带布尔返回值的形式：
if s, ok := val.(string); ok {
// 安全使用 s
} else {
// 处理类型不符，比如记录日志、返回 error、提供默认值
return fmt.Errorf("expected string, got %T", val)
}
这比任何 recover 更清晰、更高效、更符合 Go 的错误处理哲学。只有当你的代码明确**不控制输入来源**（比如解析不受信的 JSON 后做断言），且必须保证服务不挂，才考虑在外层加 recover——但它兜的是整个 handler，不是为某个类型转换单独设计的。
类型安全是 Go 的基石，依赖 recover 来“修复”类型错误，相当于用创可贴包扎骨折——表面止血，实则回避了真正需要加固的结构。
