该用反射而非代码生成的情况是：输入结构完全不可预测、仅在启动或低频路径使用、项目小且迭代快；反之，性能敏感、需类型强约束或深度IDE协作时必须用代码生成。
什么时候该用 reflect，而不是代码生成？
反射适合处理运行时才确定结构的场景，比如通用 JSON 解析器、ORM 的动态字段映射、或调试工具里打印任意值。它省去了提前生成代码的流程，开发快，但代价是：性能损耗（reflect.Value.Interface() 有分配开销）、类型安全丢失（编译期无法检查字段是否存在）、IDE 支持弱（跳转/补全失效）。
以下情况优先选反射：
- 输入结构完全不可预测（如用户上传的任意 YAML 配置）
- 只在启动或低频路径使用（如 CLI 工具解析参数）
- 项目小、迭代快，没精力维护生成逻辑和模板
什么时候必须上代码生成（go:generate）？
当性能敏感、类型强约束或需要深度 IDE 协作时，代码生成几乎是唯一选择。典型如 gRPC stub、SQL 查询构造器、Protobuf 编解码——这些场景里，反射会拖慢吞吐、掩盖字段变更错误、让 go vet 失效。
常见触发点包括：
立即学习“go语言免费学习笔记（深入）”；
- HTTP handler 中高频调用的结构体序列化（
json.Marshal替换为生成的MarshalJSON方法） - 数据库模型需与 SQL 字段严格对齐，且字段增删必须同步报错
- 团队要求所有 API 响应结构带
Validate()方法，且验证逻辑需内联到字段标签
reflect 容易踩的坑有哪些？
最常被忽略的是反射值的可寻址性与设置权限。比如用 reflect.ValueOf(&v).Elem() 才能修改原变量；直接 reflect.ValueOf(v) 是只读副本。还有类型擦除问题：interface{} 经反射后，reflect.TypeOf 返回的是底层具体类型，但若原始值是 nil 接口，reflect.Value.Kind() 会是 Invalid，不是 Ptr 或 Struct。
其他高频陷阱：
- 对未导出字段（小写开头）调用
FieldByName返回零值，不报错也不提示 -
reflect.StructTag.Get("json")返回空字符串时，不代表没 tag，可能是json:"-" - 用
reflect.Copy复制 slice 时，目标必须已分配内存，否则 panic
生成代码真的比反射难维护吗？
不一定。现代生成工具（如 ent、oapi-codegen、自定义 gengo）已把模板和钩子封装得足够清晰。关键在分层：把「描述」（如 OpenAPI spec / struct tags）和「生成逻辑」分离。改字段只需动注释或 schema，不碰模板。
真正难维护的是混用——比如主体用生成代码，但某个字段用反射 fallback。这种设计会让 bug 只在特定数据下暴露，且排查时要同时查两套逻辑。
建议守住一条线：
- 同一类操作（如序列化）要么全反射，要么全生成
- 生成代码的入口统一放在
//go:generate注释里，不散落在 Makefile 或 CI 脚本中 - 生成文件加
// Code generated by ... DO NOT EDIT.头，避免手改被覆盖
反射的灵活性是假象，生成代码的“僵硬”反而是稳定性的来源。多数人低估了反射在复杂嵌套结构中的行为一致性成本——而高估了维护一个模板的难度。
