Clause 是 GORM 底层 SQL 构建入口，绕过模型层抽象，原样注入 ON/WHERE/SET 子句，不校验字段、不转义、不处理方言差异；适用于精细控制 JOIN、UPSERT 或数据库特有语法，非日常 CRUD 场景。
Clause 是 GORM 的底层 SQL 构建入口，不是万能拼接器
直接用 Clause 写 SQL 子句，本质是绕过 GORM 的模型层抽象，把控制权交还给开发者。它不校验字段是否存在、不自动转义、不处理方言差异——你写的 ON、WHERE、SET 会原样塞进最终 SQL。适合需要精细控制 JOIN 条件、UPSERT 行为或数据库特有语法（如 MySQL ON DUPLICATE KEY UPDATE）的场景，不适合日常 CRUD。
用 Clause 替换默认 JOIN 条件时，必须显式指定整个 ON 子句
GORM 默认的 Joins 只按外键推导 ON，一旦加 Clause，就得自己写全。比如想让 User 关联 Profile 但只查启用状态的记录：
db.Clauses(clause.Join{
On: clause.Expr("profiles.user_id = users.id AND profiles.status = 'active'"),
}).Joins("Profile").Find(&users)
注意点：
-
clause.Join的On字段必须是clause.Expr，不能传字符串或 map - 表名和字段名不会自动加引号，MySQL 大小写敏感时得手动写对（如
users.id而非Users.ID） - 如果同时用
Joins("Profile")和Clauses(clause.Join{...})，后者会完全覆盖前者生成的ON，不是追加
Upsert 场景下，Clause 是唯一可靠方式
PostgreSQL 的 ON CONFLICT 或 MySQL 的 ON DUPLICATE KEY UPDATE，GORM 的 FirstOrCreate 无法覆盖所有需求（比如要更新部分字段、带条件更新）。这时必须用 Clause：
// PostgreSQL
db.Clauses(clause.OnConflict{
Columns: []clause.Column{{Name: "email"}},
DoUpdates: clause.AssignmentColumns([]string{"name", "updated_at"}),
}).Create(&user)
// MySQL
db.Clauses(clause.OnConflict{
DoUpdates: clause.AssignmentColumns(map[string]interface{}{"name": gorm.Expr("VALUES(name)"), "updated_at": gorm.Expr("NOW()")}),
}).Create(&user)
关键细节：
-
Columns指定冲突检测列，必须是数据库真实列名（区分大小写），不能是 struct 字段名 -
DoUpdates里用gorm.Expr包裹动态值，否则会被当字面量插入（如"NOW()"会存成字符串，不是函数调用） - SQLite 不支持
ON CONFLICT的完整语法，Clause在不同驱动下行为不一致，务必在目标 DB 上实测
Where 子句里混用 Clause 和普通条件会丢失优先级控制
别以为 Where("a = ?", 1).Clauses(clause.Where{Expr: clause.Expr("b > 5")}) 就能拼出 WHERE a = 1 AND b > 5——GORM 会把两个条件都塞进 WHERE，但顺序不可控，且括号包裹逻辑由 GORM 自行决定。真要控制 AND/OR 分组或加括号，得全用 clause.Where 手动构造：
db.Clauses(clause.Where{
Expr: clause.And(
clause.Eq{"a": 1},
clause.Gt{"b": 5},
clause.Or(clause.Like{"c": "%x%"}, clause.IsNull{"d"}),
),
}).Find(&items)
这写法看着重，但好处是：逻辑清晰、无歧义、可复用。缺点是失去链式调用的简洁性，且 clause.And/clause.Or 不支持嵌套太深（超过 3 层易读性骤降）。
真正难的是跨方言适配——同一个 clause.Where{Expr: ...} 在 PostgreSQL 可能正常，在 SQL Server 却因函数名不同而报错。写之前先确认目标数据库的 SQL 语法，别指望 GORM 自动翻译。
