内容列表服务分层比查询技巧更重要

内容系统做久了会发现，列表接口几乎总是最先变复杂。搜索、状态筛选、分类、标签、排序、统计、权限，一个入口承载的事情越来越多。如果这时只盯着 Sequelize 查询技巧看，通常治不了根。

我比较认可的拆法是三层：

• 控制器层只做参数接收和响应结构。
• 服务层负责业务规则、筛选组合和权限约束。
• 仓储层专门落 Sequelize 查询。

这样一来，查询本身就不需要知道页面为什么要这个字段，也不用顺手处理权限和展示文案。列表接口真正怕的不是条件多，而是职责混在一起之后没人能安全调整。

分层带来的好处很现实：新增筛选项时不必从头翻整条调用链，统计和明细也能独立优化。对内容系统来说，这比写一条“很厉害”的 ORM 查询更有长期价值。

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

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

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

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