asp.net core 不支持属性注入，因其绕过构造函数约束、破坏不可变性、易致空引用，且 di 容器默认仅执行构造函数注入；[fromservices] 仅适用于 razor pages 的 pagemodel 或 viewcomponent，对 controller 或普通 service 无效。
属性注入不是推荐方式，它绕过构造函数约束、破坏不可变性、容易引发空引用，且 ASP.NET Core 官方不支持原生属性注入。
为什么 ASP.NET Core 不支持 public IService MyService { get; set; } 自动赋值
框架的 DI 容器默认只做构造函数注入。即使你把属性声明为 public 且有 set 访问器，IServiceProvider 在解析类型时不会扫描并设置这些属性——它根本没这逻辑。有人误以为加个 [FromServices] 就能行，但该特性只在 Razor Pages 的 PageModel 或 ViewComponent 中有效，对普通 Controller 或 Service 类完全无效。
- Controller 中写
public IEmailService EmailService { get; set; }→ 启动不报错，但运行时是null - 手动调用
serviceProvider.Populate(instance)是非标准做法，需额外引入Microsoft.Extensions.DependencyInjection.Abstractions且极易漏掉初始化时机 - Autofac 等第三方容器虽支持属性注入（靠
PropertiesAutowired()），但要求显式启用、严格控制作用域，否则会把本该 Scoped 的服务意外提升为 Singleton
Autofac 中启用属性注入的必要步骤
如果你确实需要属性注入（比如适配遗留代码或特定插件场景），必须用 Autofac 并手动配置，不能依赖默认行为。
- 注册服务时必须链式调用
PropertiesAutowired()：builder.RegisterType<myservice>().As<imyservice>().PropertiesAutowired();</imyservice></myservice> - 被注入的属性必须是
public且有set访问器；private set或init都不行 - 属性类型必须已在容器中注册，且生命周期兼容：例如不能把
Transient服务注入到Singleton实例的属性里，否则造成内存泄漏 - 避免混合使用：一个类同时有构造函数参数和可注入属性时，Autofac 默认优先满足构造函数，属性注入可能被跳过，除非显式设
PreserveExistingDefaults()
比属性注入更安全的替代方案
绝大多数场景下，你应该放弃属性注入，改用明确、可控的方式。
- 构造函数注入：强制依赖显式声明，对象创建即完整，单元测试可直接 new 实例传参
- 工厂模式 +
Func<t></t>延迟解析：适用于需运行时才决定依赖实例的场景，如多租户服务路由 - 通过
IHttpContextAccessor按需获取服务：仅限 Web 上下文内，且要确保服务注册为Scoped，避免跨请求污染 - 方法参数注入（ASP.NET Core 8+）：在 Minimal API 或控制器 Action 中用
[FromServices]标记单个参数，语义清晰、无副作用
真正难处理的不是“怎么让属性被注入”，而是“为什么设计成必须可空、可重置、无法验证”。一旦接受属性注入，你就放弃了编译期检查和构造一致性保障——这点在大型系统演进中会持续反噬。
