ASP.NET Core 2中MVC如何识别控制器构造函数的依赖注入？

你问到的这个点，其实是ASP.NET Core核心的依赖注入（DI）系统和控制器激活机制在协同工作，我给你拆解清楚：

1. 谁在实例化控制器？ #

你说得对，我们从来不会手动new一个控制器实例——这项工作是由框架的控制器激活器（默认是DefaultControllerActivator）完成的。当一个HTTP请求进来，路由系统匹配到对应的控制器后，框架会告诉激活器：“给我创建这个控制器的实例”，剩下的就交给激活器和DI容器了。

2. DI容器怎么识别构造函数签名？ #

ASP.NET Core的DI容器会自动扫描控制器类的所有公共构造函数，然后选择参数最多且所有参数都能被容器解析的那个构造函数来创建实例。

举个你的例子：你在控制器构造函数里加了ILogger<YourController>，ASP.NET Core在启动时已经默认注册了ILogger<T>服务，所以DI容器能找到这个服务的实现，递归地把所有依赖（这里就是日志实例）注入到构造函数里，最终创建出完整的控制器实例。

如果你的控制器有多个公共构造函数，比如一个带ILogger，一个带IRepository，而这两个依赖都在DI里注册了，那框架会直接抛出异常——因为它不知道该选哪个构造函数。

3. 有没有必须遵循的签名约定？ #

严格来说没有“强制的签名列表”，但有几个需要注意的规则：

• 构造函数必须是public的：私有/保护的构造函数框架无法访问，会导致激活失败。
• 避免多个可解析的公共构造函数：刚才说过，这种情况会触发异常，最好只保留一个公共构造函数。
• 构造函数的参数必须是DI容器中已注册的服务：如果你加了一个DI里没注册的类型参数，框架会抛出“无法解析服务类型”的异常。
• 支持无参数构造函数：如果你的控制器没有任何依赖，用默认的无参构造函数也完全没问题，框架会直接创建实例。

额外补充：自定义激活逻辑 #

如果默认的激活机制满足不了你的需求（比如想通过其他方式创建控制器），你可以实现自己的IControllerActivator，然后在Startup.cs的ConfigureServices里替换默认服务：

services.Replace(ServiceDescriptor.Transient<IControllerActivator, CustomControllerActivator>());

不过绝大多数场景下，默认的激活器和DI系统已经足够用了。

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