Active Record 模式有哪些局限和陷阱？

Active Record 模式让对象同时承载业务数据和数据库访问逻辑（user.save()、User.find(1)），Rails、Django ORM 即典型代表。它简单直观，但随系统复杂度上升暴露出明显局限：

• 领域模型与表结构强耦合：一类一表的假设在复杂领域（聚合、继承、值对象）下不成立，逼你按数据库形状设计对象，而非按业务。
• 业务逻辑散落或臃肿：模型容易变成"上帝对象"，验证、回调、持久化、业务规则全堆在一起，难测试（离不开数据库）。
• N+1 查询陷阱：遍历集合逐个访问关联对象会触发逐条 SQL，是 AR 项目最常见的性能事故，需要 eager loading 之类手段显式规避。
• 跨表事务与聚合边界模糊：一个业务用例涉及多个 AR 对象时，事务一致性缺乏清晰的归属层，容易写出半持久化的中间状态。
• 难以替换持久化方案：持久化细节渗进领域对象，换库、加缓存层、读写分离都牵动全局。
• 隐藏 SQL 导致的认知错觉：开发者以为在操作内存对象，实际每行代码都可能是一次数据库往返。

对应解法是 Data Mapper / Repository 模式（如 SQLAlchemy 的 classical mapping、Java 的 JPA/Hibernate），把领域对象与持久化解耦，代价是更多样板代码。经验法则：CRUD 为主的应用 AR 高效；复杂领域逻辑选 Data Mapper。追问方向：N+1 如何排查与优化、领域驱动设计中的聚合根与仓储。