GORM一对一关联由外键位置和语义共同决定：外键在从表用has one，外键在主表用belongs to；错用会导致预加载失效、数据查不到或迁移失败。
GORM 里的一对一不是靠“写法统一”实现的，而是靠外键位置 + 关联方向共同决定的。用 has one 还是 belongs to，关键看「谁持有外键」和「语义上谁属于谁」，选错会导致预加载失效、数据查不到、甚至迁移失败。
怎么选 has one 还是 belongs to
外键在哪张表，就决定了该表对应模型用哪个关联标签：
-
has one：外键在「被拥有方」（从表）——比如CreditCard表里有user_id字段，那User模型就该用has one -
belongs to：外键在「当前模型」（主表）——比如User表里有company_id字段，那User模型就该用belongs to
常见错误是把 has one 和 belongs to 当成可互换的同义词。实际上它们生成的 SQL 完全不同：has one 预加载时会查从表 WHERE user_id IN (...)，而 belongs to 预加载时会查主表 WHERE id = ? —— 如果外键放反了，Preload("CreditCard") 可能返回空，但不会报错。
外键字段名不叫 XXXID 怎么办
GORM 默认按「关联结构体名 + ID」推导外键（如 CreditCard → credit_card_id），但实际业务中常遇到 user_name、owner_code 这类非标准命名。必须显式声明：
立即学习“go语言免费学习笔记（深入）”；
- 用
foreignKey指定当前模型里哪个字段是外键（如CreditCard CreditCard `gorm:"foreignKey:UserName"`） - 用
references指定它引用的是对方模型的哪个字段（如UserName string对应User.Name，就得加references:Name） - 两个标签要配对出现，只写
foreignKey不写references时，GORM 仍会默认找对方的ID字段，容易查不到数据
示例：
type User struct {
gorm.Model
Name string `gorm:"index"`
CreditCard CreditCard `gorm:"foreignKey:UserName;references:Name"`
}
type CreditCard struct {
gorm.Model
Number string
UserName string
}
Preload 一对一关联总查不到数据
最常见原因是没指定 Model 或用了错误的链式调用方式：
-
db.Preload("CreditCard").Find(&users)是对的；但db.Preload("CreditCard").Where(...).Find(&users)会先执行 WHERE 再预加载，没问题；而db.Where(...).Preload("CreditCard").Find(&users)就可能出问题——GORM v2 中Preload必须在Find前且紧邻，否则会被忽略 - 如果关联字段是指针类型（如
CreditCard *CreditCard），Preload仍能工作，但要注意：数据库该字段为 NULL 时，Go 结构体里就是 nil，别直接访问user.CreditCard.Number，得先判空 - 想查带条件的关联（比如只加载状态为 active 的信用卡），得用
Preload("CreditCard", db.Where("status = ?", "active"))，不能写成db.Where("status = ?").Preload(...)
AutoMigrate 时外键没建出来
GORM v2 的 AutoMigrate 不会自动创建外键约束（foreign key constraint），只建字段。即使你写了 foreignKey 标签，生成的 SQL 里也不会有 FOREIGN KEY 定义。这意味着：
- 数据库层面无级联、无引用完整性保障
- 手动删用户时，信用卡记录不会自动删（除非你在 Go 层用
Association().Delete()） - 如果真需要数据库级外键，得自己写
db.Exec("ALTER TABLE credit_cards ADD CONSTRAINT fk_user FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE")
这恰恰是最容易被忽略的一点：开发时一切正常，上线后因缺少外键约束，导致脏数据堆积或级联逻辑失效，排查起来非常隐蔽。
