ASP.NET Core 试题 39：HttpClientFactory 与弹性
0761 在 处理器池 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. Factory 为每次请求创建全新 TCP 连接且不复用
- B. IHttpClientFactory 创建短生命周期 HttpClient，同时池化底层 HttpMessageHandler
- C. HandlerLifetime 需兼顾连接复用和 DNS 变化，不能每请求 new 并立刻释放处理器
- D. 观察到“高并发下端口耗尽”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案B
正确答案直接描述 处理器池 的主规则：IHttpClientFactory 创建短生命周期 HttpClient，同时池化底层 HttpMessageHandler。选项“HandlerLifetime 需兼顾连接复用和 DNS 变化，不能每请求 new 并立刻释放处理器”是使用规则时要验证的边界，不是规则本身；“Factory 为每次请求创建全新 TCP 连接且不复用”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0762 高并发下端口耗尽。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“Factory 为每次请求创建全新 TCP 连接且不复用”定性，不再检查配置、身份或运行时证据。
- B. 只增加重试次数或机器资源，暂不核对“HandlerLifetime 需兼顾连接复用和 DNS 变化，不能每请求 new 并立刻释放处理器”。
- C. 先验证“HandlerLifetime 需兼顾连接复用和 DNS 变化，不能每请求 new 并立刻释放处理器”，再依据“IHttpClientFactory 创建短生命周期 HttpClient，同时池化底层 HttpMessageHandler”判断实现是否符合契约。
- D. 以一次成功请求作为结论，不再确认“IHttpClientFactory 创建短生命周期 HttpClient，同时池化底层 HttpMessageHandler”是否成立。
查看答案与解析
正确答案C
场景“高并发下端口耗尽”指向 处理器池，但症状本身不能证明根因。正确排查应先确认边界“HandlerLifetime 需兼顾连接复用和 DNS 变化，不能每请求 new 并立刻释放处理器”，再用主规则“IHttpClientFactory 创建短生命周期 HttpClient，同时池化底层 HttpMessageHandler”解释证据。直接采用误区“Factory 为每次请求创建全新 TCP 连接且不复用”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0763 关于 处理器池，以下哪项说法不成立？
难度： 实战
- A. IHttpClientFactory 创建短生命周期 HttpClient，同时池化底层 HttpMessageHandler
- B. HandlerLifetime 需兼顾连接复用和 DNS 变化，不能每请求 new 并立刻释放处理器
- C. 出现“高并发下端口耗尽”时，应收集证据并同时核对主规则与适用边界。
- D. Factory 为每次请求创建全新 TCP 连接且不复用
查看答案与解析
正确答案D
题目要求选出不成立的说法，答案“Factory 为每次请求创建全新 TCP 连接且不复用”正是 处理器池 的典型误区。其余三项分别给出了主规则“IHttpClientFactory 创建短生命周期 HttpClient，同时池化底层 HttpMessageHandler”、适用边界“HandlerLifetime 需兼顾连接复用和 DNS 变化，不能每请求 new 并立刻释放处理器”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0764 针对“高并发下端口耗尽”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“IHttpClientFactory 创建短生命周期 HttpClient，同时池化底层 HttpMessageHandler”修正实现，并用测试或遥测验证“HandlerLifetime 需兼顾连接复用和 DNS 变化，不能每请求 new 并立刻释放处理器”。
- B. 按“Factory 为每次请求创建全新 TCP 连接且不复用”修改实现，并把一次请求成功作为验收结果。
- C. 按“IHttpClientFactory 创建短生命周期 HttpClient，同时池化底层 HttpMessageHandler”修改代码后直接上线，不验证“HandlerLifetime 需兼顾连接复用和 DNS 变化，不能每请求 new 并立刻释放处理器”。
- D. 只验证“HandlerLifetime 需兼顾连接复用和 DNS 变化，不能每请求 new 并立刻释放处理器”，但实现仍继续依赖“Factory 为每次请求创建全新 TCP 连接且不复用”。
查看答案与解析
正确答案A
完整决策同时覆盖规则与验证：IHttpClientFactory 创建短生命周期 HttpClient，同时池化底层 HttpMessageHandler；并确认 HandlerLifetime 需兼顾连接复用和 DNS 变化，不能每请求 new 并立刻释放处理器。继续接受“Factory 为每次请求创建全新 TCP 连接且不复用”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“高并发下端口耗尽”这一生产场景能否安全上线。
0765 在 Typed Client 生命周期 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. Typed Client 被单例捕获后每个请求仍由 DI 自动替换字段
- B. 把 Typed Client 捕获进 Singleton 可能阻止按预期重新解析和更新处理器配置
- C. Typed Client 通常注册为 Transient，并封装特定下游配置
- D. 观察到“DNS 切换后单例长期连接旧地址”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案C
正确答案直接描述 Typed Client 生命周期 的主规则：Typed Client 通常注册为 Transient，并封装特定下游配置。选项“把 Typed Client 捕获进 Singleton 可能阻止按预期重新解析和更新处理器配置”是使用规则时要验证的边界，不是规则本身；“Typed Client 被单例捕获后每个请求仍由 DI 自动替换字段”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0766 DNS 切换后单例长期连接旧地址。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“Typed Client 被单例捕获后每个请求仍由 DI 自动替换字段”定性，不再检查配置、身份或运行时证据。
- B. 先验证“把 Typed Client 捕获进 Singleton 可能阻止按预期重新解析和更新处理器配置”，再依据“Typed Client 通常注册为 Transient，并封装特定下游配置”判断实现是否符合契约。
- C. 只增加重试次数或机器资源，暂不核对“把 Typed Client 捕获进 Singleton 可能阻止按预期重新解析和更新处理器配置”。
- D. 以一次成功请求作为结论，不再确认“Typed Client 通常注册为 Transient，并封装特定下游配置”是否成立。
查看答案与解析
正确答案B
场景“DNS 切换后单例长期连接旧地址”指向 Typed Client 生命周期，但症状本身不能证明根因。正确排查应先确认边界“把 Typed Client 捕获进 Singleton 可能阻止按预期重新解析和更新处理器配置”，再用主规则“Typed Client 通常注册为 Transient，并封装特定下游配置”解释证据。直接采用误区“Typed Client 被单例捕获后每个请求仍由 DI 自动替换字段”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0767 关于 Typed Client 生命周期，以下哪项说法不成立？
难度： 实战
- A. Typed Client 被单例捕获后每个请求仍由 DI 自动替换字段
- B. Typed Client 通常注册为 Transient，并封装特定下游配置
- C. 把 Typed Client 捕获进 Singleton 可能阻止按预期重新解析和更新处理器配置
- D. 出现“DNS 切换后单例长期连接旧地址”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案A
题目要求选出不成立的说法，答案“Typed Client 被单例捕获后每个请求仍由 DI 自动替换字段”正是 Typed Client 生命周期 的典型误区。其余三项分别给出了主规则“Typed Client 通常注册为 Transient，并封装特定下游配置”、适用边界“把 Typed Client 捕获进 Singleton 可能阻止按预期重新解析和更新处理器配置”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0768 针对“DNS 切换后单例长期连接旧地址”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“Typed Client 被单例捕获后每个请求仍由 DI 自动替换字段”修改实现，并把一次请求成功作为验收结果。
- B. 按“Typed Client 通常注册为 Transient，并封装特定下游配置”修改代码后直接上线，不验证“把 Typed Client 捕获进 Singleton 可能阻止按预期重新解析和更新处理器配置”。
- C. 只验证“把 Typed Client 捕获进 Singleton 可能阻止按预期重新解析和更新处理器配置”，但实现仍继续依赖“Typed Client 被单例捕获后每个请求仍由 DI 自动替换字段”。
- D. 按“Typed Client 通常注册为 Transient，并封装特定下游配置”修正实现，并用测试或遥测验证“把 Typed Client 捕获进 Singleton 可能阻止按预期重新解析和更新处理器配置”。
查看答案与解析
正确答案D
完整决策同时覆盖规则与验证：Typed Client 通常注册为 Transient，并封装特定下游配置；并确认 把 Typed Client 捕获进 Singleton 可能阻止按预期重新解析和更新处理器配置。继续接受“Typed Client 被单例捕获后每个请求仍由 DI 自动替换字段”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“DNS 切换后单例长期连接旧地址”这一生产场景能否安全上线。
0769 在 重试策略 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 所有 5xx 都应无限立即重试直到成功
- B. 非幂等写请求可能重复产生副作用，应使用幂等键或仅重试安全条件
- C. 观察到“下游故障时重试放大流量形成雪崩”即可把一次现象当成完整框架契约。
- D. 重试适合瞬态失败，但次数、退避、抖动和总超时都需限制
查看答案与解析
正确答案D
正确答案直接描述 重试策略 的主规则：重试适合瞬态失败，但次数、退避、抖动和总超时都需限制。选项“非幂等写请求可能重复产生副作用，应使用幂等键或仅重试安全条件”是使用规则时要验证的边界，不是规则本身；“所有 5xx 都应无限立即重试直到成功”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0770 下游故障时重试放大流量形成雪崩。排查时哪项动作最合理？
难度： 进阶
- A. 先验证“非幂等写请求可能重复产生副作用，应使用幂等键或仅重试安全条件”，再依据“重试适合瞬态失败，但次数、退避、抖动和总超时都需限制”判断实现是否符合契约。
- B. 直接按“所有 5xx 都应无限立即重试直到成功”定性，不再检查配置、身份或运行时证据。
- C. 只增加重试次数或机器资源，暂不核对“非幂等写请求可能重复产生副作用，应使用幂等键或仅重试安全条件”。
- D. 以一次成功请求作为结论，不再确认“重试适合瞬态失败，但次数、退避、抖动和总超时都需限制”是否成立。
查看答案与解析
正确答案A
场景“下游故障时重试放大流量形成雪崩”指向 重试策略，但症状本身不能证明根因。正确排查应先确认边界“非幂等写请求可能重复产生副作用，应使用幂等键或仅重试安全条件”，再用主规则“重试适合瞬态失败，但次数、退避、抖动和总超时都需限制”解释证据。直接采用误区“所有 5xx 都应无限立即重试直到成功”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0771 关于 重试策略，以下哪项说法不成立？
难度： 实战
- A. 重试适合瞬态失败，但次数、退避、抖动和总超时都需限制
- B. 非幂等写请求可能重复产生副作用，应使用幂等键或仅重试安全条件
- C. 所有 5xx 都应无限立即重试直到成功
- D. 出现“下游故障时重试放大流量形成雪崩”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案C
题目要求选出不成立的说法，答案“所有 5xx 都应无限立即重试直到成功”正是 重试策略 的典型误区。其余三项分别给出了主规则“重试适合瞬态失败，但次数、退避、抖动和总超时都需限制”、适用边界“非幂等写请求可能重复产生副作用，应使用幂等键或仅重试安全条件”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0772 针对“下游故障时重试放大流量形成雪崩”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“所有 5xx 都应无限立即重试直到成功”修改实现，并把一次请求成功作为验收结果。
- B. 按“重试适合瞬态失败，但次数、退避、抖动和总超时都需限制”修正实现，并用测试或遥测验证“非幂等写请求可能重复产生副作用，应使用幂等键或仅重试安全条件”。
- C. 按“重试适合瞬态失败，但次数、退避、抖动和总超时都需限制”修改代码后直接上线，不验证“非幂等写请求可能重复产生副作用，应使用幂等键或仅重试安全条件”。
- D. 只验证“非幂等写请求可能重复产生副作用，应使用幂等键或仅重试安全条件”，但实现仍继续依赖“所有 5xx 都应无限立即重试直到成功”。
查看答案与解析
正确答案B
完整决策同时覆盖规则与验证：重试适合瞬态失败，但次数、退避、抖动和总超时都需限制；并确认 非幂等写请求可能重复产生副作用，应使用幂等键或仅重试安全条件。继续接受“所有 5xx 都应无限立即重试直到成功”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“下游故障时重试放大流量形成雪崩”这一生产场景能否安全上线。
0773 在 HTTP 请求超时与取消 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. HttpClient.Timeout、策略超时和调用 CancellationToken 可能共同终止请求
- B. 设置 HttpClient.Timeout 后不再需要传请求取消令牌
- C. 要区分调用方取消、超时和网络失败，并保证响应与流正确释放
- D. 观察到“客户端断开后下游调用仍继续到全局超时”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案A
正确答案直接描述 HTTP 请求超时与取消 的主规则：HttpClient.Timeout、策略超时和调用 CancellationToken 可能共同终止请求。选项“要区分调用方取消、超时和网络失败，并保证响应与流正确释放”是使用规则时要验证的边界，不是规则本身；“设置 HttpClient.Timeout 后不再需要传请求取消令牌”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0774 客户端断开后下游调用仍继续到全局超时。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“设置 HttpClient.Timeout 后不再需要传请求取消令牌”定性，不再检查配置、身份或运行时证据。
- B. 先验证“要区分调用方取消、超时和网络失败，并保证响应与流正确释放”，再依据“HttpClient.Timeout、策略超时和调用 CancellationToken 可能共同终止请求”判断实现是否符合契约。
- C. 只增加重试次数或机器资源，暂不核对“要区分调用方取消、超时和网络失败，并保证响应与流正确释放”。
- D. 以一次成功请求作为结论，不再确认“HttpClient.Timeout、策略超时和调用 CancellationToken 可能共同终止请求”是否成立。
查看答案与解析
正确答案B
场景“客户端断开后下游调用仍继续到全局超时”指向 HTTP 请求超时与取消，但症状本身不能证明根因。正确排查应先确认边界“要区分调用方取消、超时和网络失败，并保证响应与流正确释放”，再用主规则“HttpClient.Timeout、策略超时和调用 CancellationToken 可能共同终止请求”解释证据。直接采用误区“设置 HttpClient.Timeout 后不再需要传请求取消令牌”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0775 关于 HTTP 请求超时与取消，以下哪项说法不成立？
难度： 实战
- A. HttpClient.Timeout、策略超时和调用 CancellationToken 可能共同终止请求
- B. 要区分调用方取消、超时和网络失败，并保证响应与流正确释放
- C. 设置 HttpClient.Timeout 后不再需要传请求取消令牌
- D. 出现“客户端断开后下游调用仍继续到全局超时”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案C
题目要求选出不成立的说法，答案“设置 HttpClient.Timeout 后不再需要传请求取消令牌”正是 HTTP 请求超时与取消 的典型误区。其余三项分别给出了主规则“HttpClient.Timeout、策略超时和调用 CancellationToken 可能共同终止请求”、适用边界“要区分调用方取消、超时和网络失败，并保证响应与流正确释放”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0776 针对“客户端断开后下游调用仍继续到全局超时”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“设置 HttpClient.Timeout 后不再需要传请求取消令牌”修改实现，并把一次请求成功作为验收结果。
- B. 按“HttpClient.Timeout、策略超时和调用 CancellationToken 可能共同终止请求”修改代码后直接上线，不验证“要区分调用方取消、超时和网络失败，并保证响应与流正确释放”。
- C. 只验证“要区分调用方取消、超时和网络失败，并保证响应与流正确释放”，但实现仍继续依赖“设置 HttpClient.Timeout 后不再需要传请求取消令牌”。
- D. 按“HttpClient.Timeout、策略超时和调用 CancellationToken 可能共同终止请求”修正实现，并用测试或遥测验证“要区分调用方取消、超时和网络失败，并保证响应与流正确释放”。
查看答案与解析
正确答案D
完整决策同时覆盖规则与验证：HttpClient.Timeout、策略超时和调用 CancellationToken 可能共同终止请求；并确认 要区分调用方取消、超时和网络失败，并保证响应与流正确释放。继续接受“设置 HttpClient.Timeout 后不再需要传请求取消令牌”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“客户端断开后下游调用仍继续到全局超时”这一生产场景能否安全上线。
0777 在 请求头与上下文 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. DelegatingHandler 可添加认证、追踪等横切逻辑
- B. DelegatingHandler 每次 HTTP 请求都会创建新实例且绝不复用
- C. Handler 可能被池化跨请求复用，不能在实例字段保存某次请求的用户状态
- D. 观察到“租户令牌被错误复用到另一请求”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案A
正确答案直接描述 请求头与上下文 的主规则：DelegatingHandler 可添加认证、追踪等横切逻辑。选项“Handler 可能被池化跨请求复用，不能在实例字段保存某次请求的用户状态”是使用规则时要验证的边界，不是规则本身；“DelegatingHandler 每次 HTTP 请求都会创建新实例且绝不复用”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0778 租户令牌被错误复用到另一请求。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“DelegatingHandler 每次 HTTP 请求都会创建新实例且绝不复用”定性，不再检查配置、身份或运行时证据。
- B. 只增加重试次数或机器资源，暂不核对“Handler 可能被池化跨请求复用，不能在实例字段保存某次请求的用户状态”。
- C. 以一次成功请求作为结论，不再确认“DelegatingHandler 可添加认证、追踪等横切逻辑”是否成立。
- D. 先验证“Handler 可能被池化跨请求复用，不能在实例字段保存某次请求的用户状态”，再依据“DelegatingHandler 可添加认证、追踪等横切逻辑”判断实现是否符合契约。
查看答案与解析
正确答案D
场景“租户令牌被错误复用到另一请求”指向 请求头与上下文，但症状本身不能证明根因。正确排查应先确认边界“Handler 可能被池化跨请求复用，不能在实例字段保存某次请求的用户状态”，再用主规则“DelegatingHandler 可添加认证、追踪等横切逻辑”解释证据。直接采用误区“DelegatingHandler 每次 HTTP 请求都会创建新实例且绝不复用”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0779 关于 请求头与上下文，以下哪项说法不成立？
难度： 实战
- A. DelegatingHandler 可添加认证、追踪等横切逻辑
- B. Handler 可能被池化跨请求复用，不能在实例字段保存某次请求的用户状态
- C. DelegatingHandler 每次 HTTP 请求都会创建新实例且绝不复用
- D. 出现“租户令牌被错误复用到另一请求”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案C
题目要求选出不成立的说法，答案“DelegatingHandler 每次 HTTP 请求都会创建新实例且绝不复用”正是 请求头与上下文 的典型误区。其余三项分别给出了主规则“DelegatingHandler 可添加认证、追踪等横切逻辑”、适用边界“Handler 可能被池化跨请求复用，不能在实例字段保存某次请求的用户状态”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0780 针对“租户令牌被错误复用到另一请求”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“DelegatingHandler 每次 HTTP 请求都会创建新实例且绝不复用”修改实现，并把一次请求成功作为验收结果。
- B. 按“DelegatingHandler 可添加认证、追踪等横切逻辑”修正实现，并用测试或遥测验证“Handler 可能被池化跨请求复用，不能在实例字段保存某次请求的用户状态”。
- C. 按“DelegatingHandler 可添加认证、追踪等横切逻辑”修改代码后直接上线，不验证“Handler 可能被池化跨请求复用，不能在实例字段保存某次请求的用户状态”。
- D. 只验证“Handler 可能被池化跨请求复用，不能在实例字段保存某次请求的用户状态”，但实现仍继续依赖“DelegatingHandler 每次 HTTP 请求都会创建新实例且绝不复用”。
查看答案与解析
正确答案B
完整决策同时覆盖规则与验证：DelegatingHandler 可添加认证、追踪等横切逻辑；并确认 Handler 可能被池化跨请求复用，不能在实例字段保存某次请求的用户状态。继续接受“DelegatingHandler 每次 HTTP 请求都会创建新实例且绝不复用”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“租户令牌被错误复用到另一请求”这一生产场景能否安全上线。