Autofac使用TypedParameter解析时参数匹配问题咨询

首先，你的观察完全符合Autofac的预期行为——TypedParameter的设计逻辑就是仅按参数类型匹配注入值，而不会考虑参数的顺序或名称。下面详细拆解这个问题：

为什么你的第二个断言会失败？ #

在你的示例中，构造函数A(string a, string b)有两个同类型参数。当你传入两个TypedParameter(typeof(string), "First")和TypedParameter(typeof(string), "Second")时，Autofac的解析逻辑是：

对构造函数的每个参数，查找第一个匹配其类型的TypedParameter值。

因为两个参数都是string类型，它们都会匹配到你传入的第一个TypedParameter（值为"First"），第二个同类型的TypedParameter会被忽略——这就是为什么instance.b也变成了"First"。

TypedParameter的预期行为与核心用途 #

预期行为 #

• 仅基于参数的类型进行匹配，不关心参数的名称、在构造函数中的位置。
• 当构造函数存在多个同类型参数时，所有这些参数都会使用第一个匹配该类型的TypedParameter值，后续同类型的TypedParameter不会生效。

核心用途 #

TypedParameter最适合以下场景：

• 构造函数中该类型的参数唯一：比如某个类只有一个int或ILogger类型的构造参数，此时用TypedParameter不需要记住参数名称，代码更简洁。
• 你不知道参数的具体名称，但明确知道参数类型：比如在通用工具类中解析某个类型，不想硬编码参数名称（避免因参数名重构导致代码失效）。

TypedParameter能做，但NamedParameter做不到的场景 #

虽然NamedParameter能解决同类型多参数的区分问题，但TypedParameter在以下场景更有优势：

1. 参数名称不稳定的场景：如果目标类的构造参数名称可能会被重构修改，用TypedParameter不需要同步修改注入代码，因为它依赖的是类型而非名称。
2. 通用注入逻辑：比如封装一个全局的服务解析方法，需要给任意类型注入某个固定类型的依赖（比如注入当前用户ID，类型为Guid），此时不需要关心目标类的参数名称，只要知道有一个Guid类型的参数即可。
3. 简化单类型参数注入：当构造函数只有一个该类型参数时，TypedParameter比NamedParameter更简洁——你不需要额外写参数名称，减少冗余代码。

如何解决你的示例问题？ #

如果你需要按顺序或名称区分同类型参数，有两种更合适的选择：

1. 使用NamedParameter（按参数名称匹配） #

var instance = container.Resolve<A>(
    new NamedParameter("a", "First"),
    new NamedParameter("b", "Second"));

2. 使用PositionalParameter（按参数位置匹配） #

如果你确定参数的位置不会变，也可以用位置匹配：

var instance = container.Resolve<A>(
    new PositionalParameter(0, "First"),
    new PositionalParameter(1, "Second"));

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