Go反射不能直接生成安全SQL，因其仅能读取字段名、类型和标签，无法理解主键、空值、时区等业务语义，易致SQL注入、NULL写入、时间错乱；ORM仅用其做元数据映射，SQL构建依赖预编译与参数绑定。
Go 的反射本身无法直接实现完整 ORM，它只是构建 ORM 的基础工具之一；真正生成和执行 SQL 需要配合结构体标签解析、SQL 模板拼接、数据库驱动调用三者协同——单独靠 reflect 包做不了这件事。
为什么不能只靠 reflect 生成 SQL
reflect 只能读取结构体字段名、类型、值和标签（如 json:"name"），但它不理解“主键”“外键”“是否可空”这些语义。没有额外约定或配置，它连哪一列该进 INSERT 都不确定。
- 字段是否忽略插入？得靠自定义标签，比如
orm:"-"或orm:"id,pk,auto" - 时间字段要不要转成
UTC？reflect不管时区，你得自己判断time.Time类型后手动格式化 - 嵌套结构体（如
User.Profile）不会自动扁平成表字段；ORM 必须显式禁止或展开，reflect默认只停在第一层
reflect 在 ORM 中的真实职责
它只干三件事：遍历字段、提取标签、取值。所有 SQL 构建逻辑必须由你写代码补全。
- 用
reflect.TypeOf(v).NumField()数出字段数，再用.Field(i)拿每个StructField - 用
sf.Tag.Get("orm")解析自定义标签，例如拆出column:name,type:varchar(255),notnull - 用
reflect.ValueOf(v).Field(i).Interface()拿运行时值，注意指针要先.Elem()，零值要跳过（除非显式允许 NULL）
示例片段：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
for i := 0; i < t.NumField(); i++ {
sf := t.Field(i)
tag := sf.Tag.Get("orm")
if tag == "-" {
continue
}
val := v.Field(i).Interface()
// 后续根据 tag 和 val 类型拼 WHERE / VALUES...
}
生成 INSERT SQL 时最容易漏的细节
很多人用反射拼 INSERT INTO user(name, age) VALUES(?, ?)，但立刻在生产环境翻车。
- 字段顺序不等于结构体声明顺序？错——
reflect严格按源码顺序遍历，但如果你用了匿名嵌入（type User struct { Base }），Base字段会插在中间，容易错位 -
nil指针字段（如*string）没判空就传给db.Exec，会 panic；必须提前转成sql.NullString或跳过 - MySQL 的
datetime和 PostgreSQL 的timestamp with time zone对time.Time的处理不同；反射拿不到数据库类型，你得在标签里写死orm:"type:datetime"并分支处理
执行 SQL 前必须绕开的反射陷阱
database/sql 的 Exec 和 Query 接口只接受 []interface{}，而 reflect.Value 不能直接塞进去——你得手动展开。
- 别写
db.Exec(sql, v.Field(i).Interface())：如果字段是[]byte，某些驱动会误判为 BLOB；应统一转[]byte或用sql.Named - 反射拿到的
int64和数据库期望的int32类型不匹配？不会报错，但可能截断；建议统一转成interface{}后由驱动处理，或加类型白名单校验 - 事务中多次反射结构体？避免重复解析——把
reflect.Type和字段映射缓存到sync.Map，否则每条语句都NumField()是性能黑洞
复杂点从来不在“怎么反射”，而在于“怎么让反射结果安全、可预测地对接 SQL 生命周期”。标签设计、空值策略、类型桥接、缓存粒度，这些才是实际卡住人的地方。
