ASP.NET Core 试题 09：依赖注入高级用法
0161 在 多实现注册 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 直接解析接口时容器会随机选择一个实现
- B. 依赖注册顺序不应成为隐蔽业务优先级，必要时显式建模
- C. 注册多个同一服务类型后，IEnumerable 会按注册顺序提供全部实现，直接解析通常得到最后一个
- D. 观察到“新增处理器后默认实现意外改变”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案C
正确答案直接描述 多实现注册 的主规则：注册多个同一服务类型后，IEnumerable 会按注册顺序提供全部实现，直接解析通常得到最后一个。选项“依赖注册顺序不应成为隐蔽业务优先级，必要时显式建模”是使用规则时要验证的边界，不是规则本身；“直接解析接口时容器会随机选择一个实现”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0162 新增处理器后默认实现意外改变。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“直接解析接口时容器会随机选择一个实现”定性，不再检查配置、身份或运行时证据。
- B. 先验证“依赖注册顺序不应成为隐蔽业务优先级，必要时显式建模”，再依据“注册多个同一服务类型后，IEnumerable 会按注册顺序提供全部实现，直接解析通常得到最后一个”判断实现是否符合契约。
- C. 只增加重试次数或机器资源，暂不核对“依赖注册顺序不应成为隐蔽业务优先级，必要时显式建模”。
- D. 以一次成功请求作为结论，不再确认“注册多个同一服务类型后，IEnumerable 会按注册顺序提供全部实现，直接解析通常得到最后一个”是否成立。
查看答案与解析
正确答案B
场景“新增处理器后默认实现意外改变”指向 多实现注册，但症状本身不能证明根因。正确排查应先确认边界“依赖注册顺序不应成为隐蔽业务优先级，必要时显式建模”，再用主规则“注册多个同一服务类型后，IEnumerable 会按注册顺序提供全部实现，直接解析通常得到最后一个”解释证据。直接采用误区“直接解析接口时容器会随机选择一个实现”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0163 关于 多实现注册，以下哪项说法不成立？
难度： 实战
- A. 注册多个同一服务类型后，IEnumerable 会按注册顺序提供全部实现，直接解析通常得到最后一个
- B. 依赖注册顺序不应成为隐蔽业务优先级，必要时显式建模
- C. 出现“新增处理器后默认实现意外改变”时，应收集证据并同时核对主规则与适用边界。
- D. 直接解析接口时容器会随机选择一个实现
查看答案与解析
正确答案D
题目要求选出不成立的说法，答案“直接解析接口时容器会随机选择一个实现”正是 多实现注册 的典型误区。其余三项分别给出了主规则“注册多个同一服务类型后，IEnumerable 会按注册顺序提供全部实现，直接解析通常得到最后一个”、适用边界“依赖注册顺序不应成为隐蔽业务优先级，必要时显式建模”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0164 针对“新增处理器后默认实现意外改变”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“注册多个同一服务类型后，IEnumerable 会按注册顺序提供全部实现，直接解析通常得到最后一个”修正实现，并用测试或遥测验证“依赖注册顺序不应成为隐蔽业务优先级，必要时显式建模”。
- B. 按“直接解析接口时容器会随机选择一个实现”修改实现，并把一次请求成功作为验收结果。
- C. 按“注册多个同一服务类型后，IEnumerable 会按注册顺序提供全部实现，直接解析通常得到最后一个”修改代码后直接上线，不验证“依赖注册顺序不应成为隐蔽业务优先级，必要时显式建模”。
- D. 只验证“依赖注册顺序不应成为隐蔽业务优先级，必要时显式建模”，但实现仍继续依赖“直接解析接口时容器会随机选择一个实现”。
查看答案与解析
正确答案A
完整决策同时覆盖规则与验证：注册多个同一服务类型后，IEnumerable 会按注册顺序提供全部实现，直接解析通常得到最后一个；并确认 依赖注册顺序不应成为隐蔽业务优先级，必要时显式建模。继续接受“直接解析接口时容器会随机选择一个实现”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“新增处理器后默认实现意外改变”这一生产场景能否安全上线。
0165 在 Keyed services 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 键控服务会在编译期验证所有调用使用的键
- B. 键必须保持一致且可治理，过度使用字符串键会把依赖错误推迟到运行时
- C. 观察到“某租户使用不存在的服务键”即可把一次现象当成完整框架契约。
- D. 键控服务允许同一契约按键注册和解析不同实现
查看答案与解析
正确答案D
正确答案直接描述 Keyed services 的主规则：键控服务允许同一契约按键注册和解析不同实现。选项“键必须保持一致且可治理，过度使用字符串键会把依赖错误推迟到运行时”是使用规则时要验证的边界，不是规则本身；“键控服务会在编译期验证所有调用使用的键”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0166 某租户使用不存在的服务键。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“键控服务会在编译期验证所有调用使用的键”定性，不再检查配置、身份或运行时证据。
- B. 先验证“键必须保持一致且可治理，过度使用字符串键会把依赖错误推迟到运行时”，再依据“键控服务允许同一契约按键注册和解析不同实现”判断实现是否符合契约。
- C. 只增加重试次数或机器资源，暂不核对“键必须保持一致且可治理，过度使用字符串键会把依赖错误推迟到运行时”。
- D. 以一次成功请求作为结论，不再确认“键控服务允许同一契约按键注册和解析不同实现”是否成立。
查看答案与解析
正确答案B
场景“某租户使用不存在的服务键”指向 Keyed services，但症状本身不能证明根因。正确排查应先确认边界“键必须保持一致且可治理，过度使用字符串键会把依赖错误推迟到运行时”，再用主规则“键控服务允许同一契约按键注册和解析不同实现”解释证据。直接采用误区“键控服务会在编译期验证所有调用使用的键”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0167 关于 Keyed services，以下哪项说法不成立？
难度： 实战
- A. 键控服务会在编译期验证所有调用使用的键
- B. 键控服务允许同一契约按键注册和解析不同实现
- C. 键必须保持一致且可治理，过度使用字符串键会把依赖错误推迟到运行时
- D. 出现“某租户使用不存在的服务键”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案A
题目要求选出不成立的说法，答案“键控服务会在编译期验证所有调用使用的键”正是 Keyed services 的典型误区。其余三项分别给出了主规则“键控服务允许同一契约按键注册和解析不同实现”、适用边界“键必须保持一致且可治理，过度使用字符串键会把依赖错误推迟到运行时”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0168 针对“某租户使用不存在的服务键”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“键控服务会在编译期验证所有调用使用的键”修改实现，并把一次请求成功作为验收结果。
- B. 按“键控服务允许同一契约按键注册和解析不同实现”修改代码后直接上线，不验证“键必须保持一致且可治理，过度使用字符串键会把依赖错误推迟到运行时”。
- C. 按“键控服务允许同一契约按键注册和解析不同实现”修正实现，并用测试或遥测验证“键必须保持一致且可治理，过度使用字符串键会把依赖错误推迟到运行时”。
- D. 只验证“键必须保持一致且可治理，过度使用字符串键会把依赖错误推迟到运行时”，但实现仍继续依赖“键控服务会在编译期验证所有调用使用的键”。
查看答案与解析
正确答案C
完整决策同时覆盖规则与验证：键控服务允许同一契约按键注册和解析不同实现；并确认 键必须保持一致且可治理，过度使用字符串键会把依赖错误推迟到运行时。继续接受“键控服务会在编译期验证所有调用使用的键”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“某租户使用不存在的服务键”这一生产场景能否安全上线。
0169 在 TryAdd 与 Replace 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. TryAdd 仅在服务类型尚未注册时添加，Replace 用新描述替换已有注册
- B. TryAdd 会覆盖应用之前注册的自定义实现
- C. 库作者常用 TryAdd 允许应用覆盖默认实现，替换时仍需关注生命周期
- D. 观察到“集成库注册后业务实现被意外替换”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案A
正确答案直接描述 TryAdd 与 Replace 的主规则：TryAdd 仅在服务类型尚未注册时添加，Replace 用新描述替换已有注册。选项“库作者常用 TryAdd 允许应用覆盖默认实现，替换时仍需关注生命周期”是使用规则时要验证的边界，不是规则本身；“TryAdd 会覆盖应用之前注册的自定义实现”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0170 集成库注册后业务实现被意外替换。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“TryAdd 会覆盖应用之前注册的自定义实现”定性，不再检查配置、身份或运行时证据。
- B. 先验证“库作者常用 TryAdd 允许应用覆盖默认实现，替换时仍需关注生命周期”，再依据“TryAdd 仅在服务类型尚未注册时添加，Replace 用新描述替换已有注册”判断实现是否符合契约。
- C. 只增加重试次数或机器资源，暂不核对“库作者常用 TryAdd 允许应用覆盖默认实现，替换时仍需关注生命周期”。
- D. 以一次成功请求作为结论，不再确认“TryAdd 仅在服务类型尚未注册时添加，Replace 用新描述替换已有注册”是否成立。
查看答案与解析
正确答案B
场景“集成库注册后业务实现被意外替换”指向 TryAdd 与 Replace，但症状本身不能证明根因。正确排查应先确认边界“库作者常用 TryAdd 允许应用覆盖默认实现，替换时仍需关注生命周期”，再用主规则“TryAdd 仅在服务类型尚未注册时添加，Replace 用新描述替换已有注册”解释证据。直接采用误区“TryAdd 会覆盖应用之前注册的自定义实现”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0171 关于 TryAdd 与 Replace，以下哪项说法不成立？
难度： 实战
- A. TryAdd 仅在服务类型尚未注册时添加，Replace 用新描述替换已有注册
- B. 库作者常用 TryAdd 允许应用覆盖默认实现，替换时仍需关注生命周期
- C. 出现“集成库注册后业务实现被意外替换”时，应收集证据并同时核对主规则与适用边界。
- D. TryAdd 会覆盖应用之前注册的自定义实现
查看答案与解析
正确答案D
题目要求选出不成立的说法，答案“TryAdd 会覆盖应用之前注册的自定义实现”正是 TryAdd 与 Replace 的典型误区。其余三项分别给出了主规则“TryAdd 仅在服务类型尚未注册时添加，Replace 用新描述替换已有注册”、适用边界“库作者常用 TryAdd 允许应用覆盖默认实现，替换时仍需关注生命周期”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0172 针对“集成库注册后业务实现被意外替换”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“TryAdd 会覆盖应用之前注册的自定义实现”修改实现，并把一次请求成功作为验收结果。
- B. 按“TryAdd 仅在服务类型尚未注册时添加，Replace 用新描述替换已有注册”修改代码后直接上线，不验证“库作者常用 TryAdd 允许应用覆盖默认实现，替换时仍需关注生命周期”。
- C. 按“TryAdd 仅在服务类型尚未注册时添加，Replace 用新描述替换已有注册”修正实现，并用测试或遥测验证“库作者常用 TryAdd 允许应用覆盖默认实现，替换时仍需关注生命周期”。
- D. 只验证“库作者常用 TryAdd 允许应用覆盖默认实现，替换时仍需关注生命周期”，但实现仍继续依赖“TryAdd 会覆盖应用之前注册的自定义实现”。
查看答案与解析
正确答案C
完整决策同时覆盖规则与验证：TryAdd 仅在服务类型尚未注册时添加，Replace 用新描述替换已有注册；并确认 库作者常用 TryAdd 允许应用覆盖默认实现，替换时仍需关注生命周期。继续接受“TryAdd 会覆盖应用之前注册的自定义实现”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“集成库注册后业务实现被意外替换”这一生产场景能否安全上线。
0173 在 工厂注册 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 使用工厂注册后容器不再管理返回对象的释放
- B. 实现工厂可根据 IServiceProvider 构造服务，但仍受声明生命周期约束
- C. 工厂中不应自行 new 后遗漏释放，也不能借机从根容器捕获 Scoped 服务
- D. 观察到“工厂创建的 HttpClientHandler 长期泄漏”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案B
正确答案直接描述 工厂注册 的主规则：实现工厂可根据 IServiceProvider 构造服务，但仍受声明生命周期约束。选项“工厂中不应自行 new 后遗漏释放，也不能借机从根容器捕获 Scoped 服务”是使用规则时要验证的边界，不是规则本身；“使用工厂注册后容器不再管理返回对象的释放”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0174 工厂创建的 HttpClientHandler 长期泄漏。排查时哪项动作最合理？
难度： 进阶
- A. 先验证“工厂中不应自行 new 后遗漏释放，也不能借机从根容器捕获 Scoped 服务”，再依据“实现工厂可根据 IServiceProvider 构造服务，但仍受声明生命周期约束”判断实现是否符合契约。
- B. 直接按“使用工厂注册后容器不再管理返回对象的释放”定性，不再检查配置、身份或运行时证据。
- C. 只增加重试次数或机器资源，暂不核对“工厂中不应自行 new 后遗漏释放，也不能借机从根容器捕获 Scoped 服务”。
- D. 以一次成功请求作为结论，不再确认“实现工厂可根据 IServiceProvider 构造服务，但仍受声明生命周期约束”是否成立。
查看答案与解析
正确答案A
场景“工厂创建的 HttpClientHandler 长期泄漏”指向 工厂注册，但症状本身不能证明根因。正确排查应先确认边界“工厂中不应自行 new 后遗漏释放，也不能借机从根容器捕获 Scoped 服务”，再用主规则“实现工厂可根据 IServiceProvider 构造服务，但仍受声明生命周期约束”解释证据。直接采用误区“使用工厂注册后容器不再管理返回对象的释放”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0175 关于 工厂注册，以下哪项说法不成立？
难度： 实战
- A. 实现工厂可根据 IServiceProvider 构造服务，但仍受声明生命周期约束
- B. 工厂中不应自行 new 后遗漏释放，也不能借机从根容器捕获 Scoped 服务
- C. 使用工厂注册后容器不再管理返回对象的释放
- D. 出现“工厂创建的 HttpClientHandler 长期泄漏”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案C
题目要求选出不成立的说法，答案“使用工厂注册后容器不再管理返回对象的释放”正是 工厂注册 的典型误区。其余三项分别给出了主规则“实现工厂可根据 IServiceProvider 构造服务，但仍受声明生命周期约束”、适用边界“工厂中不应自行 new 后遗漏释放，也不能借机从根容器捕获 Scoped 服务”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0176 针对“工厂创建的 HttpClientHandler 长期泄漏”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“使用工厂注册后容器不再管理返回对象的释放”修改实现，并把一次请求成功作为验收结果。
- B. 按“实现工厂可根据 IServiceProvider 构造服务，但仍受声明生命周期约束”修改代码后直接上线，不验证“工厂中不应自行 new 后遗漏释放，也不能借机从根容器捕获 Scoped 服务”。
- C. 只验证“工厂中不应自行 new 后遗漏释放，也不能借机从根容器捕获 Scoped 服务”，但实现仍继续依赖“使用工厂注册后容器不再管理返回对象的释放”。
- D. 按“实现工厂可根据 IServiceProvider 构造服务，但仍受声明生命周期约束”修正实现，并用测试或遥测验证“工厂中不应自行 new 后遗漏释放，也不能借机从根容器捕获 Scoped 服务”。
查看答案与解析
正确答案D
完整决策同时覆盖规则与验证：实现工厂可根据 IServiceProvider 构造服务，但仍受声明生命周期约束；并确认 工厂中不应自行 new 后遗漏释放，也不能借机从根容器捕获 Scoped 服务。继续接受“使用工厂注册后容器不再管理返回对象的释放”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“工厂创建的 HttpClientHandler 长期泄漏”这一生产场景能否安全上线。
0177 在 服务定位器 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 服务定位器能让依赖关系更容易被编译器检查
- B. 在业务代码中到处注入 IServiceProvider 会隐藏真实依赖并推迟错误
- C. 框架集成或动态插件可能需要受控解析，但常规服务应优先构造函数依赖
- D. 观察到“单元测试必须配置大量隐式服务才能运行”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案B
正确答案直接描述 服务定位器 的主规则：在业务代码中到处注入 IServiceProvider 会隐藏真实依赖并推迟错误。选项“框架集成或动态插件可能需要受控解析，但常规服务应优先构造函数依赖”是使用规则时要验证的边界，不是规则本身；“服务定位器能让依赖关系更容易被编译器检查”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0178 单元测试必须配置大量隐式服务才能运行。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“服务定位器能让依赖关系更容易被编译器检查”定性，不再检查配置、身份或运行时证据。
- B. 只增加重试次数或机器资源，暂不核对“框架集成或动态插件可能需要受控解析，但常规服务应优先构造函数依赖”。
- C. 以一次成功请求作为结论，不再确认“在业务代码中到处注入 IServiceProvider 会隐藏真实依赖并推迟错误”是否成立。
- D. 先验证“框架集成或动态插件可能需要受控解析，但常规服务应优先构造函数依赖”，再依据“在业务代码中到处注入 IServiceProvider 会隐藏真实依赖并推迟错误”判断实现是否符合契约。
查看答案与解析
正确答案D
场景“单元测试必须配置大量隐式服务才能运行”指向 服务定位器，但症状本身不能证明根因。正确排查应先确认边界“框架集成或动态插件可能需要受控解析，但常规服务应优先构造函数依赖”，再用主规则“在业务代码中到处注入 IServiceProvider 会隐藏真实依赖并推迟错误”解释证据。直接采用误区“服务定位器能让依赖关系更容易被编译器检查”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0179 关于 服务定位器，以下哪项说法不成立？
难度： 实战
- A. 在业务代码中到处注入 IServiceProvider 会隐藏真实依赖并推迟错误
- B. 框架集成或动态插件可能需要受控解析，但常规服务应优先构造函数依赖
- C. 服务定位器能让依赖关系更容易被编译器检查
- D. 出现“单元测试必须配置大量隐式服务才能运行”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案C
题目要求选出不成立的说法，答案“服务定位器能让依赖关系更容易被编译器检查”正是 服务定位器 的典型误区。其余三项分别给出了主规则“在业务代码中到处注入 IServiceProvider 会隐藏真实依赖并推迟错误”、适用边界“框架集成或动态插件可能需要受控解析，但常规服务应优先构造函数依赖”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0180 针对“单元测试必须配置大量隐式服务才能运行”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“在业务代码中到处注入 IServiceProvider 会隐藏真实依赖并推迟错误”修正实现，并用测试或遥测验证“框架集成或动态插件可能需要受控解析，但常规服务应优先构造函数依赖”。
- B. 按“服务定位器能让依赖关系更容易被编译器检查”修改实现，并把一次请求成功作为验收结果。
- C. 按“在业务代码中到处注入 IServiceProvider 会隐藏真实依赖并推迟错误”修改代码后直接上线，不验证“框架集成或动态插件可能需要受控解析，但常规服务应优先构造函数依赖”。
- D. 只验证“框架集成或动态插件可能需要受控解析，但常规服务应优先构造函数依赖”，但实现仍继续依赖“服务定位器能让依赖关系更容易被编译器检查”。
查看答案与解析
正确答案A
完整决策同时覆盖规则与验证：在业务代码中到处注入 IServiceProvider 会隐藏真实依赖并推迟错误；并确认 框架集成或动态插件可能需要受控解析，但常规服务应优先构造函数依赖。继续接受“服务定位器能让依赖关系更容易被编译器检查”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“单元测试必须配置大量隐式服务才能运行”这一生产场景能否安全上线。