198 篇博文 含有标签「Node.js」

到了 2022 年，Node.js 关系型数据库生态里一个很明显的变化，就是 Prisma 开始越来越频繁地进入讨论。很多人原本已经熟悉 Sequelize，这时自然会问：还要不要换？

2022 年 Prisma 热度越来越高，很多团队开始认真讨论要不要把 Prisma Migrate 引进来。但对已经跑在 Sequelize 或自建 migration 体系上的项目来说，这不是“装个新工具”那么简单，它会牵涉数据库演进方式、代码生成流程和团队习惯一起变化。

归档页看起来只是一个简单时间轴，但真把接口写出来就会发现，它和普通列表完全不是一回事。页面需要的是按年、按月、按数量聚合后的结构，而数据库天然存的是一篇篇文章明细。

如果说模型、关联、分页都是准备动作，那么真正让人感受到 ORM 价值的，还是内容列表。博客首页、分类页、归档页、后台管理页，本质上都在围绕“把文章列表稳定地拉出来”这件事打转。

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

很多内容系统都会遇到发布动作失败重试的问题，比如文章入库成功了，但缓存没刷、索引没建，用户看到的状态就不完整。这时候最直觉的做法是“再点一次发布”，但如果底层没有幂等设计，重试本身会把问题放大。

Sequelize 开事务并不难，难的是控制事务作用域。很多项目一开始只是局部写入，后来为了复用逻辑，把 transaction 对象一层层往下传，结果一个简单发布动作能串起好几个服务函数，谁都可能在事务里顺手写点东西。

很多人提到事务，第一反应都是订单、库存、支付。但内容系统也会遇到并发问题，只是它通常没那么刺眼，等线上数据变脏了才会意识到早该补。

后台列表的分页性能，前期常常给人一种“问题不大”的错觉。因为数据量小时，任何写法都像能跑。一旦线上数据变多，再叠加排序、过滤和关联，分页接口很快就会成为慢查询集中地。

刚接触 Sequelize 时，很多人喜欢用一条查询同时把总数和明细都拿回来，觉得这样“更省请求”。但在复杂列表里，我越来越倾向把 count 和 rows 拆开，因为它们的目标根本不是一回事。