GORM定义一对一关联需明确外键字段与结构体指针：主模型（如User）用指针字段引用从模型（如Profile），从模型定义匹配主键类型的外键字段（如UserID uint），并用gorm:"foreignKey:UserID"指定关联，外键字段须可导出且类型一致。
怎么用 GORM 定义一对一关联的 struct 字段
GORM 里实现一对一，核心是靠外键字段 + 结构体嵌套或指针字段，而不是靠“自动绑定”这种魔法。你得明确告诉 GORM 哪个字段是外键、关联到哪个模型、是否允许为空。
常见错误是只加 gorm:"foreignKey:UserID" 却漏掉 gorm:"constraint:OnUpdate:CASCADE,OnDelete:CASCADE" 或没设外键字段类型，导致迁移失败或查询时返回 nil。
- 主模型（如
User）里用指针字段引用从模型（如Profile），表示“一个用户最多有一个档案” - 从模型（
Profile）必须定义外键字段（如UserID uint），且类型要和主模型主键一致 - 在
Profile的gorm.Model标签里写gorm:"foreignKey:UserID"，不是写在User上 - 如果想预加载（Preload），必须对
User调用Preload("Profile")，GORM 不会自动 eager load
为什么 Preload("Profile") 有时返回 nil，但数据库里明明有数据
最常见原因是外键字段值为 0 或空，而 GORM 默认把 0 当作“无效 ID”，不触发关联查询；或者字段名和标签里的 foreignKey 值不一致，比如写了 gorm:"foreignKey:Uid"，但 struct 字段叫 UserID。
另一个隐蔽坑：如果你用 SELECT * 查询，但 Profile 表里有字段名和 User 表冲突（比如都叫 CreatedAt），GORM 解析时可能覆盖字段，导致 Profile 字段全为零值。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 检查迁移后
profiles表中user_id列是否非空且与users.id匹配 - 用
db.Debug().Preload("Profile").First(&user)看生成的 SQL，确认 JOIN 条件是否正确 - 确保
Profilestruct 的字段名首字母大写（可导出），否则 GORM 无法赋值 - 避免在
User中用匿名嵌入Profile，这容易引发字段重名和序列化混乱
使用 BelongsTo 还是 HasOne？区别在哪
HasOne 和 BelongsTo 都能实现一对一，但语义和外键位置相反：前者外键在“被拥有方”，后者在外键在“所属方”。实际选哪个，取决于你希望谁持有关系。
比如 User has one Profile → 外键 user_id 在 profiles 表；Profile belongs to User → 同样是 user_id 在 profiles 表。它们底层 SQL 一样，但 GORM 的预加载方向相反：db.Preload("Profile") 对应 HasOne，db.Preload("User") 对应 BelongsTo。
- 优先用
HasOne表达“主体拥有附属物”，更符合直觉（如 User → Profile） - 如果附属模型（如
Profile）需要频繁查回主模型，再加一个BelongsTo字段也行，但别重复建外键 -
HasOne默认要求外键非空，加gorm:"null"才允许为 NULL；BelongsTo默认就支持 NULL - 不要同时在两个 struct 里互相
HasOne，那会建两个外键，逻辑矛盾
软删除场景下一对一关联怎么处理
如果 User 开启了软删除（gorm.DeletedAt），但 Profile 没开，那么 Preload("Profile") 仍会查出已软删的 User 关联的 Profile —— 因为 GORM 默认不会把软删除条件透传到 JOIN 子句里。
这时候要么统一开启软删除（Profile 也加 gorm.DeletedAt），要么手动写 JOIN 查询，用 Joins("LEFT JOIN profiles ON profiles.user_id = users.id AND profiles.deleted_at IS NULL")。
- GORM v1.24+ 支持
Preload("Profile", func(db *gorm.DB) *gorm.DB { return db.Unscoped() })强制包含软删记录 - 但更稳妥的是：只要主模型用了软删除，附属模型也加上
gorm.Model，保持行为一致 - 别依赖
Profile的软删状态去控制User可见性，权限逻辑应放在业务层，不在关联定义里塞条件
