类型断言适合已知有限具体类型的场景，如处理json.unmarshal后的map[string]interface{}，需用双返回值安全断言；反射仅用于类型完全未知或泛化操作，二者不可混用。
类型断言适合什么场景
当你清楚接口变量可能的几种具体类型，且数量有限（比如 string、int、[]interface{}），就该用类型断言——它快、安全、可读性强。
- 典型场景：处理
json.Unmarshal后的map[string]interface{}，逐层取值时对每个字段做v.(string)或v.([]interface{}) - 必须用双返回值写法：
s, ok := v.(string)；单写v.(string)一旦失败直接 panic - 注意嵌套结构：JSON 解析出的数组是
[]interface{}，不是[]map[string]interface{}，强行断言会报错interface conversion: interface {} is []interface {}, not []map[string]interface {} - 不能跨底层类型转换：比如
int64断言成int会失败，反射也帮不了——得显式调用int(v.(int64))
反射该在什么时候上
只有当类型完全未知、结构深度不确定、或需要泛化操作（如自动 map→struct 绑定、通用 deep-copy、框架级序列化）时，才引入 reflect 包。
- 典型场景：写一个通用配置加载器，输入任意 struct 指针和
map[string]interface{}，自动填充字段 -
reflect.ValueOf(v).Kind()看“是什么类”，.Type()看“叫什么名”，二者常需配合判断（比如Kind() == reflect.Ptr但Type().Elem()才是真实类型） -
reflect.Value.Convert()只支持同一底层类型的转换（如int32 → int64），且要求值可寻址；想把[]byte转string？得手动调用string(b)，反射不接管这种语义转换 - 性能损耗明显：一次
reflect.TypeOf+reflect.ValueOf调用开销远高于多次类型断言，别在 hot path 里滥用
为什么不能用反射代替所有类型断言
因为反射不是“更高级的断言”，而是不同维度的工具：断言回答“是不是这个类型”，反射回答“它到底长什么样、能怎么动”。混用反而增加风险。
- 常见误用：看到
interface{}就反射探查，其实多数时候用switch v.(type)更清晰、更快、更易调试 - 反射无法绕过 Go 的类型系统限制——比如你拿不到私有字段、不能给 unexported 字段赋值（除非用
unsafe，那已超出本文范围） - 错误信息晦涩：
panic: reflect: call of reflect.Value.Interface on zero Value这类提示比interface conversion: interface {} is nil, not string更难定位 - 编译期零检查：反射代码哪怕写错了类型路径，也能编译通过，直到运行时才崩
组合策略：断言优先 + 反射兜底
实际项目里最稳的路，是先用类型断言覆盖主流路径，再用反射处理边缘 case，中间加明确 fallback。
立即学习“go语言免费学习笔记（深入）”；
- 例如解析 API 响应：主逻辑按文档假设字段是
string或int，用断言；若遇到新字段或类型变异（比如某字段从int改成string），再 fallback 到反射做兼容解析 - 封装一个
safeConvertTo[T any](v interface{}) (*T, error)函数，内部先尝试AssignableTo判断，失败再考虑是否需特殊规则（如字符串数字转 int），而不是一上来就全量反射 - 永远检查
reflect.Value.IsValid()和.CanInterface()，空值、未导出字段、不可寻址值都可能让反射调用静默失败或 panic
真正容易被忽略的点是：类型断言失败不是 bug，而是设计的一部分；而反射一旦出错，往往意味着你本不该用它——先问自己“我是不是在试图绕过类型系统”，答案是就该回头重审接口契约。
