Beego ORM一对一关联需配对使用rel(one)和reverse(one)：前者加在外键持有方（如AuthorInfo.Author Author），后者加在被引用方（如Author.AuthorInfo AuthorInfo），且必须显式打tag、字段类型匹配、外键值真实存在。
Beego ORM 处理一对一关联，核心就两条路：用 rel(one) 正向建外键，或用 reverse(one) 反向查关联数据；不能只靠结构体字段名自动推断，必须显式打 tag。
如何定义一对一模型（rel(one) 与 reverse(one) 必须配对）
一对一不是“有字段就行”，而是要明确哪张表存外键、哪张表负责反查。常见错误是只在一方加 tag，另一方没配，导致 RelatedSel() 查不到或 panic。
-
rel(one)加在外键持有方（比如AuthorInfo表里存了author_id），表示“我属于某一个 Author” -
reverse(one)加在被引用方（Author结构体上），表示“我能反查到唯一的 AuthorInfo” - 两个结构体的字段类型要匹配：
AuthorInfo.Author *Author和Author.AuthorInfo *AuthorInfo，不能是值类型或切片 - 如果用了
TableName()自定义表名，RegisterModel()仍需传指针：orm.RegisterModel(new(Author), new(AuthorInfo))
RelatedSel() 查一对一数据时为什么返回 nil？
这是最常踩的坑：调用 RelatedSel() 后字段仍是 nil，不是 ORM 没查，而是条件不满足或关系未命中。
- 确保查询主表时，外键字段（如
author_id）值非空且真实存在对应记录 -
RelatedSel()默认只查一级关联，不会递归查AuthorInfo的再下级关联 - 若用
QueryTable("author_info").Filter(...).RelatedSel().All(&list)，它会尝试查AuthorInfo.Author，但Author字段是*Author类型，所以能查；反过来用QueryTable("author")...查Author.AuthorInfo才是典型场景 - 调试时打开
orm.Debug = true，看生成的 SQL 是否含LEFT JOIN和对应 ON 条件
原生 SQL 与 ORM 混用时一对一字段怎么取？
当 Raw() 查询需要带关联字段（比如同时取 author.name 和 author_info.phone），别指望 ORM 自动映射结构体字段 —— 它只认 Values() 或 ValuesList() 返回的 map/slice。
- 用
Values(&maps)时，SQL 中的列别名必须和结构体字段名一致，或用 map key 显式接收："phone": "author_info.phone" - 如果结构体字段名是
Phone，SQL 别名得写成author_info.phone AS phone（小写），否则Values()不识别 - 想复用模型结构体接收，得自己定义新 struct，字段名和 SQL 别名严格对应，再用
Raw().QueryRow() / QueryRows()+Scan() -
RelatedSel()和Raw()不能混用：前者走 ORM 关系链，后者绕过所有模型逻辑
真正容易被忽略的是：一对一关系在数据库层面是否真建了外键约束。Beego ORM 不校验、不强制、不报错，哪怕你 tag 写对了，但 MySQL 表里没加 FOREIGN KEY，查询时遇到脏数据（比如 author_id = 999 但 author 表无此 ID），结果就是 AuthorInfo.Author 为 nil —— 这时候得靠业务层判空，而不是等 ORM 抛异常。
