Go反射生成SQL字段名需统一用json标签、跳过匿名字段、手动映射time.Time等类型、列名加反引号、字符串设默认长度、显式处理主键索引及时间默认值。
struct标签没写对，gorm和sqlx生成的字段名就全错
Go反射本身不关心数据库，真正影响SQL建表语句的是你用的ORM或工具库怎么解析struct字段。比如gorm默认看gorm标签，sqlx看db标签，而手写反射代码时若直接取field.Name，就会生成大驼峰字段（如UserName），但MySQL习惯用user_name。不统一标签规则，后续加索引、写查询都会踩坑。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 统一用
json标签作为字段名来源（兼容性好，且多数反射生成SQL的工具都支持 fallback 到它），例如：UserName string `json:"user_name" gorm:"column:user_name"` - 避免只依赖
field.Type.Name()——它返回的是类型名，不是字段名；要用field.Tag.Get("json")并手动解析omitempty等修饰 - 如果用
gorm，注意gorm:"primaryKey"这类标签不会自动转成PRIMARY KEY，得在反射逻辑里显式判断strings.Contains(tag, "primaryKey")
反射遍历struct时忽略匿名字段和嵌套结构体
Go的reflect.StructField.Anonymous为true时，该字段是内嵌结构体，比如type User struct { BaseModel; Name string }。若反射代码没跳过Anonymous == true的字段，就会把BaseModel的ID、CreatedAt重复当新字段处理，导致建表语句里出现两个id列。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 遍历
reflect.TypeOf(t).NumField()后，对每个field先检查field.Anonymous，为true则continue - 不要递归展开嵌套struct——建表语句只对应单表，嵌套结构体应提前扁平化或报错提示，否则生成的SQL会漏外键或类型错乱
- 用
field.PkgPath != ""判断是否为导出字段，非导出字段（小写开头）无法被反射读取标签，直接跳过
time.Time和*string这类类型在SQL中没有直译，必须手动映射
反射拿到field.Type只能知道是time.Time，但MySQL里对应的是DATETIME还是TIMESTAMP？是NULL还是NOT NULL？这些信息不在类型里，而在标签或上下文逻辑中。同理，*string表示可空字符串，但反射不会自动给你加DEFAULT NULL或NULL约束。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 建个映射表：
map[reflect.Type]string，例如reflect.TypeOf(time.Time{})→"DATETIME"，reflect.TypeOf("")→"VARCHAR(255)" - 判断是否指针类型用
field.Type.Kind() == reflect.Ptr，再用field.Type.Elem()取实际类型，避免把*int64当成int64处理 - 是否允许NULL不能只看是否指针——有些业务要求
string字段也设为NULL，这时得查标签里有没有sql:",null"或自定义nullable:"true"
生成CREATE TABLE时没处理关键字冲突和长度限制
直接拿json标签值当列名，遇到order、group这种MySQL关键字就语法错误；另外VARCHAR不指定长度（如VARCHAR()）在MySQL 8.0+会报错，但反射代码若没给默认值，就真会生成空括号。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 列名用反引号包裹：
`<col>`，哪怕不是关键字也加上，省去判断成本 - 字符串类型必须设默认长度：没在标签里声明
size时，统一用VARCHAR(191)（适配utf8mb4 + 索引限制） - 主键、索引、唯一约束不能只靠标签存在就加，要显式收集——比如扫描所有字段，找出
gorm:"uniqueIndex"，再单独拼UNIQUE KEY子句，否则建表语句不完整
最麻烦的其实是时间字段的默认值：MySQL里CURRENT_TIMESTAMP不能用于非TIMESTAMP类型，而DATETIME要写CURRENT_TIMESTAMP得加ON UPDATE CURRENT_TIMESTAMP才合法。这些细节不硬编码进反射逻辑，生成的SQL大概率执行失败。
