Eager Loading 的使用边界别放太宽

Sequelize 的 include 第一次用起来很爽，因为它帮你把关联数据一次带回来了。可一旦团队形成习惯，列表、详情、后台搜索全都开始层层 include，接口就会慢慢变成一坨难调试的 SQL。

我现在更愿意把 eager loading 当成“详情页能力”，而不是“默认查询方式”。列表页最重要的是稳定、轻量、可分页，很多关联字段其实完全可以二次查询或者在服务层聚合，而不需要每次都把整棵关系树带上。

比较实用的经验是：

• 列表页只带必要的一层关系。
• 后台管理页如果有复杂筛选，不要把所有关系都交给一次查询解决。
• 一旦 include 超过两层，就应该怀疑是不是服务边界已经不清楚了。

Eager loading 真正的问题不在语法，而在使用边界。把它放在合适场景里，它是效率工具；放得太宽，它就是性能债务。

为什么这类问题总会在线上阶段突然变贵

围绕「Eager Loading 的使用边界别放太宽」这类判断，最容易被低估的地方，是大家前期总把它当成 ORM 写法偏好，而不是数据契约和查询边界。数据量小、调用方少的时候，字段命名、关联深度、分页方式、迁移顺序都像只是风格问题；一旦接口被更多页面复用，筛选、排序、统计和审计需求一起叠上来，之前没收住的边界就会同时在性能、排障和协作成本上爆出来。

落地时我会先卡住的检查项

• 先把输入 DTO、模型字段和最终 SQL 这三层对应关系看清，避免“接口语义已经变了，ORM 代码却还在偷偷兜底”。
• 把统计、明细、写操作和回滚路径拆开看，别让一个方便的查询顺手背上太多职责。
• 一旦这篇文章讨论的点已经影响到索引、事务或迁移顺序，就说明它不是微调，而是该补正式约束了。