hasone应写在不含外键的主表结构体上，如user表无userid字段而profile表有，则user用hasone、profile用belongsto；gorm只依据外键物理位置判定关系方向，不依赖业务语义。
HasOne 关联该写在哪张结构体上
只看外键字段物理位置：如果外键在「被关联表」（比如 Profile 表里有 UserID 字段），那 User 用 HasOne，Profile 用 BelongsTo。写反了会导致 Preload 查不到数据、Create 不写外键、AutoMigrate 建不出外键约束。
常见错误是被业务语义带偏——“用户有一份档案”不等于 User 必须用 HasOne；GORM 只认字段在哪张表，不认中文描述。
-
User结构体里声明Profile Profile `gorm:"foreignKey:UserID"` -
Profile结构体里必须有UserID uint字段（类型必须和User.ID一致） - 别漏掉
UserID的索引声明：UserID uint `gorm:"index"`
foreignKey 和 references 标签为什么必须显式写
GORM 默认按命名规则推断外键，但实际项目中极易失效：字段名稍有偏差（比如叫 OwnerID 而非 UserID）、主键非 ID（比如是 Code 或 UUID）、类型不一致（User.ID 是 uint，但 Profile.UserID 写成 int64），都会让关联静默失败。
-
foreignKey写在拥有关系的结构体字段上，表示“本表用哪个字段存对方的 ID”，例如Profile User `gorm:"foreignKey:UserID"` -
references必须配套使用，指明“对方表用哪个字段被引用”，默认是ID，但如果User主键叫Code，就得写references:Code - 字段类型必须严格一致：
User.ID uint→Profile.UserID uint，不能是int或int64
Preload 和 Joins 查询怎么选
Preload 发两条 SQL（先查 users，再用 IN 批量查 profiles），适合需要嵌套结构且主表结果集不大；Joins 是单条 LEFT JOIN，能对关联表字段加 WHERE，但返回扁平结构，需手动映射。
- 用
Preload：需要完整嵌套对象，比如db.Preload("Profile").Find(&users)，支持链式预加载如Preload("Profile.Address") - 用
Joins：要过滤关联字段，比如 “查真实姓名含 admin 的用户”，得写db.Joins("LEFT JOIN profiles ON profiles.user_id = users.id").Where("profiles.real_name LIKE ?", "%admin%") -
Preload不等于JOIN，它底层是子查询 +IN，无法做INNER JOIN或条件限制关联表非空
AutoMigrate 为什么没建外键约束
AutoMigrate 不会自动加外键约束，除非所有条件同时满足：外键字段存在、类型匹配、foreignKey 和 references 标签显式写全、且字段名与标签值完全一致。
- 确保
Profile.UserID字段已定义，且类型和User.ID一致 - 在
Profile的User字段上写全标签：gorm:"foreignKey:UserID;references:ID" - 如果外键字段叫
UserRefer，标签必须是foreignKey:UserRefer，不能只靠命名猜测 - 少写一个
references，或类型差一个字节（uintvsuint32），AutoMigrate都只会建普通字段，不建FOREIGN KEY
最容易被忽略的是字段类型一致性——哪怕只差一个符号位，GORM 就拒绝建约束，且不报错，只静默跳过。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
