依赖注入类中使用本地默认值的适用场景解析

针对你给出的RestClient构造函数，我来梳理几个适合为参数设置本地默认值的场景，结合实际使用场景来解释：

• 当依赖是通用稳定的基础实现时
  如果某些依赖（比如ISerializer或IResponseFactory）存在一个广泛适用、无需定制的默认实现，就可以给它们设置本地默认值。比如假设你有一个DefaultJsonSerializer，它能处理绝大多数常规的序列化需求，那你可以把构造函数改成：

  public RestClient(string key, Uri baseAddress, IHttpClient httpClient, ISerializer serializer = new DefaultJsonSerializer(), IResponseFactory responseFactory = new DefaultResponseFactory())
  {
      // 赋值逻辑不变
  }
  

  这样DI容器在注入时，如果没有特意注册对应的实现，就会自动使用这个默认值，减少了不必要的配置成本，同时也保留了用户定制的灵活性。

• 当依赖是可选的，存在降级兼容方案时
  要是某个依赖并不是所有场景都必须定制，比如IResponseFactory，在简单场景下用基础的响应解析逻辑就能满足需求，那给它加默认值就很合适。这样即使DI容器没有注册这个依赖，RestClient依然能正常运行，不会因为缺少依赖抛出异常。当然，这个默认实现得能覆盖基础场景，不能是个无法工作的空实现。

• 为了简化单元测试，减少冗余的依赖Mock
  在写RestClient的单元测试时，如果每次都要Mock所有5个依赖会非常繁琐。给ISerializer、IResponseFactory这类非核心依赖设置默认值后，测试时只需要Mock关键的IHttpClient（用来模拟HTTP请求的返回），其他依赖用默认实现即可，这样测试代码会更简洁，能更专注于验证核心业务逻辑。

• 当类需要同时支持DI注入和手动实例化时
  如果你的RestClient不仅要通过DI容器管理，有时候还需要在代码里直接new出来使用（比如临时脚本、非DI管理的模块），那给部分依赖加默认值就很有必要。比如你可以直接写：

  var client = new RestClient("my-api-key", new Uri("https://api.example.com"), new HttpClient());
  

  不需要手动传递所有5个参数，大大简化了手动实例化的代码。

注意避坑 #

有些参数绝对不适合加本地默认值：

• 像key、baseAddress这种业务专属的配置参数，每个实例的取值都不同，没有通用默认值；
• 像IHttpClient如果是由DI容器（比如HttpClientFactory）管理生命周期的依赖，不能设置本地默认值，否则会绕过DI的生命周期管理，可能导致资源泄漏问题。

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