Sequelize 模型字段约定别等线上再补

很多团队第一次上 Sequelize，最容易忽略的不是关联关系，而是字段约定。字段长度、是否允许为空、默认值和枚举范围如果一开始不说清楚，后面接口一多，数据库就会慢慢长成“谁都不敢动”的样子。

我现在更习惯先把字段分成三类：业务主键、业务可见字段、系统维护字段。主键和外键保证稳定，可见字段强调语义清晰，系统字段则统一命名和默认值。这样做的好处是接口、后台表单和数据库结构能对得上，不会今天叫 publishedAt，明天又冒出一个 publish_time。

对内容系统来说，几个字段最好尽早固定下来：

• title、slug、status、publishedAt 这种直接影响页面展示和路由的字段要优先统一。
• 长文本字段要明确是不是允许为空，避免前端拿到 null、空串、未定义三种状态。
• 布尔型配置别偷懒用整型代替，否则代码里判断会越来越乱。

真正有价值的约定，不是“看起来整齐”，而是让 migration、校验和接口契约有共同基础。字段约定一旦定住，后面的查询、列表和后台编辑体验都会稳很多。

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

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

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

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