ASP.NET Core 试题 17：Controller 与 Action
0321 在 控制器激活 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 同一个 Controller 实例默认服务所有并发请求
- B. 控制器应保持无状态且轻量，不能依赖实例跨请求保存会话数据
- C. 观察到“控制器字段中的当前用户数据串到其他请求”即可把一次现象当成完整框架契约。
- D. 控制器通常由 DI 激活，可通过构造函数声明应用服务依赖
查看答案与解析
正确答案D
正确答案直接描述 控制器激活 的主规则：控制器通常由 DI 激活，可通过构造函数声明应用服务依赖。选项“控制器应保持无状态且轻量，不能依赖实例跨请求保存会话数据”是使用规则时要验证的边界，不是规则本身；“同一个 Controller 实例默认服务所有并发请求”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0322 控制器字段中的当前用户数据串到其他请求。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“同一个 Controller 实例默认服务所有并发请求”定性，不再检查配置、身份或运行时证据。
- B. 只增加重试次数或机器资源，暂不核对“控制器应保持无状态且轻量，不能依赖实例跨请求保存会话数据”。
- C. 先验证“控制器应保持无状态且轻量，不能依赖实例跨请求保存会话数据”，再依据“控制器通常由 DI 激活，可通过构造函数声明应用服务依赖”判断实现是否符合契约。
- D. 以一次成功请求作为结论，不再确认“控制器通常由 DI 激活，可通过构造函数声明应用服务依赖”是否成立。
查看答案与解析
正确答案C
场景“控制器字段中的当前用户数据串到其他请求”指向 控制器激活，但症状本身不能证明根因。正确排查应先确认边界“控制器应保持无状态且轻量，不能依赖实例跨请求保存会话数据”，再用主规则“控制器通常由 DI 激活，可通过构造函数声明应用服务依赖”解释证据。直接采用误区“同一个 Controller 实例默认服务所有并发请求”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0323 关于 控制器激活，以下哪项说法不成立？
难度： 实战
- A. 控制器通常由 DI 激活，可通过构造函数声明应用服务依赖
- B. 同一个 Controller 实例默认服务所有并发请求
- C. 控制器应保持无状态且轻量，不能依赖实例跨请求保存会话数据
- D. 出现“控制器字段中的当前用户数据串到其他请求”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案B
题目要求选出不成立的说法，答案“同一个 Controller 实例默认服务所有并发请求”正是 控制器激活 的典型误区。其余三项分别给出了主规则“控制器通常由 DI 激活，可通过构造函数声明应用服务依赖”、适用边界“控制器应保持无状态且轻量，不能依赖实例跨请求保存会话数据”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0324 针对“控制器字段中的当前用户数据串到其他请求”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“控制器通常由 DI 激活，可通过构造函数声明应用服务依赖”修正实现，并用测试或遥测验证“控制器应保持无状态且轻量，不能依赖实例跨请求保存会话数据”。
- B. 按“同一个 Controller 实例默认服务所有并发请求”修改实现，并把一次请求成功作为验收结果。
- C. 按“控制器通常由 DI 激活，可通过构造函数声明应用服务依赖”修改代码后直接上线，不验证“控制器应保持无状态且轻量，不能依赖实例跨请求保存会话数据”。
- D. 只验证“控制器应保持无状态且轻量，不能依赖实例跨请求保存会话数据”，但实现仍继续依赖“同一个 Controller 实例默认服务所有并发请求”。
查看答案与解析
正确答案A
完整决策同时覆盖规则与验证：控制器通常由 DI 激活，可通过构造函数声明应用服务依赖；并确认 控制器应保持无状态且轻量，不能依赖实例跨请求保存会话数据。继续接受“同一个 Controller 实例默认服务所有并发请求”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“控制器字段中的当前用户数据串到其他请求”这一生产场景能否安全上线。
0325 在 Action 发现 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 公开实例方法可能按约定成为 Action，NonAction 可排除辅助方法
- B. 只有名称以 Action 结尾的方法才会成为 Action
- C. 重载和路由特性必须形成明确候选，避免动作选择歧义
- D. 观察到“公开辅助方法被意外暴露为端点”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案A
正确答案直接描述 Action 发现 的主规则：公开实例方法可能按约定成为 Action，NonAction 可排除辅助方法。选项“重载和路由特性必须形成明确候选，避免动作选择歧义”是使用规则时要验证的边界，不是规则本身；“只有名称以 Action 结尾的方法才会成为 Action”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0326 公开辅助方法被意外暴露为端点。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“只有名称以 Action 结尾的方法才会成为 Action”定性，不再检查配置、身份或运行时证据。
- B. 只增加重试次数或机器资源，暂不核对“重载和路由特性必须形成明确候选，避免动作选择歧义”。
- C. 以一次成功请求作为结论，不再确认“公开实例方法可能按约定成为 Action，NonAction 可排除辅助方法”是否成立。
- D. 先验证“重载和路由特性必须形成明确候选，避免动作选择歧义”，再依据“公开实例方法可能按约定成为 Action，NonAction 可排除辅助方法”判断实现是否符合契约。
查看答案与解析
正确答案D
场景“公开辅助方法被意外暴露为端点”指向 Action 发现，但症状本身不能证明根因。正确排查应先确认边界“重载和路由特性必须形成明确候选，避免动作选择歧义”，再用主规则“公开实例方法可能按约定成为 Action，NonAction 可排除辅助方法”解释证据。直接采用误区“只有名称以 Action 结尾的方法才会成为 Action”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0327 关于 Action 发现，以下哪项说法不成立？
难度： 实战
- A. 公开实例方法可能按约定成为 Action，NonAction 可排除辅助方法
- B. 只有名称以 Action 结尾的方法才会成为 Action
- C. 重载和路由特性必须形成明确候选，避免动作选择歧义
- D. 出现“公开辅助方法被意外暴露为端点”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案B
题目要求选出不成立的说法，答案“只有名称以 Action 结尾的方法才会成为 Action”正是 Action 发现 的典型误区。其余三项分别给出了主规则“公开实例方法可能按约定成为 Action，NonAction 可排除辅助方法”、适用边界“重载和路由特性必须形成明确候选，避免动作选择歧义”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0328 针对“公开辅助方法被意外暴露为端点”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“只有名称以 Action 结尾的方法才会成为 Action”修改实现，并把一次请求成功作为验收结果。
- B. 按“公开实例方法可能按约定成为 Action，NonAction 可排除辅助方法”修改代码后直接上线，不验证“重载和路由特性必须形成明确候选，避免动作选择歧义”。
- C. 按“公开实例方法可能按约定成为 Action，NonAction 可排除辅助方法”修正实现，并用测试或遥测验证“重载和路由特性必须形成明确候选，避免动作选择歧义”。
- D. 只验证“重载和路由特性必须形成明确候选，避免动作选择歧义”，但实现仍继续依赖“只有名称以 Action 结尾的方法才会成为 Action”。
查看答案与解析
正确答案C
完整决策同时覆盖规则与验证：公开实例方法可能按约定成为 Action，NonAction 可排除辅助方法；并确认 重载和路由特性必须形成明确候选，避免动作选择歧义。继续接受“只有名称以 Action 结尾的方法才会成为 Action”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“公开辅助方法被意外暴露为端点”这一生产场景能否安全上线。
0329 在 ActionResult<T> 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 返回 ActionResult<T> 后所有异常会自动转换为 T
- B. ActionResult<T> 可表达 T 成功结果与 ActionResult 错误结果，并辅助响应元数据推断
- C. 接口类型和隐式转换存在限制，多状态仍应明确文档化
- D. 观察到“查询不到资源时抛异常并得到错误 500”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案B
正确答案直接描述 ActionResult<T> 的主规则：ActionResult<T> 可表达 T 成功结果与 ActionResult 错误结果，并辅助响应元数据推断。选项“接口类型和隐式转换存在限制，多状态仍应明确文档化”是使用规则时要验证的边界，不是规则本身；“返回 ActionResult<T> 后所有异常会自动转换为 T”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0330 查询不到资源时抛异常并得到错误 500。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“返回 ActionResult<T> 后所有异常会自动转换为 T”定性，不再检查配置、身份或运行时证据。
- B. 只增加重试次数或机器资源，暂不核对“接口类型和隐式转换存在限制，多状态仍应明确文档化”。
- C. 先验证“接口类型和隐式转换存在限制，多状态仍应明确文档化”，再依据“ActionResult<T> 可表达 T 成功结果与 ActionResult 错误结果，并辅助响应元数据推断”判断实现是否符合契约。
- D. 以一次成功请求作为结论，不再确认“ActionResult<T> 可表达 T 成功结果与 ActionResult 错误结果，并辅助响应元数据推断”是否成立。
查看答案与解析
正确答案C
场景“查询不到资源时抛异常并得到错误 500”指向 ActionResult<T>，但症状本身不能证明根因。正确排查应先确认边界“接口类型和隐式转换存在限制，多状态仍应明确文档化”，再用主规则“ActionResult<T> 可表达 T 成功结果与 ActionResult 错误结果，并辅助响应元数据推断”解释证据。直接采用误区“返回 ActionResult<T> 后所有异常会自动转换为 T”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0331 关于 ActionResult<T>，以下哪项说法不成立？
难度： 实战
- A. ActionResult<T> 可表达 T 成功结果与 ActionResult 错误结果，并辅助响应元数据推断
- B. 接口类型和隐式转换存在限制，多状态仍应明确文档化
- C. 出现“查询不到资源时抛异常并得到错误 500”时，应收集证据并同时核对主规则与适用边界。
- D. 返回 ActionResult<T> 后所有异常会自动转换为 T
查看答案与解析
正确答案D
题目要求选出不成立的说法，答案“返回 ActionResult<T> 后所有异常会自动转换为 T”正是 ActionResult<T> 的典型误区。其余三项分别给出了主规则“ActionResult<T> 可表达 T 成功结果与 ActionResult 错误结果，并辅助响应元数据推断”、适用边界“接口类型和隐式转换存在限制，多状态仍应明确文档化”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0332 针对“查询不到资源时抛异常并得到错误 500”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“ActionResult<T> 可表达 T 成功结果与 ActionResult 错误结果，并辅助响应元数据推断”修正实现，并用测试或遥测验证“接口类型和隐式转换存在限制，多状态仍应明确文档化”。
- B. 按“返回 ActionResult<T> 后所有异常会自动转换为 T”修改实现，并把一次请求成功作为验收结果。
- C. 按“ActionResult<T> 可表达 T 成功结果与 ActionResult 错误结果，并辅助响应元数据推断”修改代码后直接上线，不验证“接口类型和隐式转换存在限制，多状态仍应明确文档化”。
- D. 只验证“接口类型和隐式转换存在限制，多状态仍应明确文档化”，但实现仍继续依赖“返回 ActionResult<T> 后所有异常会自动转换为 T”。
查看答案与解析
正确答案A
完整决策同时覆盖规则与验证：ActionResult<T> 可表达 T 成功结果与 ActionResult 错误结果，并辅助响应元数据推断；并确认 接口类型和隐式转换存在限制，多状态仍应明确文档化。继续接受“返回 ActionResult<T> 后所有异常会自动转换为 T”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“查询不到资源时抛异常并得到错误 500”这一生产场景能否安全上线。
0333 在 ApiController 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. ApiController 会自动验证数据库唯一约束
- B. 自动 400 依赖 ModelState，业务冲突、权限和资源不存在仍需显式处理
- C. ApiControllerAttribute 启用属性路由要求、绑定来源推断和自动 400 等 API 行为
- D. 观察到“重复请求在 SaveChanges 时才发生冲突”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案C
正确答案直接描述 ApiController 的主规则：ApiControllerAttribute 启用属性路由要求、绑定来源推断和自动 400 等 API 行为。选项“自动 400 依赖 ModelState，业务冲突、权限和资源不存在仍需显式处理”是使用规则时要验证的边界，不是规则本身；“ApiController 会自动验证数据库唯一约束”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0334 重复请求在 SaveChanges 时才发生冲突。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“ApiController 会自动验证数据库唯一约束”定性，不再检查配置、身份或运行时证据。
- B. 先验证“自动 400 依赖 ModelState，业务冲突、权限和资源不存在仍需显式处理”，再依据“ApiControllerAttribute 启用属性路由要求、绑定来源推断和自动 400 等 API 行为”判断实现是否符合契约。
- C. 只增加重试次数或机器资源，暂不核对“自动 400 依赖 ModelState，业务冲突、权限和资源不存在仍需显式处理”。
- D. 以一次成功请求作为结论，不再确认“ApiControllerAttribute 启用属性路由要求、绑定来源推断和自动 400 等 API 行为”是否成立。
查看答案与解析
正确答案B
场景“重复请求在 SaveChanges 时才发生冲突”指向 ApiController，但症状本身不能证明根因。正确排查应先确认边界“自动 400 依赖 ModelState，业务冲突、权限和资源不存在仍需显式处理”，再用主规则“ApiControllerAttribute 启用属性路由要求、绑定来源推断和自动 400 等 API 行为”解释证据。直接采用误区“ApiController 会自动验证数据库唯一约束”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0335 关于 ApiController，以下哪项说法不成立？
难度： 实战
- A. ApiController 会自动验证数据库唯一约束
- B. ApiControllerAttribute 启用属性路由要求、绑定来源推断和自动 400 等 API 行为
- C. 自动 400 依赖 ModelState，业务冲突、权限和资源不存在仍需显式处理
- D. 出现“重复请求在 SaveChanges 时才发生冲突”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案A
题目要求选出不成立的说法，答案“ApiController 会自动验证数据库唯一约束”正是 ApiController 的典型误区。其余三项分别给出了主规则“ApiControllerAttribute 启用属性路由要求、绑定来源推断和自动 400 等 API 行为”、适用边界“自动 400 依赖 ModelState，业务冲突、权限和资源不存在仍需显式处理”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0336 针对“重复请求在 SaveChanges 时才发生冲突”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“ApiController 会自动验证数据库唯一约束”修改实现，并把一次请求成功作为验收结果。
- B. 按“ApiControllerAttribute 启用属性路由要求、绑定来源推断和自动 400 等 API 行为”修改代码后直接上线，不验证“自动 400 依赖 ModelState，业务冲突、权限和资源不存在仍需显式处理”。
- C. 只验证“自动 400 依赖 ModelState，业务冲突、权限和资源不存在仍需显式处理”，但实现仍继续依赖“ApiController 会自动验证数据库唯一约束”。
- D. 按“ApiControllerAttribute 启用属性路由要求、绑定来源推断和自动 400 等 API 行为”修正实现，并用测试或遥测验证“自动 400 依赖 ModelState，业务冲突、权限和资源不存在仍需显式处理”。
查看答案与解析
正确答案D
完整决策同时覆盖规则与验证：ApiControllerAttribute 启用属性路由要求、绑定来源推断和自动 400 等 API 行为；并确认 自动 400 依赖 ModelState，业务冲突、权限和资源不存在仍需显式处理。继续接受“ApiController 会自动验证数据库唯一约束”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“重复请求在 SaveChanges 时才发生冲突”这一生产场景能否安全上线。
0337 在 异步 Action 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 只要方法签名返回 Task 就不会占用任何线程
- B. 把同步 CPU 工作包装进 Task.Run 通常不能提高服务器吞吐，需按工作负载设计
- C. 观察到“大量同步阻塞调用导致线程池饥饿”即可把一次现象当成完整框架契约。
- D. I/O 型 Action 应异步等待数据库和网络调用并传递 RequestAborted
查看答案与解析
正确答案D
正确答案直接描述 异步 Action 的主规则：I/O 型 Action 应异步等待数据库和网络调用并传递 RequestAborted。选项“把同步 CPU 工作包装进 Task.Run 通常不能提高服务器吞吐，需按工作负载设计”是使用规则时要验证的边界，不是规则本身；“只要方法签名返回 Task 就不会占用任何线程”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0338 大量同步阻塞调用导致线程池饥饿。排查时哪项动作最合理？
难度： 进阶
- A. 先验证“把同步 CPU 工作包装进 Task.Run 通常不能提高服务器吞吐，需按工作负载设计”，再依据“I/O 型 Action 应异步等待数据库和网络调用并传递 RequestAborted”判断实现是否符合契约。
- B. 直接按“只要方法签名返回 Task 就不会占用任何线程”定性，不再检查配置、身份或运行时证据。
- C. 只增加重试次数或机器资源，暂不核对“把同步 CPU 工作包装进 Task.Run 通常不能提高服务器吞吐，需按工作负载设计”。
- D. 以一次成功请求作为结论，不再确认“I/O 型 Action 应异步等待数据库和网络调用并传递 RequestAborted”是否成立。
查看答案与解析
正确答案A
场景“大量同步阻塞调用导致线程池饥饿”指向 异步 Action，但症状本身不能证明根因。正确排查应先确认边界“把同步 CPU 工作包装进 Task.Run 通常不能提高服务器吞吐，需按工作负载设计”，再用主规则“I/O 型 Action 应异步等待数据库和网络调用并传递 RequestAborted”解释证据。直接采用误区“只要方法签名返回 Task 就不会占用任何线程”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0339 关于 异步 Action，以下哪项说法不成立？
难度： 实战
- A. I/O 型 Action 应异步等待数据库和网络调用并传递 RequestAborted
- B. 把同步 CPU 工作包装进 Task.Run 通常不能提高服务器吞吐，需按工作负载设计
- C. 只要方法签名返回 Task 就不会占用任何线程
- D. 出现“大量同步阻塞调用导致线程池饥饿”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案C
题目要求选出不成立的说法，答案“只要方法签名返回 Task 就不会占用任何线程”正是 异步 Action 的典型误区。其余三项分别给出了主规则“I/O 型 Action 应异步等待数据库和网络调用并传递 RequestAborted”、适用边界“把同步 CPU 工作包装进 Task.Run 通常不能提高服务器吞吐，需按工作负载设计”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0340 针对“大量同步阻塞调用导致线程池饥饿”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“只要方法签名返回 Task 就不会占用任何线程”修改实现，并把一次请求成功作为验收结果。
- B. 按“I/O 型 Action 应异步等待数据库和网络调用并传递 RequestAborted”修正实现，并用测试或遥测验证“把同步 CPU 工作包装进 Task.Run 通常不能提高服务器吞吐，需按工作负载设计”。
- C. 按“I/O 型 Action 应异步等待数据库和网络调用并传递 RequestAborted”修改代码后直接上线，不验证“把同步 CPU 工作包装进 Task.Run 通常不能提高服务器吞吐，需按工作负载设计”。
- D. 只验证“把同步 CPU 工作包装进 Task.Run 通常不能提高服务器吞吐，需按工作负载设计”，但实现仍继续依赖“只要方法签名返回 Task 就不会占用任何线程”。
查看答案与解析
正确答案B
完整决策同时覆盖规则与验证：I/O 型 Action 应异步等待数据库和网络调用并传递 RequestAborted；并确认 把同步 CPU 工作包装进 Task.Run 通常不能提高服务器吞吐，需按工作负载设计。继续接受“只要方法签名返回 Task 就不会占用任何线程”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“大量同步阻塞调用导致线程池饥饿”这一生产场景能否安全上线。