依赖注入如何处理带默认值的可构造构造函数参数

绝大多数主流DI容器（包括.NET内置DI、Autofac、Spring等）对这类参数的处理逻辑完全一致，规则非常明确：

• 解析构造参数的优先级固定为：容器内已注册、可正常解析的服务实例 > 参数声明的默认值。只要容器能正常构造、获取到Baz类型的匹配实例，就会自动完成注入，根本不会触发你写的= default默认值逻辑。
• 只有当容器遍历完所有注册源，都找不到对应类型的可用实例、也没有额外配置参数传入规则时，才会回退使用参数上定义的默认值，不会直接抛出依赖解析失败的异常。

这个写法完全可以兼容你当前需要适配旧单元测试的需求：

1. 生产环境运行时，容器能正常解析到注册的Baz实例，会按预期完成依赖注入，业务逻辑没有任何副作用
2. 旧单元测试不需要做任何修改，原有手动编写的new Foo(barMock)代码可以正常运行——这时候没有DI容器介入解析Baz参数，构造函数会自动使用你设置的default默认值（引用类型默认是null），不会出现参数不匹配的编译或运行错误。

补充一个容易踩的注意点：

• 不要给注入参数写硬编码的默认实例（比如= new Baz()），否则当容器解析失败回退到默认值时，会直接耦合Baz的具体实现，破坏依赖注入的解耦设计，用default作为默认值就足够适配测试场景了。

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