ASP.NET Core 试题 02：Generic Host 与应用生命周期
0021 在 Generic Host 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 使用 Generic Host 后后台任务绝不会重复执行
- B. 主机负责基础设施生命周期，但不会自动保证业务操作幂等
- C. 通用主机统一管理依赖注入、日志、配置、应用生命周期和托管服务
- D. 观察到“容器重启时后台任务处理到一半”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案C
正确答案直接描述 Generic Host 的主规则：通用主机统一管理依赖注入、日志、配置、应用生命周期和托管服务。选项“主机负责基础设施生命周期，但不会自动保证业务操作幂等”是使用规则时要验证的边界，不是规则本身；“使用 Generic Host 后后台任务绝不会重复执行”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0022 容器重启时后台任务处理到一半。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“使用 Generic Host 后后台任务绝不会重复执行”定性，不再检查配置、身份或运行时证据。
- B. 先验证“主机负责基础设施生命周期，但不会自动保证业务操作幂等”，再依据“通用主机统一管理依赖注入、日志、配置、应用生命周期和托管服务”判断实现是否符合契约。
- C. 只增加重试次数或机器资源，暂不核对“主机负责基础设施生命周期，但不会自动保证业务操作幂等”。
- D. 以一次成功请求作为结论，不再确认“通用主机统一管理依赖注入、日志、配置、应用生命周期和托管服务”是否成立。
查看答案与解析
正确答案B
场景“容器重启时后台任务处理到一半”指向 Generic Host，但症状本身不能证明根因。正确排查应先确认边界“主机负责基础设施生命周期，但不会自动保证业务操作幂等”，再用主规则“通用主机统一管理依赖注入、日志、配置、应用生命周期和托管服务”解释证据。直接采用误区“使用 Generic Host 后后台任务绝不会重复执行”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0023 关于 Generic Host，以下哪项说法不成立？
难度： 实战
- A. 使用 Generic Host 后后台任务绝不会重复执行
- B. 通用主机统一管理依赖注入、日志、配置、应用生命周期和托管服务
- C. 主机负责基础设施生命周期，但不会自动保证业务操作幂等
- D. 出现“容器重启时后台任务处理到一半”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案A
题目要求选出不成立的说法，答案“使用 Generic Host 后后台任务绝不会重复执行”正是 Generic Host 的典型误区。其余三项分别给出了主规则“通用主机统一管理依赖注入、日志、配置、应用生命周期和托管服务”、适用边界“主机负责基础设施生命周期，但不会自动保证业务操作幂等”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0024 针对“容器重启时后台任务处理到一半”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“使用 Generic Host 后后台任务绝不会重复执行”修改实现，并把一次请求成功作为验收结果。
- B. 按“通用主机统一管理依赖注入、日志、配置、应用生命周期和托管服务”修改代码后直接上线，不验证“主机负责基础设施生命周期，但不会自动保证业务操作幂等”。
- C. 只验证“主机负责基础设施生命周期，但不会自动保证业务操作幂等”，但实现仍继续依赖“使用 Generic Host 后后台任务绝不会重复执行”。
- D. 按“通用主机统一管理依赖注入、日志、配置、应用生命周期和托管服务”修正实现，并用测试或遥测验证“主机负责基础设施生命周期，但不会自动保证业务操作幂等”。
查看答案与解析
正确答案D
完整决策同时覆盖规则与验证：通用主机统一管理依赖注入、日志、配置、应用生命周期和托管服务；并确认 主机负责基础设施生命周期，但不会自动保证业务操作幂等。继续接受“使用 Generic Host 后后台任务绝不会重复执行”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“容器重启时后台任务处理到一半”这一生产场景能否安全上线。
0025 在 IHostApplicationLifetime 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. ApplicationStopped 触发后仍可安全接受新 HTTP 请求
- B. Stopping 回调应快速、可取消，不能假设拥有无限清理时间
- C. 观察到“优雅停机期间需要停止拉取新消息”即可把一次现象当成完整框架契约。
- D. 该接口暴露 ApplicationStarted、Stopping 和 Stopped 取消令牌
查看答案与解析
正确答案D
正确答案直接描述 IHostApplicationLifetime 的主规则：该接口暴露 ApplicationStarted、Stopping 和 Stopped 取消令牌。选项“Stopping 回调应快速、可取消，不能假设拥有无限清理时间”是使用规则时要验证的边界，不是规则本身；“ApplicationStopped 触发后仍可安全接受新 HTTP 请求”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0026 优雅停机期间需要停止拉取新消息。排查时哪项动作最合理？
难度： 进阶
- A. 先验证“Stopping 回调应快速、可取消，不能假设拥有无限清理时间”，再依据“该接口暴露 ApplicationStarted、Stopping 和 Stopped 取消令牌”判断实现是否符合契约。
- B. 直接按“ApplicationStopped 触发后仍可安全接受新 HTTP 请求”定性，不再检查配置、身份或运行时证据。
- C. 只增加重试次数或机器资源，暂不核对“Stopping 回调应快速、可取消，不能假设拥有无限清理时间”。
- D. 以一次成功请求作为结论，不再确认“该接口暴露 ApplicationStarted、Stopping 和 Stopped 取消令牌”是否成立。
查看答案与解析
正确答案A
场景“优雅停机期间需要停止拉取新消息”指向 IHostApplicationLifetime，但症状本身不能证明根因。正确排查应先确认边界“Stopping 回调应快速、可取消，不能假设拥有无限清理时间”，再用主规则“该接口暴露 ApplicationStarted、Stopping 和 Stopped 取消令牌”解释证据。直接采用误区“ApplicationStopped 触发后仍可安全接受新 HTTP 请求”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0027 关于 IHostApplicationLifetime，以下哪项说法不成立？
难度： 实战
- A. 该接口暴露 ApplicationStarted、Stopping 和 Stopped 取消令牌
- B. Stopping 回调应快速、可取消，不能假设拥有无限清理时间
- C. ApplicationStopped 触发后仍可安全接受新 HTTP 请求
- D. 出现“优雅停机期间需要停止拉取新消息”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案C
题目要求选出不成立的说法，答案“ApplicationStopped 触发后仍可安全接受新 HTTP 请求”正是 IHostApplicationLifetime 的典型误区。其余三项分别给出了主规则“该接口暴露 ApplicationStarted、Stopping 和 Stopped 取消令牌”、适用边界“Stopping 回调应快速、可取消，不能假设拥有无限清理时间”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0028 针对“优雅停机期间需要停止拉取新消息”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“ApplicationStopped 触发后仍可安全接受新 HTTP 请求”修改实现，并把一次请求成功作为验收结果。
- B. 按“该接口暴露 ApplicationStarted、Stopping 和 Stopped 取消令牌”修正实现，并用测试或遥测验证“Stopping 回调应快速、可取消，不能假设拥有无限清理时间”。
- C. 按“该接口暴露 ApplicationStarted、Stopping 和 Stopped 取消令牌”修改代码后直接上线，不验证“Stopping 回调应快速、可取消，不能假设拥有无限清理时间”。
- D. 只验证“Stopping 回调应快速、可取消，不能假设拥有无限清理时间”，但实现仍继续依赖“ApplicationStopped 触发后仍可安全接受新 HTTP 请求”。
查看答案与解析
正确答案B
完整决策同时覆盖规则与验证：该接口暴露 ApplicationStarted、Stopping 和 Stopped 取消令牌；并确认 Stopping 回调应快速、可取消，不能假设拥有无限清理时间。继续接受“ApplicationStopped 触发后仍可安全接受新 HTTP 请求”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“优雅停机期间需要停止拉取新消息”这一生产场景能否安全上线。
0029 在 HostOptions.ShutdownTimeout 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. ShutdownTimeout 限制主机等待托管服务停止的时间
- B. 增大 ShutdownTimeout 会让所有未完成业务必然成功提交
- C. 超时只是等待上限，业务仍需正确响应 CancellationToken
- D. 观察到“发布时旧实例长期无法退出”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案A
正确答案直接描述 HostOptions.ShutdownTimeout 的主规则：ShutdownTimeout 限制主机等待托管服务停止的时间。选项“超时只是等待上限，业务仍需正确响应 CancellationToken”是使用规则时要验证的边界，不是规则本身；“增大 ShutdownTimeout 会让所有未完成业务必然成功提交”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0030 发布时旧实例长期无法退出。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“增大 ShutdownTimeout 会让所有未完成业务必然成功提交”定性，不再检查配置、身份或运行时证据。
- B. 先验证“超时只是等待上限，业务仍需正确响应 CancellationToken”，再依据“ShutdownTimeout 限制主机等待托管服务停止的时间”判断实现是否符合契约。
- C. 只增加重试次数或机器资源，暂不核对“超时只是等待上限，业务仍需正确响应 CancellationToken”。
- D. 以一次成功请求作为结论，不再确认“ShutdownTimeout 限制主机等待托管服务停止的时间”是否成立。
查看答案与解析
正确答案B
场景“发布时旧实例长期无法退出”指向 HostOptions.ShutdownTimeout，但症状本身不能证明根因。正确排查应先确认边界“超时只是等待上限，业务仍需正确响应 CancellationToken”，再用主规则“ShutdownTimeout 限制主机等待托管服务停止的时间”解释证据。直接采用误区“增大 ShutdownTimeout 会让所有未完成业务必然成功提交”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0031 关于 HostOptions.ShutdownTimeout，以下哪项说法不成立？
难度： 实战
- A. ShutdownTimeout 限制主机等待托管服务停止的时间
- B. 超时只是等待上限，业务仍需正确响应 CancellationToken
- C. 增大 ShutdownTimeout 会让所有未完成业务必然成功提交
- D. 出现“发布时旧实例长期无法退出”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案C
题目要求选出不成立的说法，答案“增大 ShutdownTimeout 会让所有未完成业务必然成功提交”正是 HostOptions.ShutdownTimeout 的典型误区。其余三项分别给出了主规则“ShutdownTimeout 限制主机等待托管服务停止的时间”、适用边界“超时只是等待上限，业务仍需正确响应 CancellationToken”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0032 针对“发布时旧实例长期无法退出”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“增大 ShutdownTimeout 会让所有未完成业务必然成功提交”修改实现，并把一次请求成功作为验收结果。
- B. 按“ShutdownTimeout 限制主机等待托管服务停止的时间”修改代码后直接上线，不验证“超时只是等待上限，业务仍需正确响应 CancellationToken”。
- C. 只验证“超时只是等待上限，业务仍需正确响应 CancellationToken”，但实现仍继续依赖“增大 ShutdownTimeout 会让所有未完成业务必然成功提交”。
- D. 按“ShutdownTimeout 限制主机等待托管服务停止的时间”修正实现，并用测试或遥测验证“超时只是等待上限，业务仍需正确响应 CancellationToken”。
查看答案与解析
正确答案D
完整决策同时覆盖规则与验证：ShutdownTimeout 限制主机等待托管服务停止的时间；并确认 超时只是等待上限，业务仍需正确响应 CancellationToken。继续接受“增大 ShutdownTimeout 会让所有未完成业务必然成功提交”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“发布时旧实例长期无法退出”这一生产场景能否安全上线。
0033 在 内容根目录 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 内容根目录用于解析应用内容文件，默认值由宿主构建方式和启动位置决定
- B. 相对路径总是以程序集文件所在目录解析
- C. 容器或服务启动目录可能不同，关键路径应基于 ContentRootPath 或绝对配置
- D. 观察到“本地能读取模板而容器中找不到文件”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案A
正确答案直接描述 内容根目录 的主规则：内容根目录用于解析应用内容文件，默认值由宿主构建方式和启动位置决定。选项“容器或服务启动目录可能不同，关键路径应基于 ContentRootPath 或绝对配置”是使用规则时要验证的边界，不是规则本身；“相对路径总是以程序集文件所在目录解析”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0034 本地能读取模板而容器中找不到文件。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“相对路径总是以程序集文件所在目录解析”定性，不再检查配置、身份或运行时证据。
- B. 只增加重试次数或机器资源，暂不核对“容器或服务启动目录可能不同，关键路径应基于 ContentRootPath 或绝对配置”。
- C. 以一次成功请求作为结论，不再确认“内容根目录用于解析应用内容文件，默认值由宿主构建方式和启动位置决定”是否成立。
- D. 先验证“容器或服务启动目录可能不同，关键路径应基于 ContentRootPath 或绝对配置”，再依据“内容根目录用于解析应用内容文件，默认值由宿主构建方式和启动位置决定”判断实现是否符合契约。
查看答案与解析
正确答案D
场景“本地能读取模板而容器中找不到文件”指向 内容根目录，但症状本身不能证明根因。正确排查应先确认边界“容器或服务启动目录可能不同，关键路径应基于 ContentRootPath 或绝对配置”，再用主规则“内容根目录用于解析应用内容文件，默认值由宿主构建方式和启动位置决定”解释证据。直接采用误区“相对路径总是以程序集文件所在目录解析”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0035 关于 内容根目录，以下哪项说法不成立？
难度： 实战
- A. 内容根目录用于解析应用内容文件，默认值由宿主构建方式和启动位置决定
- B. 容器或服务启动目录可能不同，关键路径应基于 ContentRootPath 或绝对配置
- C. 相对路径总是以程序集文件所在目录解析
- D. 出现“本地能读取模板而容器中找不到文件”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案C
题目要求选出不成立的说法，答案“相对路径总是以程序集文件所在目录解析”正是 内容根目录 的典型误区。其余三项分别给出了主规则“内容根目录用于解析应用内容文件，默认值由宿主构建方式和启动位置决定”、适用边界“容器或服务启动目录可能不同，关键路径应基于 ContentRootPath 或绝对配置”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0036 针对“本地能读取模板而容器中找不到文件”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“相对路径总是以程序集文件所在目录解析”修改实现，并把一次请求成功作为验收结果。
- B. 按“内容根目录用于解析应用内容文件，默认值由宿主构建方式和启动位置决定”修正实现，并用测试或遥测验证“容器或服务启动目录可能不同，关键路径应基于 ContentRootPath 或绝对配置”。
- C. 按“内容根目录用于解析应用内容文件，默认值由宿主构建方式和启动位置决定”修改代码后直接上线，不验证“容器或服务启动目录可能不同，关键路径应基于 ContentRootPath 或绝对配置”。
- D. 只验证“容器或服务启动目录可能不同，关键路径应基于 ContentRootPath 或绝对配置”，但实现仍继续依赖“相对路径总是以程序集文件所在目录解析”。
查看答案与解析
正确答案B
完整决策同时覆盖规则与验证：内容根目录用于解析应用内容文件，默认值由宿主构建方式和启动位置决定；并确认 容器或服务启动目录可能不同，关键路径应基于 ContentRootPath 或绝对配置。继续接受“相对路径总是以程序集文件所在目录解析”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“本地能读取模板而容器中找不到文件”这一生产场景能否安全上线。
0037 在 主机配置与应用配置 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 所有配置源优先级固定且无法被应用调整
- B. 宿主关键配置先确定环境和内容根，应用配置随后合并更多提供程序
- C. 同名键最终值取决于提供程序顺序和实际来源
- D. 观察到“命令行参数没有覆盖 JSON 中的端口”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案B
正确答案直接描述 主机配置与应用配置 的主规则：宿主关键配置先确定环境和内容根，应用配置随后合并更多提供程序。选项“同名键最终值取决于提供程序顺序和实际来源”是使用规则时要验证的边界，不是规则本身；“所有配置源优先级固定且无法被应用调整”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0038 命令行参数没有覆盖 JSON 中的端口。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“所有配置源优先级固定且无法被应用调整”定性，不再检查配置、身份或运行时证据。
- B. 只增加重试次数或机器资源，暂不核对“同名键最终值取决于提供程序顺序和实际来源”。
- C. 以一次成功请求作为结论，不再确认“宿主关键配置先确定环境和内容根，应用配置随后合并更多提供程序”是否成立。
- D. 先验证“同名键最终值取决于提供程序顺序和实际来源”，再依据“宿主关键配置先确定环境和内容根，应用配置随后合并更多提供程序”判断实现是否符合契约。
查看答案与解析
正确答案D
场景“命令行参数没有覆盖 JSON 中的端口”指向 主机配置与应用配置，但症状本身不能证明根因。正确排查应先确认边界“同名键最终值取决于提供程序顺序和实际来源”，再用主规则“宿主关键配置先确定环境和内容根，应用配置随后合并更多提供程序”解释证据。直接采用误区“所有配置源优先级固定且无法被应用调整”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0039 关于 主机配置与应用配置，以下哪项说法不成立？
难度： 实战
- A. 所有配置源优先级固定且无法被应用调整
- B. 宿主关键配置先确定环境和内容根，应用配置随后合并更多提供程序
- C. 同名键最终值取决于提供程序顺序和实际来源
- D. 出现“命令行参数没有覆盖 JSON 中的端口”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案A
题目要求选出不成立的说法，答案“所有配置源优先级固定且无法被应用调整”正是 主机配置与应用配置 的典型误区。其余三项分别给出了主规则“宿主关键配置先确定环境和内容根，应用配置随后合并更多提供程序”、适用边界“同名键最终值取决于提供程序顺序和实际来源”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0040 针对“命令行参数没有覆盖 JSON 中的端口”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“所有配置源优先级固定且无法被应用调整”修改实现，并把一次请求成功作为验收结果。
- B. 按“宿主关键配置先确定环境和内容根，应用配置随后合并更多提供程序”修改代码后直接上线，不验证“同名键最终值取决于提供程序顺序和实际来源”。
- C. 按“宿主关键配置先确定环境和内容根，应用配置随后合并更多提供程序”修正实现，并用测试或遥测验证“同名键最终值取决于提供程序顺序和实际来源”。
- D. 只验证“同名键最终值取决于提供程序顺序和实际来源”，但实现仍继续依赖“所有配置源优先级固定且无法被应用调整”。
查看答案与解析
正确答案C
完整决策同时覆盖规则与验证：宿主关键配置先确定环境和内容根，应用配置随后合并更多提供程序；并确认 同名键最终值取决于提供程序顺序和实际来源。继续接受“所有配置源优先级固定且无法被应用调整”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“命令行参数没有覆盖 JSON 中的端口”这一生产场景能否安全上线。