belongsToMany 中间表不要只当桥接表

Sequelize 的 belongsToMany 很方便，几行配置就能把多对多关系跑起来。可到了真实业务里，我越来越少把中间表只当“两个外键的过桥结构”，因为它往往很快就会承载排序、来源、状态和时间这些额外信息。

以博客系统为例，文章和标签看起来只是简单多对多，但很快你就会遇到这些需求：标签展示顺序、某个标签是否由编辑人工推荐、标签绑定是否需要审核。这个时候，如果中间表一开始没有被当成正式模型来设计，后面补字段和改约束会比较痛苦。

我更推荐两步走：

• 先承认中间表是领域对象的一部分，不要把它藏起来。
• 真有业务字段时，直接显式定义 join model，而不是一直依赖默认表。

这样做的好处是查询表达更稳定，后续也更容易在中间层加索引和审计字段。多对多关系本身不复杂，复杂的是你愿不愿意给它留成长空间。

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

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

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

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