Prisma ，用起来很自然，心智负担很小。 事务直接放数组里面： const [posts, totalPosts] = await prisma.$transaction([ prisma.post.findMany({ where: { title: { contains: 'prisma' } } }), prisma.post.count(), ])

夸 Laravel 还行，但是夸 Prisma 的真是没预料到，这辈子都不想再用： 根本不能算模型定义的模型 migration 根本没法用 简单的保存是有了 id 还用要 id 执行一遍查询，然后再更新，然后在获取更新后的结果

Spring Boot + Mybatis Plus

我给 TypeScript ORM 排个名： Drizzle > Kysely > Orchid ORM >> MikroORM > Prisma > TypeORM Drizzle 、Kysely 已经是版本答案了：没有太花哨的功能，只需要写 SQL ，ORM | SQL Builder 将给你类型安全的查询结果。 Kysely 只是一个 SQL Builder ，类型安全方面做得也是最好的； Drizzle 在 SQL Builder 的基础上加了表结构定义，能满足表迁移的许多工作，因此把 Drizzle 排在 Kysely 前面。 Orchid ORM 非常小众，除了 SQL Builder 和表结构定义还加了许多 EntityManager | Repository 的糖，但主要还是以 SQL Builder 为主。 再之后就是传统的围绕 Entity 的 ORM 。这一类 ORM 都内置了丰富的 EntityManager | Repository 的功能，SQL Builder 功能只是作为兜底方案。这类 ORM 的通病是 Repository API 无法满足所有的 SQL 写法，到头来还是得写 SQL 。 这其中功能做的最全的是 MikroORM ，隐式事务、实体事件监听、过滤器、Migrations 、Seeding ，也内置了 Knex 作为 SQL Builder 。 Prisma 的主要槽点是：使用自己发明的 Prisma Schema 用于定义表结构、使用自己发明的 Repository API 用于读写数据库，后果是增加了学习成本，隐藏了许多细节碰到问题了不太容易排查； TypeORM 毫无疑问垫底，连最基础的空安全和类型安全都不好。隔壁 MikroORM 6.5 已经在用 `defineEntity` 尝试摆脱了对 Decorators 的依赖。TypeORM 前两年都没怎么维护，今年有了新的团队接手才开始处理积攒了几年的 issue 。

很多人根本没真正用过 Rails ，这已经是一种技术上的遗憾。你们天天吹前后端分离、Microservices ，殊不知那不过是自嗨，搞得整个项目复杂化、性能折腾、调试痛苦，用户体验倒退, 成天看着菊花转啊转。Rails 告诉你：什么是高效、简洁和稳健。 Rails 的开发效率是任何 JS 、C#、Java 、Python 框架都望尘莫及的。一个标准的 CRUD 网站，加上各种 Gems, 几小时就能上线一个带 RBAC 带后台的管理系统，ActiveRecord ORM 简直是魔法，数据库操作简单得让你怀疑人生。而你们那些前后端分离、手动调接口的项目，动不动就死在同步和状态管理上。 现在有了 AI ，99% 的网站根本不需要前后端分离。以前是前端的开发者可以自己定制后端, 以前是后端的开发者, 可以让 AI 帮你写前端。如果用 Hotwire 就可以告别 React 、Vue 的冗余和复杂性，如果用 Hotwire Native 适配一下，就可以用极少的代价上线 iOS + Android. 真正做过 Rails 的人，从来不想回到 JS/Java/C# 的折磨里。Rails 不只是开发工具，它是高效网站开发的标准，其他框架，只能是“绕路”的选择.