TypeORM 和 MikroORM 对比：TypeScript ORM 之争
TypeORM 灵活老牌，MikroORM 严谨现代。本文从模型定义、查询、事务、关联、迁移与 TS 集成全面对比两大 TS ORM。
新项目选 MikroORM——DataMapper + Unit of Work 模式更严谨，TS 类型支持与文档质量更好，维护活跃；TypeORM 胜在存量生态与双模式（ActiveRecord/DataMapper）灵活。历史包袱差异决定了这个答案。
基本盘
TypeORM：TS ORM 的先驱与装机量冠军——AR/EM 双模式、数据库覆盖广、生态插件多；但维护质量波动是社区长期槽点。
MikroORM：现代挑战者——Unit of Work 模式、类型推导精确、文档质量标杆，NestJS 官方集成之一。
模型定义
两者都用装饰器实体类，语法神似。差异在行为：MikroORM 的实体默认"纯净"（变更需经 EntityManager）；TypeORM 的 AR 模式让实体自带 save()——方便但模糊了持久化边界。
查询与事务
- TypeORM：QueryBuilder 灵活强大；事务手动管理（queryRunner 或 transaction 回调）；
- MikroORM：em 的脏检查自动生成 UPDATE——只更新变更字段；flush 统一提交，事务边界清晰。
Unit of Work 的价值在复杂业务：多实体操作的一致性由框架保证，而非开发者的纪律。
关联与加载
两者都支持全谱关联。MikroORM 的 populate 语义与 dataloader 集成防 N+1 更系统；TypeORM 的 eager/lazy 加载灵活但 N+1 陷阱更常见。
迁移与 TS 集成
- 迁移：两者都有差异迁移生成；MikroORM 的生成质量口碑更好；
- 类型：MikroORM 的查询结果类型推导（含 populate 关联）精确；TypeORM 的类型在复杂查询下常需手工补强。
决策
| 场景 | 选择 |
|---|---|
| 新项目 | MikroORM |
| 存量 TypeORM 项目 | 继续维护，新模块可试点 MikroORM |
| 需要 MongoDB 混合 | MikroORM（官方支持） |
用实际查询验证数据访问方案
TypeORM 和 MikroORM 对比的选择最终要落到查询次数、SQL 耗时与连接占用。应用接入观测云 APM 时，先核对 SDK 是否支持实际使用的数据库驱动，不能因为使用了某个 ORM 就假设全部查询自动可见。未覆盖的查询可手动插桩；PostgreSQL 等服务端数据库另配实例采集。SQL 和绑定参数上报前须脱敏，再按相同接口比较 N+1 查询与慢查询的变化。
接入文档：Node.js APM 接入 · PostgreSQL 采集 · 日志采集。
常见问题（FAQ）
Q：TypeORM 是"烂尾"了吗？
项目仍在维护（社区驱动），只是节奏与质量把控不如 MikroORM 的核心团队模式。存量代码无迁移急迫性。
Q：和 Prisma 的关系？
Prisma 走 Schema 生成路线（另一哲学）；两者对比见本系列 ORM 相关文章。装饰器实体派的答案在 MikroORM。
Q：MikroORM 的学习成本？
Unit of Work 概念需要理解（em.fork、flush 时机）——NestJS 集成自动化了大部分，独立使用读一遍官方"架构"章节即可。
参考文档
本文依据公开文档整理，示例需按项目依赖版本验证；不将文档中的性能描述视为本项目实测结果。
