Go反射不实现ORM，仅是ORM库自动映射结构体与数据库表的底层工具；它提供运行时类型操作能力，但不处理SQL生成、连接池、事务、方言差异等核心功能。
Go 的反射本身不实现 ORM，它只是 ORM 库（如 gorm、sqlx）用来自动映射结构体与数据库表的底层工具。你无法仅靠 reflect 包就写出一个可用的 ORM；但没有 reflect，主流 Go ORM 就无法做到结构体字段到 SQL 字段的自动绑定。
为什么不能直接用 reflect 实现完整 ORM
反射只提供运行时类型和值的检查与操作能力，它不处理：
- SQL 生成（比如
INSERT INTO users (name, age) VALUES (?, ?)） - 连接池管理、事务控制、预处理语句缓存
- 数据库方言差异（PostgreSQL 的
RETURNINGvs MySQL 的LAST_INSERT_ID()） - 字段标签解析以外的元数据（如索引、外键、软删除策略）
所以你在代码里看到的 reflect.StructField.Tag.Get("gorm") 或 reflect.Value.FieldByName("ID").Interface()，都只是 ORM 内部的一个环节，不是 ORM 本身。
struct tag + reflect.Value 是字段映射的核心路径
ORM 读取结构体字段时，依赖两件事：字段名（来自 StructField.Name）和数据库列名（来自 StructTag）。例如：
type User struct {
ID int64 `gorm:"primaryKey"`
Name string `gorm:"column:user_name;size:100"`
Age int `gorm:"not null"`
}
ORM 在插入前会做这些事：
- 遍历
reflect.TypeOf(User{}).NumField()获取所有字段 - 对每个
StructField调用field.Tag.Get("gorm")解析出column、primaryKey等语义 - 用
reflect.ValueOf(&u).Elem().Field(i).Interface()提取实际值 - 按顺序拼进 SQL 参数列表或 map 中
注意：reflect.Value.Interface() 返回的是 interface{}，ORM 需额外判断是否为零值、是否可扫描、是否支持 driver.Valuer 接口 —— 这些都不是反射能自动完成的。
反射带来的性能和安全代价必须正视
每次查询/插入都触发反射，比硬编码字段慢 3–10 倍（基准测试常见）。更关键的是：
-
reflect.Value.FieldByName是 case-sensitive 的，字段名写错（如UserNamevsusername）会导致静默 nil panic - 嵌套结构体（如
Address struct{ City string }）默认不会被递归映射，除非 ORM 显式支持embedded标签或深度遍历 - 私有字段（首字母小写）无法被
reflect导出，即使加了 tag 也会跳过 —— 所以gorm要求字段必须是 exported - 反射无法校验字段类型是否匹配数据库类型（比如把
string插入INT列），错误要等到执行 SQL 时才暴露
想绕过反射？可以，但代价是失去通用性
如果你明确知道结构体形状且不打算复用，完全可以不用反射：
func InsertUser(db *sql.DB, u User) error {
_, err := db.Exec("INSERT INTO users (user_name, age) VALUES (?, ?)", u.Name, u.Age)
return err
}
这种写法更快、更易调试、IDE 支持更好。但一旦新增字段、改表结构、换结构体，就得同步改 SQL 和参数列表 —— 这正是 ORM 要解决的问题。反射不是银弹，它是用运行时灵活性换编译期安全和性能的权衡结果。
真正容易被忽略的点是：哪怕用了 gorm，你也得自己确保 db.AutoMigrate(&User{}) 和 struct tag 的一致性；反射不会帮你发现 gorm:"column:name" 和数据库实际列名不一致的问题，这类错只能靠测试或日志暴露。
