面向 TypeScript 数据层的最佳 ORM
本指南没有单一首选
要回答的不是谁更快——四家都没有发布可供我们复现的延迟数据——而是 schema 归谁。写在 DSL 里、让工具链 plan 出迁移：选 Prisma，但它的合规面挂在付费档而不是免费档。写在 TypeScript 里、保持 SQL 可见，让 CLI 推送或生成迁移：选 Drizzle。只把查询层做成类型安全，schema 变更自己写：选 Kysely。保留装饰器实体类、按项目选 DataMapper 或 ActiveRecord：选 TypeORM。四家里只有一家卖托管平台，库本身没有厂商账单；也只有这一家能给你审计报告。
审计：2026-11-01阅读：约十分钟
- 预估月费
- $0 – $129 / 月。四家里三家是库形态、没有厂商价格；这套组合里唯一有公开厂商账单的是 Prisma 的托管平台，其 ORM 在定价页上写明全档免费。
- 目标团队
- 用 TypeScript 对着关系型数据库写业务的产品团队，且至少有一名工程师负责 schema 变更与迁移评审。
- 最高维护工时
- 契约式与装饰器式 ORM 会接管 schema diff 并生成迁移；查询构建器这条路把 schema 变更、执行顺序与回滚都留给你。
- 冷启动开销
- 第一条类型化查询与第一次迁移，四家都是半天内能跑通。差异出现在第二次 schema 变更——那时评审与回滚才成为问题。
Prisma
契约优先、迁移由工具生成的客户端为何胜出
数据契约在一个 DSL 里写一次，工具链就产出类型化产物与一份可评审的迁移计划，前后各有一道校验，于是 schema 变更变成待批准的 diff，而不是手写 SQL。
核心优势: 安全页写明哪个档位带哪项控制，受监管的业务可以据此对齐档位，而不必假设「用了这个库就等于有了认证」。
关键局限: 这些控制是档位门控的：审计控制与业务伙伴协议都挂在付费的 Business 档，免费档项目一项也继承不到。厂商同时写明目前还没有 squash 命令、也没有 shadow database 演练。
Drizzle ORM
SQL 形状的 TypeScript 库加迁移 CLI为何胜出
schema 就是纯 TypeScript，查询面贴着 SQL，已经会 SQL 的团队不必再学一套方言；迁移 CLI 也能顺着项目既有的方向走。
核心优势: 迁移策略是选择题而不是教条：CLI 可以推送 schema、生成 SQL 迁移文件，或者把既有数据库的 schema 反向拉回 TypeScript。
关键局限: 它是库而不是平台：没有厂商控制台，没有托管合规面，也没有可以继承的审计证据——这些全部由团队自己提供。
Kysely
不带 schema 生成器的类型化 SQL 构建器为何胜出
类型系统只覆盖当前这段查询可见的表与列，schema 漂移在编译期就暴露，中间不需要 DSL、代码生成器或额外的构建步骤。
核心优势: 迁移就是你自己持有的 up / down 函数，按文档写明的顺序执行，并为「并行分支落库顺序错乱」的团队留了一个显式开关。
关键局限: 它停在查询层：没有实体映射、没有 schema diff、不生成迁移文件，schema 与它的执行顺序都要手写并人工评审。
TypeORM
保留两种映射风格的装饰器 ORM为何胜出
实体是装饰器类，同一个项目可以走 DataMapper 也可以走 ActiveRecord，把既有代码库迁过来的团队能保留原有结构，而不必改写成另一种范式。
核心优势: 数据库覆盖广——多种关系型引擎外加 MongoDB——迁移可以从实体变更生成，而不必从零手写。
关键局限: 装饰器元数据把实体绑到运行时与编译配置上，可移植性弱于「schema 就是纯 TypeScript」的写法；项目也没有发布安全或合规页面。