Sequelize 时间戳与软删除的使用边界

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

我自己的经验是，时间戳应该默认开，软删除则必须按业务判断。像内容系统这类需要审计和误删恢复的场景，deletedAt 很有价值；但如果是一张高频写入、只保留最新状态的中间表，软删除反而会让查询条件越来越重。

真正要注意的点主要有三个：

• 软删除模型上的唯一索引，是否会被“已删但仍占位”的旧数据卡住。
• 列表接口里是否统一过滤 deletedAt，避免后台和前台结果不一致。
• 恢复功能是否真有业务意义，而不是留着一个没人敢点的入口。

所以我更倾向把时间戳当成默认基础设施，把软删除当成明确设计决策。这样不会把简单能力用成长期负担。

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

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

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

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