Sequelize增删改数据库字段应通过Model还是Migrations实现？

核心认知先给准话 #

你之前的认知基本完全正确，两者的职责边界非常清晰，没有重叠：

• Migrations 唯一负责数据库结构的版本化变更：建表删表、增删改列、加/删索引、修改字段约束、设置触发器这类所有修改数据库结构的操作，全部走Migrations实现。
• Model 唯一负责运行期的数据行操作：你写REST API时的业务数据查询、新增行、更新行、删除行这类不涉及表结构变动的操作，全部通过Model完成。

生产环境绝对禁止用sequelize.sync()系列方法做结构同步，这是早期原型开发阶段的便捷工具，没有版本管控，很容易触发全表删除、数据覆盖的高危事故。

Migrations的核心价值 #

很多新手觉得Migrations麻烦，本质是没理解它解决的是多人协作、多环境部署下的结构一致性问题，核心优势有三个：

• 变更全链路可追溯：每个迁移文件带生成时间戳，对应一次明确的结构调整，团队所有人、所有环境都能清晰看到数据库从初始化到当前状态的每一步修改，出问题可以快速回滚到指定版本，不会出现“我本地改了字段忘了同步给同事/线上库”的混乱。
• 跨环境结构一致性：开发、测试、生产环境只要按顺序执行完所有迁移文件，就能保证表结构完全一致，不会出现某台环境缺字段、约束不匹配导致的玄学bug。
• 变更过程可控：和自动同步的黑盒逻辑不同，Migrations里的结构变更逻辑是你自己写的，加新字段时可以顺便补历史数据、调整字段类型时可以提前做数据格式转换，不会被自动生成的SQL弄坏存量数据。

高频问题具体解答 #

增删改列到底用Migrations还是Model？ #

所有表结构层面的列新增、属性修改、删除操作，一律通过新建迁移文件实现，执行迁移命令完成结构变更。
同步修改Model文件里的对应字段定义即可——Model只是ORM层和表结构的映射配置，本身不会触发任何表结构修改，只负责运行期把JS操作翻译成SQL语句。

怎么在Express服务中调用db:migrate命令？ #

正常业务运行流程里，你根本不需要在Express服务的业务代码中调用迁移命令。
迁移的正确执行时机只有两个：

1. 本地开发阶段：写完迁移文件后，手动在终端执行npx sequelize-cli db:migrate，把结构变更应用到本地开发库即可。
2. 部署流程阶段：在CI/CD部署脚本、容器启动脚本里，把执行迁移命令作为服务启动的前置步骤，确认所有迁移执行成功后，再启动Express服务进程。
   如果是做本地开发一键启动工具这类特殊场景，确实需要在代码里触发迁移，可以直接用sequelize-cli底层依赖的迁移工具实现，参考代码：

const { Sequelize } = require('sequelize');
const { Umzug, SequelizeStorage } = require('umzug');

// 初始化已有的sequelize连接实例
const sequelize = new Sequelize(/* 你的数据库连接配置 */);

const migrator = new Umzug({
  migrations: { glob: '项目中migrations目录的路径/*.js' },
  context: sequelize.getQueryInterface(),
  storage: new SequelizeStorage({ sequelize }),
  logger: console,
});

// 执行所有待运行的迁移
await migrator.up();

注意：绝对不要在对外提供服务的接口请求逻辑里触发迁移，否则高并发下多个请求同时执行迁移会触发数据库锁，甚至导致数据损坏。

服务运行期间怎么和数据库交互？ #

流程非常简单：

1. 服务启动前先执行完所有待执行的迁移，保证数据库实际结构和Model定义完全匹配。
2. 接口逻辑里直接调用Model提供的方法做数据操作即可：比如用Model.findAll()做列表查询、Model.create()新增数据、Model.update()更新数据行、Model.destroy()删除数据行，整个运行过程完全不需要涉及Migrations相关逻辑。

内容的提问来源于stack exchange，提问作者Netervey