类型断言适用于类型有限、分支逻辑各异且需直接访问字段或调用特有方法的场景；必须配合ok检查，避免panic，慎用于不可控数据源，且不校验业务逻辑。
接口断言不是万能转换器，它只解决「我知道可能是什么类型，且必须做类型区分」这一类问题；盲目套用 interface{} + 断言反而让代码更脆弱、更难维护。
什么时候该用类型断言而不是反射或泛型
当你面对的是有限、明确、业务语义清晰的几种类型（比如 API 返回的 *User、*Order、*Error），且每种类型需要不同字段访问或方法调用时，类型断言比反射更轻量、比泛型更直接。
- 反射适合「完全未知结构」的通用解析（如日志字段提取），但性能差、错误难定位
- 泛型适合「同一操作逻辑，仅类型参数不同」（如
Map[T, V]），但无法处理字段名/行为差异大的类型 - 类型断言适合「类型少、分支逻辑各异、需直接访问字段或调用特有方法」的场景
value, ok := x.(T) 必须带 ok 检查
不带检查的 x.(T) 在断言失败时会 panic，线上服务里基本等同于埋雷。哪怕你「觉得」这里只能是 *Person，只要上游数据来源不可控（比如 JSON 反序列化后塞进 interface{}），就必须加 ok。
- 错误写法：
person := data.(Person)—— 一旦data是map[string]interface{}或nil，直接崩溃 - 正确写法：
if person, ok := data.(Person); ok { ... } - 注意指针：
data.(*Person)和data.(Person)是两种类型，不能混用
用 type switch 替代一长串 if-else if
当要判断的类型超过 3 种，type switch 更易读、更不易漏 case，编译器还能帮你检查是否覆盖了所有已知类型（配合 default 处理兜底）。
switch v := data.(type) {
case *User:
log.Printf("user: %s", v.Name)
case *Order:
log.Printf("order ID: %d", v.ID)
case error:
log.Printf("error: %v", v)
default:
log.Printf("unknown type: %T", v)
}
-
v在每个case中自动具有对应类型，无需再断言 -
default不是可选的——它捕获所有未列出的类型，避免静默丢弃 - 不要在
case里写v.(*User)，那会覆盖type switch提供的类型绑定
从 map[string]interface{} 解析动态字段时，断言要嵌套验证
JSON 反序列化到 map[string]interface{} 后，嵌套字段仍是 interface{}，直接断言容易 panic。必须逐层检查 ok，尤其注意数字类型在 JSON 中默认是 float64。
- 错误示例：
name := userMap["name"].(string)—— 如果"name"字段不存在，或值为null，就会 panic - 安全写法：
if name, ok := userMap["name"].(string); ok { ... } - 数字字段：
if id, ok := userMap["id"].(float64); ok { userID := int64(id) }（JSON 数字总是float64） - 嵌套 map：
if meta, ok := userMap["meta"].(map[string]interface{}); ok { ... }
最容易被忽略的是：类型断言本身不校验业务逻辑。比如断言成功得到 *User，但它的 ID 是 0 或 Name 是空字符串，这些得靠后续逻辑判断，断言不管——它只管「是不是这个类型」。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
