ASP.NET Core 试题 01：应用启动与 WebApplication
0001 在 WebApplication.CreateBuilder 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. CreateBuilder 只创建一个空 DI 容器且不会加载任何配置
- B. CreateBuilder 会装配配置、日志、依赖注入和常用宿主默认值
- C. 传入的命令行参数和环境变量可能覆盖较低优先级配置
- D. 观察到“应用在不同环境启动后读取到不同连接字符串”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案B
正确答案直接描述 WebApplication.CreateBuilder 的主规则：CreateBuilder 会装配配置、日志、依赖注入和常用宿主默认值。选项“传入的命令行参数和环境变量可能覆盖较低优先级配置”是使用规则时要验证的边界，不是规则本身；“CreateBuilder 只创建一个空 DI 容器且不会加载任何配置”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0002 应用在不同环境启动后读取到不同连接字符串。排查时哪项动作最合理？
难度： 进阶
- A. 先验证“传入的命令行参数和环境变量可能覆盖较低优先级配置”，再依据“CreateBuilder 会装配配置、日志、依赖注入和常用宿主默认值”判断实现是否符合契约。
- B. 直接按“CreateBuilder 只创建一个空 DI 容器且不会加载任何配置”定性，不再检查配置、身份或运行时证据。
- C. 只增加重试次数或机器资源，暂不核对“传入的命令行参数和环境变量可能覆盖较低优先级配置”。
- D. 以一次成功请求作为结论，不再确认“CreateBuilder 会装配配置、日志、依赖注入和常用宿主默认值”是否成立。
查看答案与解析
正确答案A
场景“应用在不同环境启动后读取到不同连接字符串”指向 WebApplication.CreateBuilder，但症状本身不能证明根因。正确排查应先确认边界“传入的命令行参数和环境变量可能覆盖较低优先级配置”，再用主规则“CreateBuilder 会装配配置、日志、依赖注入和常用宿主默认值”解释证据。直接采用误区“CreateBuilder 只创建一个空 DI 容器且不会加载任何配置”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0003 关于 WebApplication.CreateBuilder，以下哪项说法不成立？
难度： 实战
- A. CreateBuilder 会装配配置、日志、依赖注入和常用宿主默认值
- B. 传入的命令行参数和环境变量可能覆盖较低优先级配置
- C. 出现“应用在不同环境启动后读取到不同连接字符串”时，应收集证据并同时核对主规则与适用边界。
- D. CreateBuilder 只创建一个空 DI 容器且不会加载任何配置
查看答案与解析
正确答案D
题目要求选出不成立的说法，答案“CreateBuilder 只创建一个空 DI 容器且不会加载任何配置”正是 WebApplication.CreateBuilder 的典型误区。其余三项分别给出了主规则“CreateBuilder 会装配配置、日志、依赖注入和常用宿主默认值”、适用边界“传入的命令行参数和环境变量可能覆盖较低优先级配置”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0004 针对“应用在不同环境启动后读取到不同连接字符串”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“CreateBuilder 只创建一个空 DI 容器且不会加载任何配置”修改实现，并把一次请求成功作为验收结果。
- B. 按“CreateBuilder 会装配配置、日志、依赖注入和常用宿主默认值”修改代码后直接上线，不验证“传入的命令行参数和环境变量可能覆盖较低优先级配置”。
- C. 按“CreateBuilder 会装配配置、日志、依赖注入和常用宿主默认值”修正实现，并用测试或遥测验证“传入的命令行参数和环境变量可能覆盖较低优先级配置”。
- D. 只验证“传入的命令行参数和环境变量可能覆盖较低优先级配置”，但实现仍继续依赖“CreateBuilder 只创建一个空 DI 容器且不会加载任何配置”。
查看答案与解析
正确答案C
完整决策同时覆盖规则与验证：CreateBuilder 会装配配置、日志、依赖注入和常用宿主默认值；并确认 传入的命令行参数和环境变量可能覆盖较低优先级配置。继续接受“CreateBuilder 只创建一个空 DI 容器且不会加载任何配置”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“应用在不同环境启动后读取到不同连接字符串”这一生产场景能否安全上线。
0005 在 builder.Build 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 可以在 app.Run 之后继续向 builder.Services 注册请求所需服务
- B. Build 后不能再通过 builder.Services 添加新服务描述
- C. Build 根据已注册服务创建应用，通常应在映射管道前调用一次
- D. 观察到“某服务只在第一个请求到达后才尝试注册”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案C
正确答案直接描述 builder.Build 的主规则：Build 根据已注册服务创建应用，通常应在映射管道前调用一次。选项“Build 后不能再通过 builder.Services 添加新服务描述”是使用规则时要验证的边界，不是规则本身；“可以在 app.Run 之后继续向 builder.Services 注册请求所需服务”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0006 某服务只在第一个请求到达后才尝试注册。排查时哪项动作最合理？
难度： 进阶
- A. 先验证“Build 后不能再通过 builder.Services 添加新服务描述”，再依据“Build 根据已注册服务创建应用，通常应在映射管道前调用一次”判断实现是否符合契约。
- B. 直接按“可以在 app.Run 之后继续向 builder.Services 注册请求所需服务”定性，不再检查配置、身份或运行时证据。
- C. 只增加重试次数或机器资源，暂不核对“Build 后不能再通过 builder.Services 添加新服务描述”。
- D. 以一次成功请求作为结论，不再确认“Build 根据已注册服务创建应用，通常应在映射管道前调用一次”是否成立。
查看答案与解析
正确答案A
场景“某服务只在第一个请求到达后才尝试注册”指向 builder.Build，但症状本身不能证明根因。正确排查应先确认边界“Build 后不能再通过 builder.Services 添加新服务描述”，再用主规则“Build 根据已注册服务创建应用，通常应在映射管道前调用一次”解释证据。直接采用误区“可以在 app.Run 之后继续向 builder.Services 注册请求所需服务”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0007 关于 builder.Build，以下哪项说法不成立？
难度： 实战
- A. Build 根据已注册服务创建应用，通常应在映射管道前调用一次
- B. 可以在 app.Run 之后继续向 builder.Services 注册请求所需服务
- C. Build 后不能再通过 builder.Services 添加新服务描述
- D. 出现“某服务只在第一个请求到达后才尝试注册”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案B
题目要求选出不成立的说法，答案“可以在 app.Run 之后继续向 builder.Services 注册请求所需服务”正是 builder.Build 的典型误区。其余三项分别给出了主规则“Build 根据已注册服务创建应用，通常应在映射管道前调用一次”、适用边界“Build 后不能再通过 builder.Services 添加新服务描述”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0008 针对“某服务只在第一个请求到达后才尝试注册”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“可以在 app.Run 之后继续向 builder.Services 注册请求所需服务”修改实现，并把一次请求成功作为验收结果。
- B. 按“Build 根据已注册服务创建应用，通常应在映射管道前调用一次”修改代码后直接上线，不验证“Build 后不能再通过 builder.Services 添加新服务描述”。
- C. 只验证“Build 后不能再通过 builder.Services 添加新服务描述”，但实现仍继续依赖“可以在 app.Run 之后继续向 builder.Services 注册请求所需服务”。
- D. 按“Build 根据已注册服务创建应用，通常应在映射管道前调用一次”修正实现，并用测试或遥测验证“Build 后不能再通过 builder.Services 添加新服务描述”。
查看答案与解析
正确答案D
完整决策同时覆盖规则与验证：Build 根据已注册服务创建应用，通常应在映射管道前调用一次；并确认 Build 后不能再通过 builder.Services 添加新服务描述。继续接受“可以在 app.Run 之后继续向 builder.Services 注册请求所需服务”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“某服务只在第一个请求到达后才尝试注册”这一生产场景能否安全上线。
0009 在 WebApplication.Environment 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 只要编译为 Release，Environment 就一定是 Production
- B. 环境名应由部署配置决定，不能把 Development 当作安全边界
- C. Environment 提供环境名、内容根目录和 Web 根目录等宿主信息
- D. 观察到“生产部署意外显示开发异常页”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案C
正确答案直接描述 WebApplication.Environment 的主规则：Environment 提供环境名、内容根目录和 Web 根目录等宿主信息。选项“环境名应由部署配置决定，不能把 Development 当作安全边界”是使用规则时要验证的边界，不是规则本身；“只要编译为 Release，Environment 就一定是 Production”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0010 生产部署意外显示开发异常页。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“只要编译为 Release，Environment 就一定是 Production”定性，不再检查配置、身份或运行时证据。
- B. 只增加重试次数或机器资源，暂不核对“环境名应由部署配置决定，不能把 Development 当作安全边界”。
- C. 以一次成功请求作为结论，不再确认“Environment 提供环境名、内容根目录和 Web 根目录等宿主信息”是否成立。
- D. 先验证“环境名应由部署配置决定，不能把 Development 当作安全边界”，再依据“Environment 提供环境名、内容根目录和 Web 根目录等宿主信息”判断实现是否符合契约。
查看答案与解析
正确答案D
场景“生产部署意外显示开发异常页”指向 WebApplication.Environment，但症状本身不能证明根因。正确排查应先确认边界“环境名应由部署配置决定，不能把 Development 当作安全边界”，再用主规则“Environment 提供环境名、内容根目录和 Web 根目录等宿主信息”解释证据。直接采用误区“只要编译为 Release，Environment 就一定是 Production”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0011 关于 WebApplication.Environment，以下哪项说法不成立？
难度： 实战
- A. Environment 提供环境名、内容根目录和 Web 根目录等宿主信息
- B. 只要编译为 Release，Environment 就一定是 Production
- C. 环境名应由部署配置决定，不能把 Development 当作安全边界
- D. 出现“生产部署意外显示开发异常页”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案B
题目要求选出不成立的说法，答案“只要编译为 Release，Environment 就一定是 Production”正是 WebApplication.Environment 的典型误区。其余三项分别给出了主规则“Environment 提供环境名、内容根目录和 Web 根目录等宿主信息”、适用边界“环境名应由部署配置决定，不能把 Development 当作安全边界”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0012 针对“生产部署意外显示开发异常页”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“Environment 提供环境名、内容根目录和 Web 根目录等宿主信息”修正实现，并用测试或遥测验证“环境名应由部署配置决定，不能把 Development 当作安全边界”。
- B. 按“只要编译为 Release，Environment 就一定是 Production”修改实现，并把一次请求成功作为验收结果。
- C. 按“Environment 提供环境名、内容根目录和 Web 根目录等宿主信息”修改代码后直接上线，不验证“环境名应由部署配置决定，不能把 Development 当作安全边界”。
- D. 只验证“环境名应由部署配置决定，不能把 Development 当作安全边界”，但实现仍继续依赖“只要编译为 Release，Environment 就一定是 Production”。
查看答案与解析
正确答案A
完整决策同时覆盖规则与验证：Environment 提供环境名、内容根目录和 Web 根目录等宿主信息；并确认 环境名应由部署配置决定，不能把 Development 当作安全边界。继续接受“只要编译为 Release，Environment 就一定是 Production”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“生产部署意外显示开发异常页”这一生产场景能否安全上线。
0013 在 Map 与 Use 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 所有 MapGet 都必须写在 app.UseRouting 之前才能生效
- B. 中间件和端点映射的顺序会影响可见的 Endpoint 及执行行为
- C. 观察到“授权中间件没有对新端点执行”即可把一次现象当成完整框架契约。
- D. MapGet 等端点映射负责声明路由处理程序，Use 用于组合中间件管道
查看答案与解析
正确答案D
正确答案直接描述 Map 与 Use 的主规则：MapGet 等端点映射负责声明路由处理程序，Use 用于组合中间件管道。选项“中间件和端点映射的顺序会影响可见的 Endpoint 及执行行为”是使用规则时要验证的边界，不是规则本身；“所有 MapGet 都必须写在 app.UseRouting 之前才能生效”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0014 授权中间件没有对新端点执行。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“所有 MapGet 都必须写在 app.UseRouting 之前才能生效”定性，不再检查配置、身份或运行时证据。
- B. 只增加重试次数或机器资源，暂不核对“中间件和端点映射的顺序会影响可见的 Endpoint 及执行行为”。
- C. 先验证“中间件和端点映射的顺序会影响可见的 Endpoint 及执行行为”，再依据“MapGet 等端点映射负责声明路由处理程序，Use 用于组合中间件管道”判断实现是否符合契约。
- D. 以一次成功请求作为结论，不再确认“MapGet 等端点映射负责声明路由处理程序，Use 用于组合中间件管道”是否成立。
查看答案与解析
正确答案C
场景“授权中间件没有对新端点执行”指向 Map 与 Use，但症状本身不能证明根因。正确排查应先确认边界“中间件和端点映射的顺序会影响可见的 Endpoint 及执行行为”，再用主规则“MapGet 等端点映射负责声明路由处理程序，Use 用于组合中间件管道”解释证据。直接采用误区“所有 MapGet 都必须写在 app.UseRouting 之前才能生效”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0015 关于 Map 与 Use，以下哪项说法不成立？
难度： 实战
- A. 所有 MapGet 都必须写在 app.UseRouting 之前才能生效
- B. MapGet 等端点映射负责声明路由处理程序，Use 用于组合中间件管道
- C. 中间件和端点映射的顺序会影响可见的 Endpoint 及执行行为
- D. 出现“授权中间件没有对新端点执行”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案A
题目要求选出不成立的说法，答案“所有 MapGet 都必须写在 app.UseRouting 之前才能生效”正是 Map 与 Use 的典型误区。其余三项分别给出了主规则“MapGet 等端点映射负责声明路由处理程序，Use 用于组合中间件管道”、适用边界“中间件和端点映射的顺序会影响可见的 Endpoint 及执行行为”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0016 针对“授权中间件没有对新端点执行”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“所有 MapGet 都必须写在 app.UseRouting 之前才能生效”修改实现，并把一次请求成功作为验收结果。
- B. 按“MapGet 等端点映射负责声明路由处理程序，Use 用于组合中间件管道”修正实现，并用测试或遥测验证“中间件和端点映射的顺序会影响可见的 Endpoint 及执行行为”。
- C. 按“MapGet 等端点映射负责声明路由处理程序，Use 用于组合中间件管道”修改代码后直接上线，不验证“中间件和端点映射的顺序会影响可见的 Endpoint 及执行行为”。
- D. 只验证“中间件和端点映射的顺序会影响可见的 Endpoint 及执行行为”，但实现仍继续依赖“所有 MapGet 都必须写在 app.UseRouting 之前才能生效”。
查看答案与解析
正确答案B
完整决策同时覆盖规则与验证：MapGet 等端点映射负责声明路由处理程序，Use 用于组合中间件管道；并确认 中间件和端点映射的顺序会影响可见的 Endpoint 及执行行为。继续接受“所有 MapGet 都必须写在 app.UseRouting 之前才能生效”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“授权中间件没有对新端点执行”这一生产场景能否安全上线。
0017 在 app.Run 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. Run 启动宿主并阻塞到应用关闭；测试场景可使用 RunAsync 或 StartAsync
- B. Run 只是注册终结中间件，不会启动服务器
- C. Run 之后的普通语句在宿主停止前不会执行
- D. 观察到“启动日志打印后进程立刻退出且无监听端口”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案A
正确答案直接描述 app.Run 的主规则：Run 启动宿主并阻塞到应用关闭；测试场景可使用 RunAsync 或 StartAsync。选项“Run 之后的普通语句在宿主停止前不会执行”是使用规则时要验证的边界，不是规则本身；“Run 只是注册终结中间件，不会启动服务器”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0018 启动日志打印后进程立刻退出且无监听端口。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“Run 只是注册终结中间件，不会启动服务器”定性，不再检查配置、身份或运行时证据。
- B. 只增加重试次数或机器资源，暂不核对“Run 之后的普通语句在宿主停止前不会执行”。
- C. 先验证“Run 之后的普通语句在宿主停止前不会执行”，再依据“Run 启动宿主并阻塞到应用关闭；测试场景可使用 RunAsync 或 StartAsync”判断实现是否符合契约。
- D. 以一次成功请求作为结论，不再确认“Run 启动宿主并阻塞到应用关闭；测试场景可使用 RunAsync 或 StartAsync”是否成立。
查看答案与解析
正确答案C
场景“启动日志打印后进程立刻退出且无监听端口”指向 app.Run，但症状本身不能证明根因。正确排查应先确认边界“Run 之后的普通语句在宿主停止前不会执行”，再用主规则“Run 启动宿主并阻塞到应用关闭；测试场景可使用 RunAsync 或 StartAsync”解释证据。直接采用误区“Run 只是注册终结中间件，不会启动服务器”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0019 关于 app.Run，以下哪项说法不成立？
难度： 实战
- A. Run 启动宿主并阻塞到应用关闭；测试场景可使用 RunAsync 或 StartAsync
- B. Run 之后的普通语句在宿主停止前不会执行
- C. 出现“启动日志打印后进程立刻退出且无监听端口”时，应收集证据并同时核对主规则与适用边界。
- D. Run 只是注册终结中间件，不会启动服务器
查看答案与解析
正确答案D
题目要求选出不成立的说法，答案“Run 只是注册终结中间件，不会启动服务器”正是 app.Run 的典型误区。其余三项分别给出了主规则“Run 启动宿主并阻塞到应用关闭；测试场景可使用 RunAsync 或 StartAsync”、适用边界“Run 之后的普通语句在宿主停止前不会执行”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0020 针对“启动日志打印后进程立刻退出且无监听端口”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“Run 只是注册终结中间件，不会启动服务器”修改实现，并把一次请求成功作为验收结果。
- B. 按“Run 启动宿主并阻塞到应用关闭；测试场景可使用 RunAsync 或 StartAsync”修正实现，并用测试或遥测验证“Run 之后的普通语句在宿主停止前不会执行”。
- C. 按“Run 启动宿主并阻塞到应用关闭；测试场景可使用 RunAsync 或 StartAsync”修改代码后直接上线，不验证“Run 之后的普通语句在宿主停止前不会执行”。
- D. 只验证“Run 之后的普通语句在宿主停止前不会执行”，但实现仍继续依赖“Run 只是注册终结中间件，不会启动服务器”。
查看答案与解析
正确答案B
完整决策同时覆盖规则与验证：Run 启动宿主并阻塞到应用关闭；测试场景可使用 RunAsync 或 StartAsync；并确认 Run 之后的普通语句在宿主停止前不会执行。继续接受“Run 只是注册终结中间件，不会启动服务器”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“启动日志打印后进程立刻退出且无监听端口”这一生产场景能否安全上线。