为何ABP框架不推荐在应用开发中使用Lazy Loading（延迟加载）？

在应用开发中避免依赖延迟加载，主要是因为它会带来一系列难以排查的问题，具体可以从这几个方面看：

• N+1查询导致性能雪崩
  这是延迟加载最常见的坑：假设你查询了100条订单数据，然后循环遍历每个订单去访问关联的客户信息——这时候EF Core会为每个订单单独发一条SQL查询客户，加上最初的订单查询，总共会产生101条SQL请求。数据量越大，这种额外的查询开销就越夸张，直接拖垮数据库和应用性能。

• 运行时行为不可控
  延迟加载依赖于EF Core上下文（DbContext）的存活状态，如果上下文已经被释放（比如API请求结束后上下文被回收），这时候再访问实体的关联属性，就会直接抛出ObjectDisposedException。而且你很难预判什么时候会触发查询——比如在前端序列化返回结果时，序列化器自动遍历属性会意外触发延迟加载，这种问题调试起来特别头疼。

• 内存与资源浪费
  延迟加载会让实体一直持有上下文的引用，容易导致内存泄漏，尤其是在长时间运行的后台服务中。另外，频繁的小查询会消耗更多的数据库连接和TCP资源，累积起来的开销比一次性批量查询大得多。

• 业务逻辑模糊难维护
  依赖延迟加载时，数据依赖关系会分散在代码的各个地方：比如某个业务方法里突然用到了订单的关联商品，但数据层并没有预先加载这个关联，后续开发者修改代码时很容易忽略这个隐式依赖，导致线上出现性能问题或者逻辑错误。

• 序列化容易出问题
  大多数JSON序列化器（比如Newtonsoft.Json、System.Text.Json）会自动遍历实体的所有公开属性，这会意外触发延迟加载，不仅产生额外SQL，还可能因为循环引用（比如订单和客户互相引用对方的导航属性）导致序列化失败，直接返回错误给前端。

总的来说，显式使用Include/ThenInclude或者投影查询（Select）来预加载需要的数据，能让数据查询逻辑更清晰、性能更可控，也更容易维护。

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