为什么没有内置的容器注册分析？

在使用 Autofac 容器时，如果注册不完整或有误，解析时出现运行时异常会让人感到非常沮丧。为什么不内置一种分析机制，以便在容器构建后验证其有效性呢？

虽然某些容器确实提供了这种功能，但 Autofac 在依赖项解析方面的灵活性（根据运行时参数和动态功能进行处理）使得提供有用的容器有效性检查变得困难。

考虑以下示例代码：

var builder = new ContainerBuilder();

// 生产环境配置需要一个 connectionString 参数，因为它从数据库读取。
builder.RegisterType<ProdConfiguration>().AsSelf();

// Lambda 根据环境变量返回正确的配置。
builder.Register(ctx => {
    var env = Environment.GetEnvironmentVariable("ENVIRONMENT");
    switch (env)
    {
        case "Development":
            return new TestConfiguration();
        case "Production":
            return ctx.Resolve<ProdConfiguration>(new NamedParameter("connStr", connectionString));
        default:
            throw new NotSupportedException("未知的环境名称。");
    }).As<IConfiguration>();
});

这样的容器配置是完全有效的，但也引发了一些问题：

• 如果 ProdConfiguration 需要一个未在容器中注册的连接字符串参数，你的容器有效吗？如果你使用服务定位并在解析时传递该字符串（参阅 这里），容器如何知道？
• 如果 IConfiguration 依赖于特定的环境参数，而在部署时存在但在单元测试时不存在，你的容器有效吗？

这些都是相对简单的情况。再考虑一下其他情况，如...

• 可以动态附加到所有注册项的模块，例如 日志模块
• 注册源
• 注册参数
• 拦截器，适配器装饰器，以及 装饰器
• 动态程序集扫描

这些并非罕见场景，而且这还不是支持的所有动态功能的完整列表。

尽管有可能在将来添加一个非常简单的分析机制来检测少数问题，但更有可能的是增强 Autofac 的诊断和跟踪功能，以更快地定位和解决遇到的运行时挑战。（如果您有兴趣参与这项工作，请 告诉我们！）