不建议用反射在运行时动态生成SQL仓储层代码，因其开销大、类型信息丢失、SQL难调试、编译期无法捕获字段/表名错误；应改用go:generate等工具在构建前生成静态、类型安全的仓储代码。
为什么不用 reflect 自动生成 SQL 仓储层代码
直接说结论：不建议用反射在运行时动态生成 SQL 仓储层代码。Go 的反射开销大、类型信息在运行时丢失（如泛型约束、结构体字段 tag 的语义）、生成的 SQL 难以调试，且无法在编译期捕获字段名拼写错误或表名不匹配等问题。
更现实的做法是：用反射做**代码生成（code generation）**，即在构建前通过 go:generate + 自定义工具扫描结构体，输出静态的 *Repo 类型和方法。这样既保留类型安全，又避免运行时成本。
- 运行时反射调用
reflect.Value.FieldByName查字段 → 每次查询都触发反射，性能差，GC 压力高 - 字段 tag 如
db:"user_name"在反射中只是字符串，拼错不会报错，直到查不到数据才暴露 - JOIN、预加载、条件组合等逻辑无法靠反射自动推导，硬编码逻辑会迅速失控
go:generate 工具链怎么搭出可用的仓储生成器
核心思路是：写一个命令行工具（比如叫 genrepo），接收 Go 源文件路径，解析 AST，提取带特定注释标记的 struct，按模板生成 user_repo.go 这类文件。
关键点不是“能不能”，而是“怎么让生成结果可维护”：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 只处理显式标记的结构体，例如在 struct 上加
//go:generate repo或使用空接口注释// @repo - 依赖
golang.org/x/tools/go/packages解析类型，而非原始文本匹配，确保字段类型、嵌套结构、嵌入字段都能正确识别 - 生成的代码必须包含完整包声明、导入、方法签名，并把
db参数类型固定为*sql.DB或你封装的DBTX接口 - SQL 模板里禁止拼接字段名，全部走
?$占位符 +args...，避免 SQL 注入（哪怕字段来自 struct）
示例生成片段：
func (r *UserRepo) FindByID(id int64) (*User, error) {
var u User
err := r.db.QueryRow("SELECT id,name,created_at FROM users WHERE id = ?", id).Scan(&u.ID, &u.Name, &u.CreatedAt)
if err != nil {
return nil, err
}
return &u, nil
}
struct tag 怎么设计才方便生成器识别字段映射
tag 不是越复杂越好，重点是让生成器能无歧义地决定“这个字段对应哪个列”“是否忽略”“是否主键”。推荐最小可行集：
-
db:"id"→ 显式指定列名；db:"-"→ 完全跳过该字段（如密码哈希、临时状态） -
db:",pk"→ 表示主键（用于FindByID、Update的 WHERE 条件） -
db:",auto"→ 表示自增/默认值字段（插入时不写入，但 SELECT 后需赋值） - 不支持嵌套结构体自动展开（如
Address.Street），要求扁平化 struct 或手动写 JOIN 方法
错误示范：db:"name,omitempty" —— omitempty 是 JSON 场景概念，对 SQL 无意义，且会让生成器逻辑变重。
生成的仓储代码如何与业务逻辑解耦又不丧失灵活性
生成的 *Repo 类型必须是**可组合、可替换、可测试**的。这意味着不能让它直接依赖全局 sql.DB，也不能把事务控制逻辑塞进生成代码里。
- 所有方法第一个参数应为
ctx context.Context，便于超时和取消传播 - DB 依赖通过构造函数注入：
NewUserRepo(db DBTX) *UserRepo，其中DBTX是interface{ QueryContext(...), ExecContext(...) } - 批量操作（如
CreateMany）不自动生成，留白给手写——因为批量的事务边界、参数数量限制、分批策略必须由人判断 - WHERE 条件统一用
map[string]interface{}或专用条件结构体（如UserQuery{Status: "active", Limit: 10}），而不是靠反射遍历字段生成WHERE
真正难的从来不是“怎么生成”，而是“生成后哪部分必须手写、怎么预留扩展点”。比如软删除字段 deleted_at 的过滤逻辑，不可能靠 tag 自动加到每个 SELECT 里，得在 repo 方法里显式处理。
