Sequelize 关联查询别在后台列表里无限 include

做内容后台时，列表接口很容易越做越贪心：想把作者名、分类、标签、审核状态、最近操作人一次全带出来。Sequelize 的 include 看上去正好可以满足这种愿望，但到了 2021 年，很多团队也已经踩出经验了，这条路要克制。

如果后台列表里关联查询无限扩张，查询性能和代码复杂度都会一起失控。

列表和详情不该追求同样的信息密度

详情页需要看到完整上下文，列表页通常只需要做筛选和初步判断。要是两者都追求“一次把所有关联带齐”，列表接口就会承担过多查询负担。

先承认列表和详情的职责不同，很多设计自然就会变轻。

include 越多，分页语义越容易变复杂

一旦牵涉一对多、多对多关联，分页结果就可能因为 join 方式和去重逻辑变得不直观。前端看到的是“这一页怎么少了几条”，后端看到的是 SQL 变得越来越难解释。

后台列表最怕的不是某次慢，而是每次需求都继续往这条链上叠。

适合预聚合的字段就别每次现场拼

比如标签数量、评论数量、最后一次审核人名称，这类信息如果是列表高频展示字段，可以考虑做冗余或预计算，而不是让每次列表查询都现场拉一大串关联。

这是典型的后台取舍问题：稍微增加写时维护，换来稳定的读路径。

include 也应该配白名单和默认层级

不是所有调用方都应该随意指定要展开哪些关联。尤其在 Feathers 这类服务接口里，最好先定义清楚哪些关联允许列表带出，哪些只能在详情或内部接口里取。

边界不先定，后面就会变成“谁都能顺手多拿一点数据”。

小结

Sequelize 的 include 很方便，但后台列表接口需要的不是“方便把所有关系全查出来”，而是稳定、可预测的查询成本。列表轻一点，详情重一点，这种分工通常更健康。