必须用 reflect 的场景是运行时才能确定结构，如动态 json 字段、n 层嵌套 map、orm 字段映射；泛型因需编译期类型参数而无法适用，reflect 可读 tag、赋值字段、动态调方法，但性能低、类型不安全，应与泛型分层协作而非替代。
什么时候必须用 reflect，泛型完全没用
当你面对的数据结构在编译期根本不存在，reflect 就是唯一选择——泛型连类型参数都写不出来。
- 用户上传一个 JSON 文件，字段名是随机的（比如
{"user_12345": {"name": "Alice"}}），你无法提前定义 struct - 配置文件嵌套了 N 层
map[string]interface{}，键名只有运行时才确定 - ORM 要根据
struct的json:或db:tag 自动映射字段，而字段名、tag 内容、嵌套深度全由用户代码决定
这些场景下，泛型函数签名要求显式写出类型参数，例如 func Parse[T User](data []byte)，但你根本不知道 T 是什么。而 reflect.ValueOf(v).FieldByName(name) 可以直接按字符串查字段，不依赖任何编译期类型声明。
reflect 能干而泛型不能干的三件事
泛型是编译期特化，它生成的是“已知类型”的专用代码；reflect 是运行时探查，它操作的是“此刻这个值”的真实结构。
-
reflect可以读取并解析任意struct的reflect.StructTag，比如提取json:"id,omitempty"中的omitempty标志；泛型做不到——它看不见 tag -
reflect能对interface{}值做字段赋值：rv.FieldByName("Name").SetString("Bob")；泛型无法绕过类型系统直接写字段 -
reflect支持动态方法调用：rv.MethodByName("Save").Call(nil)；泛型没有“按名字找方法”这回事，只能靠接口约定
像 json.Unmarshal 这种底层逻辑，必须靠 reflect.Value.FieldByName 和 reflect.StructTag 才能工作。泛型在这里不是“不够好”，而是“根本不在同一条跑道上”。
立即学习“go语言免费学习笔记（深入）”；
泛型里调 reflect.TypeOf 不是 bug，而是分层设计
泛型负责收口类型安全，reflect 负责探查结构细节——两者不是非此即彼，而是各干各的活。
- 你可以写一个泛型校验函数
func Validate[T any](v T) error，内部用reflect.ValueOf(v)检查字段 tag，既享受泛型的类型约束，又获得反射的动态能力 - 但要注意：在循环里反复调用
reflect.ValueOf会明显拖慢性能，因为每次都有内存分配和类型检查开销 -
reflect.Value.Interface()返回的是interface{}，类型信息丢失；后续若需方法调用，得立刻断言回具体类型或接口，否则容易 panic
真正难的不是语法怎么写，而是判断：这个需求，到底是“编译期可穷举”，还是“必须等数据进来才知道”？前者交给泛型或接口，后者才轮到 reflect。
别用 reflect 模拟多态，也别指望它替代接口
reflect 不能替代接口，也替代不了泛型的编译期保障。拿它去模拟多态，往往换来的是性能损耗、panic 风险和 IDE 失效。
- 业务逻辑中优先用接口，比如
type Storer interface { Save() error }，比用反射调Save方法安全得多 -
reflect无法绕过导出规则访问小写字段——Go 的克制设计意味着你没法靠它实现 Java 那种动态代理 - 泛型无法生成新类型，
reflect也无法在运行时创建 struct 实例或方法；它们都受 Go 类型系统的边界约束
容易被忽略的一点是：reflect 的灵活性是有代价的——它让类型错误只在运行时暴露，IDE 无法跳转、补全、推导。写的时候爽，查 bug 的时候才意识到，那段“通用逻辑”其实没人敢改。
