泛型CRUD不能直接传入结构体指针，因Go泛型编译期类型擦除导致ORM反射失败；必须用约束接口（如Table）限定指针类型并实现TableName()，避免反射取名和类型断言陷阱。
泛型函数能显著减少CRUD代码冗余，但直接套用会踩反射和类型擦除两个坑
为什么泛型CRUD不能直接传入结构体指针
常见错误是把 *User 直接传给泛型函数，然后在函数里调用 db.Insert(item) —— 这会导致 gorp 或 sqlx 反射出 *interface{} 或底层空接口类型，表名识别失败，报错 table name not found for type interface{}。
根本原因是：Go泛型在编译期做类型擦除，T 在运行时无法保留原始结构体名；而ORM依赖反射获取结构体标签和名称，必须让 ORM 看到具体类型（如 *User），而不是泛型参数 T 的抽象表示。
- 泛型函数内不能对
T做reflect.TypeOf(t).Name()获取真实表名 - 即使传入
*User，若函数签名是func Insert[T any](t T)，t是值拷贝，ORM 无法拿到指针地址，导致插入失败或字段为空 - 正确做法：泛型约束必须显式限定为指针类型，且要求结构体实现某个接口（如
TableName() string）
泛型CRUD函数必须带约束条件
不加约束的 [T any] 是危险的起点。真正可用的泛型 CRUD 必须强制类型具备可持久化能力：
立即学习“go语言免费学习笔记（深入）”；
- 定义接口：
type Table interface { TableName() string } - 泛型约束写成：
[T Table]，这样所有传入类型都必须实现TableName() - MongoDB 场景下还需额外约束：
[T Table & bson.Marshaler]，否则collection.InsertOne会因类型不匹配 panic - SQL 场景中，若用
sqlx，需确保结构体字段有dbtag，泛型本身不校验 tag，靠开发者约定
示例签名：func InsertOne[T Table](ctx context.Context, coll *mongo.Collection, doc T) error
批量操作泛型函数要小心协程与切片底层数组共享
像知识库中给出的 BatchProcess[T any] 示例，直接切片传递 data[i:end] 给 goroutine，在高并发下可能引发数据竞争或静默覆盖 —— 因为切片共用底层数组，而原切片后续还在被修改。
- 必须显式复制子切片：
batch := make([]T, end-i); copy(batch, data[i:end]) - 不要在 goroutine 中直接使用
data[i:end]，尤其当data是从数据库查询结果复用的同一块内存时 - 如果
T包含指针字段（如*string），复制切片不等于深拷贝，仍需按业务判断是否需 clone - 性能提示：小批量（1000）建议改用 channel + worker 模式，避免栈爆炸
泛型+反射混合使用时，类型断言优先于反射取名
当你需要在泛型函数里动态构造 SQL 或构建 filter，又无法通过接口获取表名时，唯一安全路径是做一次类型断言，而非依赖 reflect.TypeOf(T).Name()：
- 写法：
if u, ok := any(t).(User); ok { return u.TableName() }—— 显式、可控、编译期可查 - 避免：
reflect.TypeOf(t).Elem().Name()，因为t是泛型参数，reflect.TypeOf(t)返回的是reflect.Type对应擦除后的类型，不是原始结构体 - 更稳妥方案：泛型函数只做流程控制，表名、字段映射等元信息由调用方通过参数传入，例如
func Update[T any](coll *mongo.Collection, filter bson.M, update bson.M, opts ...*options.UpdateOptions)，把“通用”和“定制”解耦
最易被忽略的一点：泛型 CRUD 的价值不在“写一遍适配所有”，而在“写一遍后，新增模型只需加一个 TableName() 实现，不用动 CRUD 函数本身”。一旦开始在泛型函数里写 if/else 判断具体类型，就退回了反射老路，还丢了类型安全。
