Go反射绕过编译期类型检查，导致运行时panic、IDE无法导航、静态分析失效；易因字段名拼写错误、未导出字段、零值误用等引发隐蔽bug；性能差且掩盖逻辑复杂度；泛型、结构体tag等显式方案更安全可控。
反射绕过了编译期类型检查
Go 的核心设计哲学之一是“显式优于隐式”，而 reflect 包让变量类型、字段名、方法调用都推迟到运行时才确定。这意味着：
var v interface{} = struct{ Name string }{Name: "Alice"}
val := reflect.ValueOf(v)
nameField := val.FieldByName("Name") // 拼写错误？字段不存在？编译器完全不报错一旦 "Name" 写成 "name" 或结构体字段被重命名，程序会在运行时 panic，且 IDE 无法跳转、无法重构、无法静态分析依赖链。
类型断言和 Value 转换极易出错
reflect.Value 和 reflect.Type 是运行时抽象，与原始 Go 类型无直接映射关系。常见陷阱包括：
- 对未导出字段调用
FieldByName返回零值，不 panic 但结果为空，难定位 - 忘记调用
Interface()就直接赋值给具体类型，触发 panic：panic: reflect: call of reflect.Value.Interface on zero Value - 用
SetString等方法修改不可寻址（unaddressable）的Value，比如从reflect.ValueOf(x)得到的副本
性能开销掩盖逻辑复杂度
反射本身慢（比直接调用慢 10–100 倍），但这不是维护难的主因；真正麻烦的是：为了“通用”，开发者常把反射嵌套多层——比如序列化库中同时处理指针解引用、接口动态派发、tag 解析、递归遍历。这种代码：
- 没有清晰的输入/输出契约（参数类型靠 runtime 判断）
- 无法用 go vet 或 staticcheck 有效检查
- benchmark 很难隔离瓶颈：是反射慢？还是逻辑分支太多？还是内存分配激增？
替代方案往往更简单且更安全
多数声称“必须用反射”的场景，其实有更可控的替代：
- 序列化/反序列化：优先用
encoding/json自带的 tag 支持，而非手写反射解析器 - 通用容器操作：用泛型（Go 1.18+）代替
interface{}+reflect，例如func Map[T, U any](s []T, f func(T) U) []U - 依赖注入或配置绑定：用结构体 tag + 显式解码函数（如
mapstructure.Decode），避免裸写reflect.StructField遍历
真正难维护的从来不是反射语法，而是当某天你发现 reflect.Value.Call 调用的函数签名在三个包外被悄悄改了，而整个项目里没有任何编译错误、也没有 test fail。
