Sequelize 表名和字段名命名策略

做内容系统时，我越来越确定一件事：表名和字段名的命名策略必须早点定。因为 ORM 能帮你屏蔽一部分 SQL 细节，但它并不能替你修复混乱命名带来的认知成本。

比较常见的冲突有三类：模型是驼峰，表名是复数，字段又混进了下划线和缩写；或者同一个时间字段，在不同表里分别叫 publishTime、published_at、releaseDate。这些问题前期看着小，后期查表、写查询、做迁移时都得重复解释。

我更偏向下面这种规则：

• 模型名按领域对象命名，保持语义清楚。
• 表名统一复数、统一下划线。
• 时间和状态字段尽量复用同一套命名，不做随意变体。

命名策略最大的收益，是让数据库结构和代码表达形成稳定映射。Sequelize 真正适合的是“约定明确后加速开发”，而不是替代基础规范。

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

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

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

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