GORM Gen 将 SQL 查询从运行时字符串拼接升级为编译期类型安全的 Go 方法调用，如 Where(t.Name.Eq("foo")) 可在编译阶段捕获字段名错误、类型不匹配等问题，而 Where("name = ?", "foo") 则无法规避 SQL 注入与重构漏改风险。
硬编码 SQL 字符串在 GORM 项目里不是“省事”，而是埋雷——字段名写错、类型不匹配、SQL 注入风险、重构时漏改，全靠人肉检查。GORM Gen 的价值不是“多一个工具”，而是把查询从字符串拼接变成编译期可校验的 Go 方法调用。
为什么 Where(t.Name.Eq("foo")) 比 Where("name = ?", "foo") 更可靠
前者是类型安全的链式调用，后者是运行时才解析的字符串。关键差异不在写法，而在编译阶段能否发现问题：
-
t.Name是生成代码里定义的字段对象，如果数据库表删了name字段，t.Name就会报未定义，编译直接失败 -
Eq()方法只接受与字段类型一致的参数：比如t.Age.Gt(18)接收int，传"18"会编译报错；而字符串拼接完全不管 - 字段别名、软删除字段（如
deleted_at）自动被过滤进WHERE条件，不用手动加AND deleted_at IS NULL - IDE 能对
t.ID、t.CreatedAt做完整补全，不会出现手敲"creat_at"这种低级错误
gentool 生成失败常见原因和绕过方式
很多团队卡在第一步：命令行跑 gentool 报错退出，但没提示具体哪张表或哪个字段有问题。实际排查路径很窄：
- MySQL 8.0+ 默认开启
sql_mode=ONLY_FULL_GROUP_BY，而gentool内部某些元数据查询可能触发该限制——临时关闭：执行SET sql_mode=(SELECT REPLACE(@@sql_mode,'ONLY_FULL_GROUP_BY','')); - 表里有 enum 类型字段且值含空格或特殊字符（如
"user active"），Gen 会因无法映射到 Go 枚举而中断——改用string类型，或在gen.Config中设置FieldNullable: true -
-tables参数指定表名时用了反引号（`users`）或大小写混用（USERS），MySQL 表名默认大小写敏感——统一用小写、无引号：-tables "users,orders" - 连接 DSN 缺少
parseTime=True，遇到TIMESTAMP字段会 panic ——必须显式加上
生成代码后，query.User 的 CRUD 方法怎么用才不踩坑
生成的 query.User 不是万能胶，它依赖底层 *gorm.DB 实例的状态。最容易忽略的是事务和上下文传递：
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 批量插入用
query.User.Create(dataSlice)时，如果dataSlice里某条记录违反唯一索引，整个操作会回滚——但错误信息只返回第一个失败项，不会告诉你第 5 条也错了 - 带事务的操作必须传入已开启事务的
*gorm.DB，不能直接用query.User.WithContext(ctx).Create(...)——正确姿势：tx := db.Begin(); defer tx.Rollback(); query.UseDB(tx).User.Create(...) -
Take()和First()都查单条，但Take()不按主键排序，First()默认按主键升序——如果表没主键，First()可能 panic - 软删除字段（
deleted_at）默认启用全局作用域，但如果你手动写了Unscoped()，记得在生成的 query 对象上调用：query.User.Unscoped().Find(...)，而不是对底层db调用
自定义 SQL 模板注释里哪些写法会失效
Gen 允许在 interface 方法上用注释写 SQL 模板，但不是所有语法都支持。真正能用的只有有限子集：
- 条件块必须用
{{if .Name}}，不能用{{if .name != ""}}——Gen 只识别简单非空判断，不支持表达式 - 参数绑定只能用
@name，不能写成:name或$1——否则生成的代码里会漏掉参数绑定逻辑 - 表名不能硬编码，必须用
@@table占位符，否则生成的 SQL 里还是字符串，失去类型安全 - JOIN 子句里不能引用别名字段，比如
JOIN orders o ON u.id = o.user_id后，o.created_at在模板里无法被识别为字段——得拆成两个独立查询再合并
最常被忽略的点：生成的 query 包默认不导出字段对象（如 User.ID），如果业务层需要直接访问字段元信息（比如做动态列筛选），得在 gen.Config 里加 FieldNamingStrategy: gen.NamingStrategy{NoPrefix: true} 并确保生成目录可写，否则 t.ID 这类引用会编译失败。
