194 篇博文 含有标签「后端开发」

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

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

很多项目里，列表筛选之所以越做越乱，不是 Sequelize 本身的问题，而是接口层直接暴露了 ORM 的思路。前端传什么字段、后端就原样拼进查询对象，结果筛选协议和数据库实现被彻底绑在一起。

真正让 ORM 见真章的，不是建模，而是列表查询。博客系统看起来简单，但一旦有分类、标签、发布时间、状态和关键词搜索，分页接口很容易被写成一锅粥。

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

Sequelize 的 include 第一次用起来很爽，因为它帮你把关联数据一次带回来了。可一旦团队形成习惯，列表、详情、后台搜索全都开始层层 include，接口就会慢慢变成一坨难调试的 SQL。

ORM 最容易让人上头的地方，是看起来什么关系都能一句话配完；但真正落到博客系统里，关联一旦建得太随意，列表接口的查询成本会立刻暴露出来。

刚开始把博客系统往关系型数据库上迁的时候，我最先补的一块不是查询，而是模型设计。因为模型边界一旦定错，后面的列表、详情、标签、归档都会变得越来越绕。

Sequelize 默认帮我们带上时间戳，这一点很省事。但很多项目用着用着就会发现，时间戳和软删除并不是“打开就完事”的便利功能，它们会直接影响列表查询、唯一索引和后台恢复逻辑。

• 文章目录