一对多查询必须用RelatedSel()而非LoadRelated，因后者默认逐条查导致N+1性能陷阱；RelatedSel需紧接QueryTable后、All前调用，字段名须与结构体关联字段名一致且为指针类型，漏写orm:"rel(fk)"将静默失效。
一对多查询必须用 RelatedSel()，不能只靠 LoadRelated
Beego ORM 的 LoadRelated 默认按“逐条查”执行 N+1 查询，比如查 100 篇文章，再查每篇文章的作者，就会发 100 条 SQL —— 这不是关联查询，是性能陷阱。真正的一对多 JOIN 式加载，得用 RelatedSel() 配合 QueryTable。
常见错误现象：o.QueryTable(&Article{}).All(&articles) 后直接访问 articles[0].Author.Name 返回空或 panic，因为 Author 字段根本没查出来。
-
RelatedSel()必须紧跟在QueryTable之后、All()之前调用，顺序错就无效 - 字段名要和结构体中关联字段名一致，比如
Author *Author `orm:"rel(fk)"`，就得写RelatedSel("Author")，不能写"author"或"author_id" - 如果想查多级关联（如 Article → Author → AuthorInfo），得链式写
RelatedSel("Author").RelatedSel("Author.AuthorInfo")，但注意这会生成 LEFT JOIN，字段名冲突时需手动重命名
模型定义里外键字段必须显式声明 rel(fk)，且首字母大写
一对多关系不是靠表名或字段名自动推断的，Beego ORM 完全依赖 struct tag。漏掉 orm:"rel(fk)"，RelatedSel 就不生效，也不会报错，只会静默忽略。
典型错误：定义了 AuthorId int 字段但没加 tag，或者写了 author *Author（小写开头）—— Go 反射无法导出该字段，ORM 读不到，查出来永远是 nil。
- 正确写法：
Author *Author `orm:"rel(fk);column(author_id)"`，其中column明确指定外键字段名，避免歧义 - 如果主表（如 Article）不存外键，而是靠中间表实现一对多（实际是多对多变体），必须改用
orm:"rel(m2m)"并注册中间模型 - 关联字段类型必须是指针（
*Author），不能是值类型（Author），否则RelatedSel不识别
原生 SQL 查一对多更可控，特别是需要聚合或过滤关联数据时
当你要查“每个作者发了几篇文章”或者“只查有文章的作者”，用 ORM 的 RelatedSel 很难表达，这时候直接上 Raw() 更干脆。
常见坑：Values(&list) 返回的是 []orm.Params（map[string]interface{}），字段名全转成小写，且没有结构体绑定能力；而 QueryRow 或 QueryRows 配合 struct scan 要自己处理 NULL 和类型转换。
- 推荐组合：
o.Raw("SELECT a.id, a.title, au.name FROM article a LEFT JOIN author au ON a.author_id = au.id WHERE a.status = ?", 1).Values(&rows) - 如果结果要映射到结构体，用
o.Raw(...).QueryRows(&articles)，前提是articles是切片，且结构体字段名与 SELECT 列名完全匹配（大小写敏感） - 注意参数占位符是
?，不是$1或:name，MySQL 驱动只认?
RelatedSel 性能边界在哪？大数据量时必须设 limit
RelatedSel("Author") 底层是 LEFT JOIN，查 1000 篇文章 + 关联作者，SQL 只发一次，但结果集可能膨胀数倍（尤其一对多嵌套深时）。没加 Limit() 容易 OOM。
容易被忽略的点：JOIN 后的 ORDER BY 和 WHERE 条件如果写在主表字段上没问题，但一旦涉及关联表字段（如 WHERE au.status = 1），就可能漏掉主表无匹配的记录 —— 这时候得换 INNER JOIN 语义，而 Beego ORM 不提供显式 JOIN 类型切换，只能退回到 Raw()。
- 安全做法：总在
RelatedSel后加Limit(100)，业务侧分页控制数据量 - 调试时打开
orm.Debug = true，看生成的 SQL 是否真用了 JOIN，还是悄悄退化成多次查询 - 上线前务必关掉
RunSyncdb，它不会感知RelatedSel所需的外键约束，建表时漏加FOREIGN KEY会导致 JOIN 结果异常
