先从困扰我很久的一个问题说起：实体类到底能不能做依赖注入。做了几年 .NET，很多人背 EF Core 的 CRUD 背得滚瓜烂熟，但一遇到"实体里要写业务方法，要拿当前用户、要拿时间、要触发领域事件"，马上就卡住了。有人把服务直接塞进无参构造函数里跑，结果项目一启动就报 "The entity type ... has a constructor with parameters that do not match any property"；有人干脆定义一个静态的 ServiceLocator，满代码库单例飞来飞去；还有人在 EF 查询实体之后发现注入进来的服务全是 null，百思不得其解。
这篇文章就把"EF Core 实体类的依赖注入"这件事彻底讲透。我会从 EF Core 物化实体的底层逻辑入手，讲清楚为什么常规注入方式会失败，再给出 ILazyLoader、双轨构造、AsyncLocal 环境服务定位器、领域事件这四种实际可用的方案，最后附上我的选型原则和真实踩坑记录。不管是刚入门的初学者，还是正在做领域模型的老手，看完至少能少走三个月的弯路。
1. 先弄明白：EF Core 到底是怎么"造"出实体来的
很多人把依赖注入失败的原因归结为"EF Core 版本太低"或者"构造函数写法不对"，其实真正的根源在于：EF Core 在从数据库查询数据时，根本就不是走你的服务容器来创建对象的。
1.1 实体工厂是编译好的表达式，不是容器
ASP.NET Core 里我们习惯的依赖注入，是通过ActivatorUtilities或者直接调用容器来解析构造函数参数的。你AddScoped<IClock, SystemClock>()一下，任何类构造时容器都会把IClock塞进去。
但 EF Core 不一样。它在OnModelCreating阶段就会把每个实体类型的"物化表达式"编译并缓存。所谓物化（Materialization），就是从数据库读取到的原始行数据，按照列名把值赋给实体属性、创建实体实例的过程。这个表达式树的构建走的是内部的一组IParameterBinding和InstantiationBinding，跟 Application Service Provider 基本没有关系。
换句话说，你的IClock、ICurrentUser在容器里注册得再勤快，EF Core 在context.Set<Order>().FirstOrDefault()那一刻也完全不理会容器，它只关心一件事：这个实体类型能不能通过它认识的规则被创建出来。
1.2 构造函数绑定：名字对上才算数
那 EF Core 认识什么规则？三件事：
- 实体有公开/受保护的无参构造函数，那就用它，这是最省事的路。
- 没有无参构造函数，EF Core 会去找"参数名能跟实体属性名对应上"的构造函数。注意是参数名对属性名，不是类型对类型。
- 从 EF Core 7 开始，可以用
[EntityConstructor]显式指定让 EF 用哪个构造函数。
举个例子，下面这个没问题：
public class Blog { public Blog(int id, string name) { Id = id; Name = name; } public int Id { get; } public string Name { get; } }EF 查询时会调用new Blog(id, name)，因为id对应Id属性、name对应Name属性，名字对上了。
但如果你手一滑写成这样：
public class Blog { public Blog(IClock clock, int id, string name) { Clock = clock; Id = id; Name = name; } public IClock Clock { get; } // 没有映射到表 public int Id { get; } public string Name { get; } }模型校验阶段 EF 就会直接报错：找不到对应clock这个参数名匹配的属性。因为实体里可能确实有个Clock属性，但 EF 只认映射到表的属性，你一个没有映射的属性它根本无法赋值，于是构造函数绑定失败。
注意：
[EntityConstructor]只解决"多个构造函数之间让 EF 选哪个"的问题，并不能让 EF 从容器里解析任意服务参数。它要求的参数依然必须能和映射属性对上。
1.3 为什么看过很多"注入实体"的帖子还是会翻车
网上很多教程的做法是：在实体里放一个IServiceProvider属性，构造函数里接住它，然后业务方法里_serviceProvider.GetService<IClock>()。看似能用，但一旦走 EF 查询路径，这个IServiceProvider参数无法绑定、又没有无参构造函数兜底，项目直接崩。就算你用受保护的无参构造函数兜底，EF 创建出来的实体里服务引用是 null，业务方法一调就炸。
所以，读任何"实体类依赖注入"的内容，第一件事就是分清两条创建路径：
- 应用代码路径：你
new Order(...)，走的是你自己的构造逻辑，容器能帮上忙。 - EF 物化路径：EF 用缓存的工厂
Create(object[] values)，容器帮不上忙，除非 EF 自己开了后门。
下面这几个方案，本质都是围绕这两条路径在做文章。
2. 官方唯一开过口的构造器注入：ILazyLoader 是怎么做到的
EF Core 官方文档里，确实存在一个"实体构造函数中可以注入的服务"，名字叫ILazyLoader。它是懒加载机制的一部分。
2.1 一段标准的 ILazyLoader 注入代码
要启用这个功能，首先在注册 DbContext 时打开代理：
services.AddDbContext<AppDbContext>(options => options.UseLazyLoadingProxies() .UseSqlServer(connectionString));然后在实体里这样写：
public class Blog { private ICollection<Post> _posts; public Blog() { } public Blog(ILazyLoader lazyLoader) { LazyLoader = lazyLoader; } private ILazyLoader LazyLoader { get; set; } public virtual ICollection<Post> Posts { get => LazyLoader.Load(this, ref _posts); set => _posts = value; } }这样查询Blog时，EF 会生成一个代理类，构造函数里自动把当前 DbContext 关联的ILazyLoader实例塞进来。第一次访问Posts时，LazyLoader.Load(this, ref _posts)才会真正去数据库查导航属性。
2.2 为什么 ILazyLoader 能注入，其他服务不行
关键点在参数绑定工厂。EF Core 内部有一套ParameterBinding机制，它在构建构造函数参数绑定时，会检测参数类型。当参数类型是ILazyLoader时，绕过"参数名必须匹配属性名"的规则，直接创建一个LazyLoaderParameterBinding，把这个绑定的 lazyLoader 实例接到正在被物化的实体上。
你可以理解成：这是 EF Core 为了自己实现懒加载而故意留的后门，不是给你开的后门。ILazyLoader是 EF Core 自己定义、自己注册、自己管理的内部服务，你的自定义服务不在这个白名单里。
2.3 实战中我踩过的坑
第一，代理要求实体类不能是 sealed、导航属性必须是virtual，而且类必须是 public。有一次我把一个实体类改成了internal，结果运行时直接报代理创建失败。
第二，LazyLoader这个属性本身不能序列化。如果你做 Web API，把Blog直接返回给前端，_posts又恰好没被加载，那 JSON 序列化器一碰到这个私有属性就容易出奇怪的问题。稳妥做法是配置 JSON 忽略所有私有成员，或者干脆用 DTO。
第三，也是最大的坑：LazyLoader内部持有了 DbContext。如果你把一个懒加载的实体从仓储层返回，然后在上层长期持有，等于变相把 DbContext 的生命周期拉长到和实体一样长。这是连接池耗尽、内存泄漏的高发区。
注意：懒加载本身在生产环境一直有性能争议。我的建议是，即便需要注入，也只在项目里严格控制导航属性的访问点，不要把懒加载当默认能力敞开用。
3. 双轨构造：应用代码用完整构造器，EF 走保护构造器
明白了上面的底层逻辑，就能设计出第一个"能用"的通用方案：让应用代码创建实体时走完整依赖注入构造器，让 EF 物化时走受保护的无参构造器。这个方案我称之为"双轨构造"。
3.1 具体代码长什么样
假设我们有一个Order，业务方法MarkPaid()需要IClock来记录付款时间：
public class Order { private readonly IClock _clock; // 应用代码创建新订单时走这个构造器 public Order(IClock clock, string orderNo) { _clock = clock; OrderNo = orderNo; } // EF 物化时走这个构造器 protected Order() { } public int Id { get; private set; } public string OrderNo { get; private set; } public DateTime? PaidAt { get; private set; } public void MarkPaid() { if (_clock == null) { throw new InvalidOperationException("当前订单实例未注入 IClock，可能是从数据库加载的实例。"); } PaidAt = _clock.Now; } }在应用层创建订单时，直接用注入进来的IClock构造：
public class OrderService { private readonly IClock _clock; private readonly AppDbContext _db; public OrderService(IClock clock, AppDbContext db) { _clock = clock; _db = db; } public async Task CreateOrderAsync(string orderNo) { var order = new Order(_clock, orderNo); _db.Add(order); await _db.SaveChangesAsync(); } }这样"新建"这个场景下，实体内部确实用上了注入的服务，逻辑也都在实体里。EF 查询时走保护构造器，不报错。
3.2 加载后要拿服务怎么办：把 DbContext 当 Service Locator
但这套方案有个致命缺口：从数据库加载出来的Order，_clock是 null。你总不能每次都抛异常。更实际的做法是：把 DbContext 本身当成服务定位器，在调用实体方法时，把需要的服务作为参数传进去。
public abstract class EntityServiceLocator { protected static TService GetService<TService>(DbContext context) { // Microsoft.EntityFrameworkCore.Infrastructure 命名空间下的扩展方法 return context.GetService<TService>(); } }然后在实体方法里这样调用：
public void MarkPaid(DbContext db) { var clock = db.GetService<IClock>(); PaidAt = clock.Now; }这里用到的db.GetService<T>()是DbContext通过IInfrastructure<IServiceProvider>暴露出来的内部服务提供者扩展。它会从整个应用的IServiceProvider里解析服务，IClock只要在容器里注册过，就能拿到。
但我要提醒一句：我不建议在实体里直接依赖DbContext类型。这会让实体和方法层的耦合变得特别隐晦，测试时你得先建一个真 DbContext，而且每次调用都要传一个上下文参数，实体方法越写越像"半个仓储"。它只适合作为过渡方案。
3.3 双轨构造的边界条件
双轨构造能解决"创建时有服务可用"，不能解决"所有方法随时有服务可用"。想让实体在加载后也能自动拿到服务，必须引入环境上下文，也就是下一节的 AsyncLocal 方案。另外还要注意：protected Order()这种受保护构造器，不要给它加业务逻辑，它只是给 EF 的表达式工厂一个安全的入口。
注意：千万不要在这个受保护构造器里初始化集合属性以外的任何东西。EF 物化时会先调用构造函数再给属性赋值，你在构造函数里对属性做的预设值可能被覆盖，也可能因为代理机制产生意想不到的双重赋值。
4. AsyncLocal 环境服务定位器：让实体在运行时"自取"依赖
如果项目里已经有一堆实体方法需要ICurrentUser、ILogger这类服务，逐个传参改造不现实，双轨构造又不能覆盖"加载后的方法调用"，那可以考虑环境服务定位器方案——用AsyncLocal<T>在当前异步上下文里保存一个 scoped 的IServiceProvider，实体在需要时自行取出。
4.1 适用场景
这个方案最适合两类场景：一是老项目里已经有几十个实体方法散落着对全局服务的依赖，代码评审过不了、又没法快速重构；二是某些基础设施代码（比如审计拦截器、软删除过滤器）里实在没有干净的地方传入服务。它是"局部麻醉"，不是长期健康方案。
4.2 完整实现：作用域中间件 + 实体辅助方法
首先定义一个静态类，持有当前异步上下文里的服务作用域：
public static class AmbientScope { private static readonly AsyncLocal<IServiceScope> _current = new(); public static IServiceProvider? CurrentProvider => _current.Value?.ServiceProvider; public static void Set(IServiceScope scope) => _current.Value = scope; public static void Clear() => _current.Value = null; }然后写一个 ASP.NET Core 中间件，在每个请求里创建一个IServiceScope放入AmbientScope：
public class AmbientScopeMiddleware { private readonly RequestDelegate _next; private readonly IServiceScopeFactory _scopeFactory; public AmbientScopeMiddleware(RequestDelegate next, IServiceScopeFactory scopeFactory) { _next = next; _scopeFactory = scopeFactory; } public async Task InvokeAsync(HttpContext context) { using var scope = _scopeFactory.CreateScope(); AmbientScope.Set(scope); try { await _next(context); } finally { AmbientScope.Clear(); } } }注册中间件时注意顺序：它必须在用到AmbientScope的业务代码之前执行，但又不能包在异常处理中间件外面导致作用域被提前释放。
实体里就可以写一个辅助方法：
public static class EntityServiceExtensions { public static TService? Resolve<TService>(this object entity) where TService : class { return AmbientScope.CurrentProvider?.GetService<TService>(); } }于是实体方法变成了：
public void MarkPaid() { var clock = this.Resolve<IClock>(); if (clock == null) { throw new InvalidOperationException("当前请求作用域中未注册 IClock 或不在请求上下文中。"); } PaidAt = clock.Now; }单元测试里也可以这样手动设置作用域：
using var scope = serviceProvider.CreateScope(); AmbientScope.Set(scope); order.MarkPaid(); AmbientScope.Clear();4.3 必须接受的代价
这个方案本质上是"用全局黑话换代码简洁"。代价有三点：
第一，AsyncLocal<T>会沿异步调用链流动，但它在并行任务之间是隔离的。如果你用Task.WhenAll同时跑多个不同请求的任务，流入子任务的作用域可能不是你期望的那个。
第二，作用域生命周期一旦管理不当，很容易在请求结束后还访问已释放的IServiceProvider，抛ObjectDisposedException。上面中间件里using var scope的释放时机是请求结束前，如果你在后台Task.Run里调用实体方法，作用域已经没了，服务也解析不出来。
第三，也是最关键的：实体开始隐式依赖"无处不在的服务环境"，你很难一眼看出某个方法到底依赖了哪些服务。代码阅读成本、自动化测试成本都会上升。
所以我的立场很明确：AsyncLocal方案是"能用但不要扩散"的方案，它适合放在基础设施层，不适合成为团队默认模式。
5. 我认为的最优解：领域事件 + 零注入实体
如果你愿意跳出"实体类必须有注入"这个思维定式，其实存在一个更符合 DDD 的做法：实体不需要依赖任何服务，它只负责状态变更和记录领域事件，服务由应用层在合适的时机（通常是SaveChanges前后）通过容器解析并分发。
5.1 领域事件怎么让实体摆脱容器
看一个对比。传统写法里，实体方法内部拿IClock：
public void MarkPaid() { PaidAt = _clock.Now; }有了 AsyncLocal 之后，变成：
public void MarkPaid() { PaidAt = this.Resolve<IClock>().Now; }而领域事件方案里，实体不拿任何服务，只记录"发生了什么事"：
public class Order { private readonly List<IDomainEvent> _domainEvents = new(); public int Id { get; private set; } public DateTime? PaidAt { get; private set; } public IReadOnlyCollection<IDomainEvent> DomainEvents => _domainEvents; public void MarkPaid(DateTime paidAt) { if (PaidAt.HasValue) { throw new InvalidOperationException("订单已付款。"); } PaidAt = paidAt; _domainEvents.Add(new OrderMarkedAsPaid(Id, paidAt)); } }实体的MarkPaid只做两件事：校验状态、修改面向状态字段、记录领域事件。它不询问时间、不查当前用户、不依赖任何容器。创建和加载两条路径完全不需要区分，EF 物化用无参构造函数自然没问题。
5.2 分发环节放在哪最安全
领域事件只记录还不够，必须在某个地方把事件交给处理程序去执行真正的副作用（发邮件、更新库存、写入审计日志）。这个分发动作必须由应用层做，而且我在实战里强烈建议放在SaveChanges之后：
public class OrderService { private readonly AppDbContext _db; private readonly IMediator _mediator; public OrderService(AppDbContext db, IMediator mediator) { _db = db; _mediator = mediator; } public async Task MarkOrderPaidAsync(int orderId) { var order = await _db.Orders.FindAsync(orderId); if (order == null) { throw new InvalidOperationException("订单不存在。"); } order.MarkPaid(DateTime.UtcNow); await _db.SaveChangesAsync(); foreach (var domainEvent in order.DomainEvents) { await _mediator.Publish(domainEvent); } } }为什么要放SaveChanges之后？因为如果事件处理程序里又去查数据库，它查到的一定是已经持久化的最新状态，不会出现"事务还没提交就消费事件"的脏读问题。另外事件处理程序里如果抛了异常，数据库事务已经提交，不会连带把业务数据回滚，这个语义更清晰。
5.3 这样写之后的收益
实体彻底变成"纯领域对象"，不需要知道 DI 容器存在，不需要挂ILazyLoader，不需要依赖 DbContext。EF Core 的物化路径最舒服，因为它永远走无参构造函数；应用层的容器也舒服，因为所有服务依赖都集中在应用层服务类里；测试更是舒服，new Order()之后直接调用MarkPaid(fixedTime)就完事，连容器都不需要。
唯一的代价是实体方法里不能直接"顺手"调服务，必须通过事件去驱动副作用。但这个代价换来的可测试性和清晰度，在业务复杂度上来之后是绝对值得的。
6. 方案对比、实战避坑与面试回答思路
最后把几种方案放在一起横向比较，再聊几个我真实遇到的坑。这篇文章不是让你抱着某一种方案用到死，而是希望你能在项目场景里迅速选出代价最小的那条路。
6.1 五条路线横向对比
| 方案 | 依赖注入程度 | EF 物化兼容度 | 单元测试难度 | 主要风险 |
|---|---|---|---|---|
| ILazyLoader 注入 | 仅限懒加载导航 | 官方支持 | 中等 | 持有 DbContext、代理序列化问题 |
| 双轨构造 | 创建路径可用 | 高 | 中等 | 加载后的服务为 null |
| DbContext 当 Service Locator | 手动传参 | 高 | 较低 | 实体依赖 DbContext，耦合变高 |
| AsyncLocal 环境定位器 | 实体内自取 | 高 | 中等 | 生命周期、作用域泄漏、隐式依赖 |
| 领域事件 + 零注入 | 无 | 极高 | 低 | 事件分发时序需要设计 |
面试或者设计评审时，我通常按这个顺序推荐：默认走领域事件零注入，基础设施层少量用 AsyncLocal，创建实体时允许双轨构造，ILazyLoader只在确实需要懒加载的场景用，DbContext.GetService<T>()作为救急手段而不是常规路径。
6.2 三个我真实踩过的坑
第一个坑是静态 ServiceLocator 污染测试。当时项目里有人图快，直接在实体里写ServiceLocator.Instance.GetService<IClock>()，ServiceLocator.Instance是启动时赋值的全局单例。结果单元测试之间互相污染，一个测试改了 ServiceLocator 里的注册，另一个测试就跟着炸。后来我们统一把实体里所有服务依赖全部改成参数传递，这个问题才消停。
第二个坑是 scoped 服务被长时间持有。一个审计实体把ICurrentUser存成私有字段，实体从请求作用域里 new 出来，又被放进了内存缓存。结果请求结束后，ICurrentUser背后的 scoped 对象没有被释放，缓存里的实体一直握着它。内存占用一路飙升，最后用IDbContextFactory重新建上下文都没修好，只能清缓存。从那以后，我定了一条规矩：实体里永远不要保存 scoped 服务引用，需要用时临时解析。
第三个坑是 JSON 序列化循环引用。有个实体加了IServiceProvider属性后直接返回给前端，序列化器试图递归序列化整个服务提供者对象图，当场爆栈。后来我们用 DTO 才解决。实体如果要暴露给前端，强烈建议一律转 DTO。
6.3 被问到"EF Core 实体类怎么做依赖注入"时怎么答
面试题里经常会问 EF Core 相关的话题，实体类依赖注入这个问题，其实高频出现。我的回答思路一般是这样：
先说明 EF Core 物化实体不走 DI 容器的底层机制，再讲ILazyLoader是官方唯一支持的服务注入特例，然后谈双轨构造和 AsyncLocal 方案的取舍，最后落到领域事件是最推荐的解耦方案。只要这几条线讲清楚，对方就能判断你是真的理解 EF Core 的工作机制，而不是只会背几个 API。
我也经常反问他一句："你是想在实体里注入服务，还是想让实体不依赖服务但又能完成业务？" 这两个问题看似相似，实际上答案完全不同。后者才是成熟团队应该追的方向——实体保持纯净，依赖留在应用层，事件成为连接的桥梁。这不光是 EF Core 的问题，也是整个领域建模的核心命题。
