1. 属性依赖注入的甜蜜陷阱我刚从传统.NET Framework迁移到.NET Core时被属性注入Property Injection的简洁语法深深吸引。相比构造函数注入的冗长直接在属性上标记[FromServices]或[Inject]看起来多么优雅直到线上系统在深夜爆发连环空引用异常我才真正理解为什么社区会说属性注入是.NET Core中最危险的糖衣炮弹。属性依赖注入允许我们这样编写服务类public class OrderService { [Inject] public ILoggerOrderService Logger { get; set; } public void ProcessOrder(Order order) { Logger.LogInformation(Processing order {OrderId}, order.Id); // 业务逻辑 } }表面上看这比构造函数注入省去了大量样板代码。但魔鬼藏在细节里——当OrderService被直接实例化例如通过new操作符或某些序列化场景时Logger属性将保持null值。更可怕的是这种情况在单元测试中可能完全正常因为测试框架通常会处理依赖解析但生产环境却会突然崩溃。2. 构造函数注入的编译期保障对比以下构造函数注入的实现public class OrderService { private readonly ILoggerOrderService _logger; public OrderService(ILoggerOrderService logger) { _logger logger ?? throw new ArgumentNullException(nameof(logger)); } public void ProcessOrder(Order order) { _logger.LogInformation(Processing order {OrderId}, order.Id); // 业务逻辑 } }这种模式具有三个关键优势不可变字段readonly确保依赖项在对象生命周期内不会意外变更构造函数参数强制在创建实例时必须提供所有依赖显式的null检查可以在开发早期暴露配置错误重要提示在.NET Core 3.1中对于未注册服务尝试解析时默认会抛出异常。但在早期版本中某些容器可能静默返回null3. 真实事故现场还原去年我们电商系统就遭遇过典型事故。某个后台作业使用了如下服务public class InventoryUpdater { [FromServices] public IStockRepository StockRepo { get; set; } public void BatchUpdate(IEnumerableInventory items) { foreach (var item in items) { StockRepo.AdjustStock(item.Sku, item.Quantity); // 可能NRE } } }问题出现在后台作业系统直接new InventoryUpdater()实例由于没有走DI容器StockRepo始终为null在开发环境测试时因为调用了AddScoped配置测试全部通过上线后首次批量操作时直接引发NullReferenceException4. 安全使用属性注入的准则如果确实需要使用属性注入比如处理第三方库的限制请遵循以下防护措施public class SafeInventoryUpdater { private IStockRepository _stockRepo; [Inject] public IStockRepository StockRepo { get _stockRepo ?? throw new InvalidOperationException( 依赖项未初始化请确保通过DI容器解析此类); set _stockRepo value; } public void BatchUpdate(IEnumerableInventory items) { // 现在会在访问属性时立即失败而不是深层调用时 foreach (var item in items) { StockRepo.AdjustStock(item.Sku, item.Quantity); } } }配套的单元测试应该包含[Fact] public void Should_throw_when_not_resolved_via_container() { var updater new SafeInventoryUpdater(); Assert.ThrowsInvalidOperationException(() updater.BatchUpdate(TestData)); }5. .NET Core 10.0中的新动向随着.NET 10.0和MAUI的演进Prism库对属性注入的支持有了改进方案。现在推荐使用[BindableProperty]模式public partial class OrderViewModel : BindableBase { [BindableProperty] public IOrderService OrderService { get; set; } [BindableProperty] public INavigationService Navigation { get; set; } }这种方式的优势在于与MAUI的XAML绑定系统深度集成在编译时生成保障代码提供更清晰的依赖关系可视化6. 依赖注入最佳实践清单根据多年踩坑经验我总结出以下黄金法则默认使用构造函数注入适用于95%的场景属性注入仅用于可选依赖比如日志器这种非核心组件框架集成点例外MVC的[FromServices]、Prism的[BindableProperty]等添加防御性编程getter中进行null检查编写显式测试验证非DI路径下的行为对于新项目建议在.editorconfig中添加# 不鼓励使用属性注入 dotnet_diagnostic.DI0001.severity warning配合Roslyn分析器可以在编码阶段发现问题。记住依赖注入的核心价值是明确声明组件的关系契约而构造函数是最有力的契约表达方式。