TypeORM中能否生成基于实体的QueryRunner式迁移替代原生SQL？

核心结论：TypeORM 默认的迁移生成流程不会默认输出你期望的QueryRunner对象式API写法，但完全可以通过自定义配置实现目标效果，无需手写原生SQL拼接的迁移代码。

默认运行逻辑 #

默认执行typeorm migration:generate命令时，TypeORM会自动对比当前实体定义与目标数据库的实际Schema差异，直接将差异转换为可执行的原生SQL字符串，最终生成的迁移代码会把这些SQL字符串传入queryRunner.query()方法执行，也就是你不想要的硬拼接SQL写法。
但需要明确：TypeORM 的 QueryRunner 本身是完整支持对象式Schema操作API的，包括createTable、addColumn、dropTable、createIndex等方法，调用这些方法时只需传入Table、TableColumn、TableIndex等结构化配置对象即可，最终框架会自动根据连接的数据库方言转换为对应SQL执行，和直接写SQL的执行效果完全一致。

实现对象式迁移生成的落地方式 #

• 在项目的TypeORM数据源配置中，替换掉框架默认的迁移生成器，重写Schema差异的代码生成逻辑：把原本“将Schema差异转成原生SQL字符串”的流程，改为“将Schema差异映射为对应的QueryRunner对象式方法调用代码片段”。
• 生成规则可直接复用TypeORM内部存储的实体Schema元数据：
  • 检测到新建表的差异时，输出await queryRunner.createTable(new Table({...}))结构的代码，把实体对应的表名、列定义、主键、自增规则、默认值等参数一一填充到Table配置对象中
  • 检测到表结构变更（新增列、修改列类型、删除索引等）时，分别对应生成queryRunner.addColumn()、queryRunner.changeColumn()、queryRunner.dropIndex()的调用代码，完全替代原生SQL的拼接逻辑
• 自定义生成时需要对齐列定义的所有参数：包括字段类型、长度、是否可空、默认值、是否主键、是否自增等属性，确保生成的对象式配置最终执行的Schema变更，和原生SQL版本完全一致，不会出现执行偏差。

最终效果 #

自定义生成逻辑落地后，最终生成的迁移文件结构就会和你给出的示例完全一致，所有数据库操作都通过结构化的对象式API调用实现，不会出现硬拼接的原生SQL字符串，既保留了迁移和实体定义联动的便利性，也提升了迁移代码的可读性和可维护性。

注意：这种对象式写法只是迁移文件层面的代码形式变化，最终执行时框架依然会根据数据库方言生成对应底层SQL，和默认生成的原生SQL版本在功能、性能上没有任何差异。

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