ASP.NET Core 试题 38：后台服务
0741 在 BackgroundService 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. BackgroundService.ExecuteAsync 表示服务的长期工作，宿主停止时会传入取消信号
- B. ExecuteAsync 返回后宿主会自动重新启动该服务
- C. 实现应观察 stoppingToken，捕获预期异常并避免无界循环吞噬资源
- D. 观察到“后台循环意外退出后任务不再执行”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案A
正确答案直接描述 BackgroundService 的主规则：BackgroundService.ExecuteAsync 表示服务的长期工作，宿主停止时会传入取消信号。选项“实现应观察 stoppingToken，捕获预期异常并避免无界循环吞噬资源”是使用规则时要验证的边界，不是规则本身；“ExecuteAsync 返回后宿主会自动重新启动该服务”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0742 后台循环意外退出后任务不再执行。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“ExecuteAsync 返回后宿主会自动重新启动该服务”定性，不再检查配置、身份或运行时证据。
- B. 只增加重试次数或机器资源，暂不核对“实现应观察 stoppingToken，捕获预期异常并避免无界循环吞噬资源”。
- C. 先验证“实现应观察 stoppingToken，捕获预期异常并避免无界循环吞噬资源”，再依据“BackgroundService.ExecuteAsync 表示服务的长期工作，宿主停止时会传入取消信号”判断实现是否符合契约。
- D. 以一次成功请求作为结论，不再确认“BackgroundService.ExecuteAsync 表示服务的长期工作，宿主停止时会传入取消信号”是否成立。
查看答案与解析
正确答案C
场景“后台循环意外退出后任务不再执行”指向 BackgroundService，但症状本身不能证明根因。正确排查应先确认边界“实现应观察 stoppingToken，捕获预期异常并避免无界循环吞噬资源”，再用主规则“BackgroundService.ExecuteAsync 表示服务的长期工作，宿主停止时会传入取消信号”解释证据。直接采用误区“ExecuteAsync 返回后宿主会自动重新启动该服务”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0743 关于 BackgroundService，以下哪项说法不成立？
难度： 实战
- A. BackgroundService.ExecuteAsync 表示服务的长期工作，宿主停止时会传入取消信号
- B. ExecuteAsync 返回后宿主会自动重新启动该服务
- C. 实现应观察 stoppingToken，捕获预期异常并避免无界循环吞噬资源
- D. 出现“后台循环意外退出后任务不再执行”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案B
题目要求选出不成立的说法，答案“ExecuteAsync 返回后宿主会自动重新启动该服务”正是 BackgroundService 的典型误区。其余三项分别给出了主规则“BackgroundService.ExecuteAsync 表示服务的长期工作，宿主停止时会传入取消信号”、适用边界“实现应观察 stoppingToken，捕获预期异常并避免无界循环吞噬资源”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0744 针对“后台循环意外退出后任务不再执行”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“ExecuteAsync 返回后宿主会自动重新启动该服务”修改实现，并把一次请求成功作为验收结果。
- B. 按“BackgroundService.ExecuteAsync 表示服务的长期工作，宿主停止时会传入取消信号”修改代码后直接上线，不验证“实现应观察 stoppingToken，捕获预期异常并避免无界循环吞噬资源”。
- C. 只验证“实现应观察 stoppingToken，捕获预期异常并避免无界循环吞噬资源”，但实现仍继续依赖“ExecuteAsync 返回后宿主会自动重新启动该服务”。
- D. 按“BackgroundService.ExecuteAsync 表示服务的长期工作，宿主停止时会传入取消信号”修正实现，并用测试或遥测验证“实现应观察 stoppingToken，捕获预期异常并避免无界循环吞噬资源”。
查看答案与解析
正确答案D
完整决策同时覆盖规则与验证：BackgroundService.ExecuteAsync 表示服务的长期工作，宿主停止时会传入取消信号；并确认 实现应观察 stoppingToken，捕获预期异常并避免无界循环吞噬资源。继续接受“ExecuteAsync 返回后宿主会自动重新启动该服务”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“后台循环意外退出后任务不再执行”这一生产场景能否安全上线。
0745 在 启动与停止 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. StartAsync 中同步执行十分钟初始化不会影响 HTTP 启动
- B. IHostedService.StartAsync 应快速完成启动，StopAsync 用于协作式停止
- C. 多个托管服务启动可能是顺序的，长阻塞初始化会延迟整个应用就绪
- D. 观察到“部署健康检查长期无法通过”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案B
正确答案直接描述 启动与停止 的主规则：IHostedService.StartAsync 应快速完成启动，StopAsync 用于协作式停止。选项“多个托管服务启动可能是顺序的，长阻塞初始化会延迟整个应用就绪”是使用规则时要验证的边界，不是规则本身；“StartAsync 中同步执行十分钟初始化不会影响 HTTP 启动”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0746 部署健康检查长期无法通过。排查时哪项动作最合理？
难度： 进阶
- A. 先验证“多个托管服务启动可能是顺序的，长阻塞初始化会延迟整个应用就绪”，再依据“IHostedService.StartAsync 应快速完成启动，StopAsync 用于协作式停止”判断实现是否符合契约。
- B. 直接按“StartAsync 中同步执行十分钟初始化不会影响 HTTP 启动”定性，不再检查配置、身份或运行时证据。
- C. 只增加重试次数或机器资源，暂不核对“多个托管服务启动可能是顺序的，长阻塞初始化会延迟整个应用就绪”。
- D. 以一次成功请求作为结论，不再确认“IHostedService.StartAsync 应快速完成启动，StopAsync 用于协作式停止”是否成立。
查看答案与解析
正确答案A
场景“部署健康检查长期无法通过”指向 启动与停止，但症状本身不能证明根因。正确排查应先确认边界“多个托管服务启动可能是顺序的，长阻塞初始化会延迟整个应用就绪”，再用主规则“IHostedService.StartAsync 应快速完成启动，StopAsync 用于协作式停止”解释证据。直接采用误区“StartAsync 中同步执行十分钟初始化不会影响 HTTP 启动”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0747 关于 启动与停止，以下哪项说法不成立？
难度： 实战
- A. IHostedService.StartAsync 应快速完成启动，StopAsync 用于协作式停止
- B. 多个托管服务启动可能是顺序的，长阻塞初始化会延迟整个应用就绪
- C. 出现“部署健康检查长期无法通过”时，应收集证据并同时核对主规则与适用边界。
- D. StartAsync 中同步执行十分钟初始化不会影响 HTTP 启动
查看答案与解析
正确答案D
题目要求选出不成立的说法，答案“StartAsync 中同步执行十分钟初始化不会影响 HTTP 启动”正是 启动与停止 的典型误区。其余三项分别给出了主规则“IHostedService.StartAsync 应快速完成启动，StopAsync 用于协作式停止”、适用边界“多个托管服务启动可能是顺序的，长阻塞初始化会延迟整个应用就绪”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0748 针对“部署健康检查长期无法通过”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“StartAsync 中同步执行十分钟初始化不会影响 HTTP 启动”修改实现，并把一次请求成功作为验收结果。
- B. 按“IHostedService.StartAsync 应快速完成启动，StopAsync 用于协作式停止”修改代码后直接上线，不验证“多个托管服务启动可能是顺序的，长阻塞初始化会延迟整个应用就绪”。
- C. 按“IHostedService.StartAsync 应快速完成启动，StopAsync 用于协作式停止”修正实现，并用测试或遥测验证“多个托管服务启动可能是顺序的，长阻塞初始化会延迟整个应用就绪”。
- D. 只验证“多个托管服务启动可能是顺序的，长阻塞初始化会延迟整个应用就绪”，但实现仍继续依赖“StartAsync 中同步执行十分钟初始化不会影响 HTTP 启动”。
查看答案与解析
正确答案C
完整决策同时覆盖规则与验证：IHostedService.StartAsync 应快速完成启动，StopAsync 用于协作式停止；并确认 多个托管服务启动可能是顺序的，长阻塞初始化会延迟整个应用就绪。继续接受“StartAsync 中同步执行十分钟初始化不会影响 HTTP 启动”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“部署健康检查长期无法通过”这一生产场景能否安全上线。
0749 在 后台作用域 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 把 Scoped 服务注入 BackgroundService 构造函数会自动每轮刷新实例
- B. 作用域要及时释放，不能跨并行任务共享同一 DbContext
- C. 托管服务通常是 Singleton，使用 DbContext 等 Scoped 服务要每个工作单元创建作用域
- D. 观察到“并发任务共享 DbContext 抛出线程安全错误”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案C
正确答案直接描述 后台作用域 的主规则：托管服务通常是 Singleton，使用 DbContext 等 Scoped 服务要每个工作单元创建作用域。选项“作用域要及时释放，不能跨并行任务共享同一 DbContext”是使用规则时要验证的边界，不是规则本身；“把 Scoped 服务注入 BackgroundService 构造函数会自动每轮刷新实例”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0750 并发任务共享 DbContext 抛出线程安全错误。排查时哪项动作最合理？
难度： 进阶
- A. 先验证“作用域要及时释放，不能跨并行任务共享同一 DbContext”，再依据“托管服务通常是 Singleton，使用 DbContext 等 Scoped 服务要每个工作单元创建作用域”判断实现是否符合契约。
- B. 直接按“把 Scoped 服务注入 BackgroundService 构造函数会自动每轮刷新实例”定性，不再检查配置、身份或运行时证据。
- C. 只增加重试次数或机器资源，暂不核对“作用域要及时释放，不能跨并行任务共享同一 DbContext”。
- D. 以一次成功请求作为结论，不再确认“托管服务通常是 Singleton，使用 DbContext 等 Scoped 服务要每个工作单元创建作用域”是否成立。
查看答案与解析
正确答案A
场景“并发任务共享 DbContext 抛出线程安全错误”指向 后台作用域，但症状本身不能证明根因。正确排查应先确认边界“作用域要及时释放，不能跨并行任务共享同一 DbContext”，再用主规则“托管服务通常是 Singleton，使用 DbContext 等 Scoped 服务要每个工作单元创建作用域”解释证据。直接采用误区“把 Scoped 服务注入 BackgroundService 构造函数会自动每轮刷新实例”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0751 关于 后台作用域，以下哪项说法不成立？
难度： 实战
- A. 托管服务通常是 Singleton，使用 DbContext 等 Scoped 服务要每个工作单元创建作用域
- B. 把 Scoped 服务注入 BackgroundService 构造函数会自动每轮刷新实例
- C. 作用域要及时释放，不能跨并行任务共享同一 DbContext
- D. 出现“并发任务共享 DbContext 抛出线程安全错误”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案B
题目要求选出不成立的说法，答案“把 Scoped 服务注入 BackgroundService 构造函数会自动每轮刷新实例”正是 后台作用域 的典型误区。其余三项分别给出了主规则“托管服务通常是 Singleton，使用 DbContext 等 Scoped 服务要每个工作单元创建作用域”、适用边界“作用域要及时释放，不能跨并行任务共享同一 DbContext”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0752 针对“并发任务共享 DbContext 抛出线程安全错误”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“把 Scoped 服务注入 BackgroundService 构造函数会自动每轮刷新实例”修改实现，并把一次请求成功作为验收结果。
- B. 按“托管服务通常是 Singleton，使用 DbContext 等 Scoped 服务要每个工作单元创建作用域”修改代码后直接上线，不验证“作用域要及时释放，不能跨并行任务共享同一 DbContext”。
- C. 只验证“作用域要及时释放，不能跨并行任务共享同一 DbContext”，但实现仍继续依赖“把 Scoped 服务注入 BackgroundService 构造函数会自动每轮刷新实例”。
- D. 按“托管服务通常是 Singleton，使用 DbContext 等 Scoped 服务要每个工作单元创建作用域”修正实现，并用测试或遥测验证“作用域要及时释放，不能跨并行任务共享同一 DbContext”。
查看答案与解析
正确答案D
完整决策同时覆盖规则与验证：托管服务通常是 Singleton，使用 DbContext 等 Scoped 服务要每个工作单元创建作用域；并确认 作用域要及时释放，不能跨并行任务共享同一 DbContext。继续接受“把 Scoped 服务注入 BackgroundService 构造函数会自动每轮刷新实例”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“并发任务共享 DbContext 抛出线程安全错误”这一生产场景能否安全上线。
0753 在 周期执行 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. PeriodicTimer 的实际间隔永远是任务耗时加 Period
- B. 它按时间节奏发出 tick，不等同于每次工作完成后再 Delay；长任务可能消费已到达的 tick
- C. PeriodicTimer 可按周期产生 tick，并天然避免同一计时器多个并发等待者
- D. 观察到“任务耗时超过周期后下一轮立即开始”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案C
正确答案直接描述 周期执行 的主规则：PeriodicTimer 可按周期产生 tick，并天然避免同一计时器多个并发等待者。选项“它按时间节奏发出 tick，不等同于每次工作完成后再 Delay；长任务可能消费已到达的 tick”是使用规则时要验证的边界，不是规则本身；“PeriodicTimer 的实际间隔永远是任务耗时加 Period”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0754 任务耗时超过周期后下一轮立即开始。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“PeriodicTimer 的实际间隔永远是任务耗时加 Period”定性，不再检查配置、身份或运行时证据。
- B. 只增加重试次数或机器资源，暂不核对“它按时间节奏发出 tick，不等同于每次工作完成后再 Delay；长任务可能消费已到达的 tick”。
- C. 以一次成功请求作为结论，不再确认“PeriodicTimer 可按周期产生 tick，并天然避免同一计时器多个并发等待者”是否成立。
- D. 先验证“它按时间节奏发出 tick，不等同于每次工作完成后再 Delay；长任务可能消费已到达的 tick”，再依据“PeriodicTimer 可按周期产生 tick，并天然避免同一计时器多个并发等待者”判断实现是否符合契约。
查看答案与解析
正确答案D
场景“任务耗时超过周期后下一轮立即开始”指向 周期执行，但症状本身不能证明根因。正确排查应先确认边界“它按时间节奏发出 tick，不等同于每次工作完成后再 Delay；长任务可能消费已到达的 tick”，再用主规则“PeriodicTimer 可按周期产生 tick，并天然避免同一计时器多个并发等待者”解释证据。直接采用误区“PeriodicTimer 的实际间隔永远是任务耗时加 Period”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0755 关于 周期执行，以下哪项说法不成立？
难度： 实战
- A. PeriodicTimer 可按周期产生 tick，并天然避免同一计时器多个并发等待者
- B. PeriodicTimer 的实际间隔永远是任务耗时加 Period
- C. 它按时间节奏发出 tick，不等同于每次工作完成后再 Delay；长任务可能消费已到达的 tick
- D. 出现“任务耗时超过周期后下一轮立即开始”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案B
题目要求选出不成立的说法，答案“PeriodicTimer 的实际间隔永远是任务耗时加 Period”正是 周期执行 的典型误区。其余三项分别给出了主规则“PeriodicTimer 可按周期产生 tick，并天然避免同一计时器多个并发等待者”、适用边界“它按时间节奏发出 tick，不等同于每次工作完成后再 Delay；长任务可能消费已到达的 tick”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0756 针对“任务耗时超过周期后下一轮立即开始”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“PeriodicTimer 可按周期产生 tick，并天然避免同一计时器多个并发等待者”修正实现，并用测试或遥测验证“它按时间节奏发出 tick，不等同于每次工作完成后再 Delay；长任务可能消费已到达的 tick”。
- B. 按“PeriodicTimer 的实际间隔永远是任务耗时加 Period”修改实现，并把一次请求成功作为验收结果。
- C. 按“PeriodicTimer 可按周期产生 tick，并天然避免同一计时器多个并发等待者”修改代码后直接上线，不验证“它按时间节奏发出 tick，不等同于每次工作完成后再 Delay；长任务可能消费已到达的 tick”。
- D. 只验证“它按时间节奏发出 tick，不等同于每次工作完成后再 Delay；长任务可能消费已到达的 tick”，但实现仍继续依赖“PeriodicTimer 的实际间隔永远是任务耗时加 Period”。
查看答案与解析
正确答案A
完整决策同时覆盖规则与验证：PeriodicTimer 可按周期产生 tick，并天然避免同一计时器多个并发等待者；并确认 它按时间节奏发出 tick，不等同于每次工作完成后再 Delay；长任务可能消费已到达的 tick。继续接受“PeriodicTimer 的实际间隔永远是任务耗时加 Period”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“任务耗时超过周期后下一轮立即开始”这一生产场景能否安全上线。
0757 在 后台队列 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 内存 Channel 会在进程重启后自动恢复未处理消息
- B. 必须定义容量满时等待、丢弃或拒绝策略，并处理重启后的持久性需求
- C. 观察到“突发任务填满内存并在重启时全部丢失”即可把一次现象当成完整框架契约。
- D. 有界 Channel 可实现生产者与 BackgroundService 消费者之间的背压
查看答案与解析
正确答案D
正确答案直接描述 后台队列 的主规则：有界 Channel 可实现生产者与 BackgroundService 消费者之间的背压。选项“必须定义容量满时等待、丢弃或拒绝策略，并处理重启后的持久性需求”是使用规则时要验证的边界，不是规则本身；“内存 Channel 会在进程重启后自动恢复未处理消息”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0758 突发任务填满内存并在重启时全部丢失。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“内存 Channel 会在进程重启后自动恢复未处理消息”定性，不再检查配置、身份或运行时证据。
- B. 只增加重试次数或机器资源，暂不核对“必须定义容量满时等待、丢弃或拒绝策略，并处理重启后的持久性需求”。
- C. 先验证“必须定义容量满时等待、丢弃或拒绝策略，并处理重启后的持久性需求”，再依据“有界 Channel 可实现生产者与 BackgroundService 消费者之间的背压”判断实现是否符合契约。
- D. 以一次成功请求作为结论，不再确认“有界 Channel 可实现生产者与 BackgroundService 消费者之间的背压”是否成立。
查看答案与解析
正确答案C
场景“突发任务填满内存并在重启时全部丢失”指向 后台队列，但症状本身不能证明根因。正确排查应先确认边界“必须定义容量满时等待、丢弃或拒绝策略，并处理重启后的持久性需求”，再用主规则“有界 Channel 可实现生产者与 BackgroundService 消费者之间的背压”解释证据。直接采用误区“内存 Channel 会在进程重启后自动恢复未处理消息”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0759 关于 后台队列，以下哪项说法不成立？
难度： 实战
- A. 内存 Channel 会在进程重启后自动恢复未处理消息
- B. 有界 Channel 可实现生产者与 BackgroundService 消费者之间的背压
- C. 必须定义容量满时等待、丢弃或拒绝策略，并处理重启后的持久性需求
- D. 出现“突发任务填满内存并在重启时全部丢失”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案A
题目要求选出不成立的说法，答案“内存 Channel 会在进程重启后自动恢复未处理消息”正是 后台队列 的典型误区。其余三项分别给出了主规则“有界 Channel 可实现生产者与 BackgroundService 消费者之间的背压”、适用边界“必须定义容量满时等待、丢弃或拒绝策略，并处理重启后的持久性需求”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0760 针对“突发任务填满内存并在重启时全部丢失”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“内存 Channel 会在进程重启后自动恢复未处理消息”修改实现，并把一次请求成功作为验收结果。
- B. 按“有界 Channel 可实现生产者与 BackgroundService 消费者之间的背压”修正实现，并用测试或遥测验证“必须定义容量满时等待、丢弃或拒绝策略，并处理重启后的持久性需求”。
- C. 按“有界 Channel 可实现生产者与 BackgroundService 消费者之间的背压”修改代码后直接上线，不验证“必须定义容量满时等待、丢弃或拒绝策略，并处理重启后的持久性需求”。
- D. 只验证“必须定义容量满时等待、丢弃或拒绝策略，并处理重启后的持久性需求”，但实现仍继续依赖“内存 Channel 会在进程重启后自动恢复未处理消息”。
查看答案与解析
正确答案B
完整决策同时覆盖规则与验证：有界 Channel 可实现生产者与 BackgroundService 消费者之间的背压；并确认 必须定义容量满时等待、丢弃或拒绝策略，并处理重启后的持久性需求。继续接受“内存 Channel 会在进程重启后自动恢复未处理消息”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“突发任务填满内存并在重启时全部丢失”这一生产场景能否安全上线。