Sequelize Query Builder 的组合方式

做后台列表时，最容易失控的代码通常不是控制器，而是那段越来越长的 findAll 参数对象。筛选、排序、分页、include、权限条件不断往里塞，最后查询虽然还能跑，但没人敢再改。

我比较认可的做法，是把查询条件拆成几个独立片段：基础 where、权限约束、排序规则、分页参数、关联加载。每一块先产出自己的配置，再由服务层统一组合。这样修改某个筛选条件时，不需要顺手去碰另一个逻辑。

这种写法的价值在于：

• 每个构建函数职责更单一，测试也更容易写。
• 查询行为发生变化时，能快速定位是哪一层拼错了。
• 新增筛选项时，不会不断复制那份巨大对象。

Sequelize 不是不能写大查询，而是复杂查询更适合被拆成清晰的构造步骤。Query Builder 的核心不是“炫技巧”，而是给演进留余地。

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

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

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

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