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 很难隔离瓶颈：是反射慢？还是逻辑分支太多？还是内存分配激增？

更隐蔽的是，它容易诱导“再加一个 if 就能支持新场景”的惯性，导致函数膨胀成难以拆分的巨石逻辑。

替代方案往往更简单且更安全

多数声称“必须用反射”的场景，其实有更可控的替代：

• 序列化/反序列化：优先用 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。