在ASP.NET Core依赖注入容器中注入Record是否可行？

你提到用Record能大幅简化服务类代码：

原来的普通类写法：

public class OrderService
{
  private readonly EcommerceContext _context;

  public OrderService(EcommerceContext context)
  {
    _context = context;
  }
}

用Record简化后的写法：

public record OrderService(EcommerceContext Context)

针对你的问题，以下是具体解答：

可行性：完全可行 #

ASP.NET Core的依赖注入容器只关注类型是否具备可被解析的构造函数。C# positional record会自动生成包含所有参数的公共构造函数，和你手写的类构造函数逻辑完全一致。DI容器能正常识别这个构造函数，并自动注入对应的EcommerceContext实例，和普通类的注入行为没有任何区别。

潜在弊端 #

• 不可变性的限制：positional record生成的属性默认是只读的。如果你的服务后续需要修改注入的依赖实例（虽然不推荐这种做法，但某些特殊场景可能存在），Record的只读属性会直接导致无法修改。而普通类可以通过私有字段+公共属性的方式灵活调整可变性。
• 复杂初始化需求无法满足：如果服务在构造时需要执行额外逻辑（比如验证依赖参数是否有效、初始化内部状态变量），positional record的自动构造函数无法支持这种场景。虽然可以手动给Record编写构造函数，但这样就失去了Record简化代码的意义，反而不如直接用普通类清晰。
• 语义上的错位：Record的设计初衷是作为不可变的数据载体（比如DTO、值对象），而服务类通常是包含业务行为的逻辑载体。用Record来定义服务类，会违背类型设计的语义约定，可能让团队成员在维护时产生误解，增加沟通成本。
• 序列化的潜在问题：很多ASP.NET Core服务可能会涉及序列化操作（比如作为API响应返回），Record默认生成的Equals、GetHashCode以及序列化行为和普通类略有差异，在某些复杂序列化场景下可能出现意外结果，需要额外适配。
• 生命周期适配冲突：如果你的服务需要使用特殊的DI生命周期（比如自定义生命周期），虽然Record本身不影响生命周期配置，但它的不可变性可能和某些生命周期的预期行为冲突。比如，若服务需要在请求周期内动态更新内部状态，不可变的Record就完全不适用。

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