ASP.NET Core 试题 05：自定义中间件
0081 在 约定式中间件 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 把 DbContext 注入约定式中间件构造函数是推荐的每请求用法
- B. 约定式中间件构造函数接收 RequestDelegate，并公开 Invoke 或 InvokeAsync
- C. 中间件实例通常在应用启动时创建，构造函数不宜直接捕获 Scoped 服务
- D. 观察到“中间件启动时报无法从根容器解析 Scoped 服务”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案B
正确答案直接描述 约定式中间件 的主规则：约定式中间件构造函数接收 RequestDelegate，并公开 Invoke 或 InvokeAsync。选项“中间件实例通常在应用启动时创建，构造函数不宜直接捕获 Scoped 服务”是使用规则时要验证的边界，不是规则本身；“把 DbContext 注入约定式中间件构造函数是推荐的每请求用法”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0082 中间件启动时报无法从根容器解析 Scoped 服务。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“把 DbContext 注入约定式中间件构造函数是推荐的每请求用法”定性，不再检查配置、身份或运行时证据。
- B. 只增加重试次数或机器资源，暂不核对“中间件实例通常在应用启动时创建，构造函数不宜直接捕获 Scoped 服务”。
- C. 以一次成功请求作为结论，不再确认“约定式中间件构造函数接收 RequestDelegate，并公开 Invoke 或 InvokeAsync”是否成立。
- D. 先验证“中间件实例通常在应用启动时创建，构造函数不宜直接捕获 Scoped 服务”，再依据“约定式中间件构造函数接收 RequestDelegate，并公开 Invoke 或 InvokeAsync”判断实现是否符合契约。
查看答案与解析
正确答案D
场景“中间件启动时报无法从根容器解析 Scoped 服务”指向 约定式中间件，但症状本身不能证明根因。正确排查应先确认边界“中间件实例通常在应用启动时创建，构造函数不宜直接捕获 Scoped 服务”，再用主规则“约定式中间件构造函数接收 RequestDelegate，并公开 Invoke 或 InvokeAsync”解释证据。直接采用误区“把 DbContext 注入约定式中间件构造函数是推荐的每请求用法”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0083 关于 约定式中间件，以下哪项说法不成立？
难度： 实战
- A. 约定式中间件构造函数接收 RequestDelegate，并公开 Invoke 或 InvokeAsync
- B. 中间件实例通常在应用启动时创建，构造函数不宜直接捕获 Scoped 服务
- C. 把 DbContext 注入约定式中间件构造函数是推荐的每请求用法
- D. 出现“中间件启动时报无法从根容器解析 Scoped 服务”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案C
题目要求选出不成立的说法，答案“把 DbContext 注入约定式中间件构造函数是推荐的每请求用法”正是 约定式中间件 的典型误区。其余三项分别给出了主规则“约定式中间件构造函数接收 RequestDelegate，并公开 Invoke 或 InvokeAsync”、适用边界“中间件实例通常在应用启动时创建，构造函数不宜直接捕获 Scoped 服务”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0084 针对“中间件启动时报无法从根容器解析 Scoped 服务”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“约定式中间件构造函数接收 RequestDelegate，并公开 Invoke 或 InvokeAsync”修正实现，并用测试或遥测验证“中间件实例通常在应用启动时创建，构造函数不宜直接捕获 Scoped 服务”。
- B. 按“把 DbContext 注入约定式中间件构造函数是推荐的每请求用法”修改实现，并把一次请求成功作为验收结果。
- C. 按“约定式中间件构造函数接收 RequestDelegate，并公开 Invoke 或 InvokeAsync”修改代码后直接上线，不验证“中间件实例通常在应用启动时创建，构造函数不宜直接捕获 Scoped 服务”。
- D. 只验证“中间件实例通常在应用启动时创建，构造函数不宜直接捕获 Scoped 服务”，但实现仍继续依赖“把 DbContext 注入约定式中间件构造函数是推荐的每请求用法”。
查看答案与解析
正确答案A
完整决策同时覆盖规则与验证：约定式中间件构造函数接收 RequestDelegate，并公开 Invoke 或 InvokeAsync；并确认 中间件实例通常在应用启动时创建，构造函数不宜直接捕获 Scoped 服务。继续接受“把 DbContext 注入约定式中间件构造函数是推荐的每请求用法”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“中间件启动时报无法从根容器解析 Scoped 服务”这一生产场景能否安全上线。
0085 在 InvokeAsync 参数注入 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. InvokeAsync 参数会在应用启动时只解析一次
- B. 参数类型必须已注册，且该方式只适合执行方法可用的依赖
- C. 约定式中间件可在 InvokeAsync 参数中解析每请求 Scoped 依赖
- D. 观察到“两个请求错误地共享了同一 DbContext”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案C
正确答案直接描述 InvokeAsync 参数注入 的主规则：约定式中间件可在 InvokeAsync 参数中解析每请求 Scoped 依赖。选项“参数类型必须已注册，且该方式只适合执行方法可用的依赖”是使用规则时要验证的边界，不是规则本身；“InvokeAsync 参数会在应用启动时只解析一次”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0086 两个请求错误地共享了同一 DbContext。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“InvokeAsync 参数会在应用启动时只解析一次”定性，不再检查配置、身份或运行时证据。
- B. 只增加重试次数或机器资源，暂不核对“参数类型必须已注册，且该方式只适合执行方法可用的依赖”。
- C. 以一次成功请求作为结论，不再确认“约定式中间件可在 InvokeAsync 参数中解析每请求 Scoped 依赖”是否成立。
- D. 先验证“参数类型必须已注册，且该方式只适合执行方法可用的依赖”，再依据“约定式中间件可在 InvokeAsync 参数中解析每请求 Scoped 依赖”判断实现是否符合契约。
查看答案与解析
正确答案D
场景“两个请求错误地共享了同一 DbContext”指向 InvokeAsync 参数注入，但症状本身不能证明根因。正确排查应先确认边界“参数类型必须已注册，且该方式只适合执行方法可用的依赖”，再用主规则“约定式中间件可在 InvokeAsync 参数中解析每请求 Scoped 依赖”解释证据。直接采用误区“InvokeAsync 参数会在应用启动时只解析一次”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0087 关于 InvokeAsync 参数注入，以下哪项说法不成立？
难度： 实战
- A. InvokeAsync 参数会在应用启动时只解析一次
- B. 约定式中间件可在 InvokeAsync 参数中解析每请求 Scoped 依赖
- C. 参数类型必须已注册，且该方式只适合执行方法可用的依赖
- D. 出现“两个请求错误地共享了同一 DbContext”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案A
题目要求选出不成立的说法，答案“InvokeAsync 参数会在应用启动时只解析一次”正是 InvokeAsync 参数注入 的典型误区。其余三项分别给出了主规则“约定式中间件可在 InvokeAsync 参数中解析每请求 Scoped 依赖”、适用边界“参数类型必须已注册，且该方式只适合执行方法可用的依赖”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0088 针对“两个请求错误地共享了同一 DbContext”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“InvokeAsync 参数会在应用启动时只解析一次”修改实现，并把一次请求成功作为验收结果。
- B. 按“约定式中间件可在 InvokeAsync 参数中解析每请求 Scoped 依赖”修正实现，并用测试或遥测验证“参数类型必须已注册，且该方式只适合执行方法可用的依赖”。
- C. 按“约定式中间件可在 InvokeAsync 参数中解析每请求 Scoped 依赖”修改代码后直接上线，不验证“参数类型必须已注册，且该方式只适合执行方法可用的依赖”。
- D. 只验证“参数类型必须已注册，且该方式只适合执行方法可用的依赖”，但实现仍继续依赖“InvokeAsync 参数会在应用启动时只解析一次”。
查看答案与解析
正确答案B
完整决策同时覆盖规则与验证：约定式中间件可在 InvokeAsync 参数中解析每请求 Scoped 依赖；并确认 参数类型必须已注册，且该方式只适合执行方法可用的依赖。继续接受“InvokeAsync 参数会在应用启动时只解析一次”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“两个请求错误地共享了同一 DbContext”这一生产场景能否安全上线。
0089 在 IMiddleware 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 实现 IMiddleware 后无需向 DI 注册该类型
- B. IMiddleware 本身及依赖生命周期由容器注册决定，通常注册为 Transient 或 Scoped
- C. 观察到“请求到达时提示找不到 IMiddleware 服务”即可把一次现象当成完整框架契约。
- D. 实现 IMiddleware 并通过 UseMiddleware 注册时，可由 IMiddlewareFactory 按请求激活
查看答案与解析
正确答案D
正确答案直接描述 IMiddleware 的主规则：实现 IMiddleware 并通过 UseMiddleware 注册时，可由 IMiddlewareFactory 按请求激活。选项“IMiddleware 本身及依赖生命周期由容器注册决定，通常注册为 Transient 或 Scoped”是使用规则时要验证的边界，不是规则本身；“实现 IMiddleware 后无需向 DI 注册该类型”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0090 请求到达时提示找不到 IMiddleware 服务。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“实现 IMiddleware 后无需向 DI 注册该类型”定性，不再检查配置、身份或运行时证据。
- B. 先验证“IMiddleware 本身及依赖生命周期由容器注册决定，通常注册为 Transient 或 Scoped”，再依据“实现 IMiddleware 并通过 UseMiddleware 注册时，可由 IMiddlewareFactory 按请求激活”判断实现是否符合契约。
- C. 只增加重试次数或机器资源，暂不核对“IMiddleware 本身及依赖生命周期由容器注册决定，通常注册为 Transient 或 Scoped”。
- D. 以一次成功请求作为结论，不再确认“实现 IMiddleware 并通过 UseMiddleware 注册时，可由 IMiddlewareFactory 按请求激活”是否成立。
查看答案与解析
正确答案B
场景“请求到达时提示找不到 IMiddleware 服务”指向 IMiddleware，但症状本身不能证明根因。正确排查应先确认边界“IMiddleware 本身及依赖生命周期由容器注册决定，通常注册为 Transient 或 Scoped”，再用主规则“实现 IMiddleware 并通过 UseMiddleware 注册时，可由 IMiddlewareFactory 按请求激活”解释证据。直接采用误区“实现 IMiddleware 后无需向 DI 注册该类型”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0091 关于 IMiddleware，以下哪项说法不成立？
难度： 实战
- A. 实现 IMiddleware 并通过 UseMiddleware 注册时，可由 IMiddlewareFactory 按请求激活
- B. IMiddleware 本身及依赖生命周期由容器注册决定，通常注册为 Transient 或 Scoped
- C. 实现 IMiddleware 后无需向 DI 注册该类型
- D. 出现“请求到达时提示找不到 IMiddleware 服务”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案C
题目要求选出不成立的说法，答案“实现 IMiddleware 后无需向 DI 注册该类型”正是 IMiddleware 的典型误区。其余三项分别给出了主规则“实现 IMiddleware 并通过 UseMiddleware 注册时，可由 IMiddlewareFactory 按请求激活”、适用边界“IMiddleware 本身及依赖生命周期由容器注册决定，通常注册为 Transient 或 Scoped”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0092 针对“请求到达时提示找不到 IMiddleware 服务”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“实现 IMiddleware 并通过 UseMiddleware 注册时，可由 IMiddlewareFactory 按请求激活”修正实现，并用测试或遥测验证“IMiddleware 本身及依赖生命周期由容器注册决定，通常注册为 Transient 或 Scoped”。
- B. 按“实现 IMiddleware 后无需向 DI 注册该类型”修改实现，并把一次请求成功作为验收结果。
- C. 按“实现 IMiddleware 并通过 UseMiddleware 注册时，可由 IMiddlewareFactory 按请求激活”修改代码后直接上线，不验证“IMiddleware 本身及依赖生命周期由容器注册决定，通常注册为 Transient 或 Scoped”。
- D. 只验证“IMiddleware 本身及依赖生命周期由容器注册决定，通常注册为 Transient 或 Scoped”，但实现仍继续依赖“实现 IMiddleware 后无需向 DI 注册该类型”。
查看答案与解析
正确答案A
完整决策同时覆盖规则与验证：实现 IMiddleware 并通过 UseMiddleware 注册时，可由 IMiddlewareFactory 按请求激活；并确认 IMiddleware 本身及依赖生命周期由容器注册决定，通常注册为 Transient 或 Scoped。继续接受“实现 IMiddleware 后无需向 DI 注册该类型”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“请求到达时提示找不到 IMiddleware 服务”这一生产场景能否安全上线。
0093 在 调用 next 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 调用 next 前后的代码分别包围后续管道，可用于计时、事务边界或响应处理
- B. await next(context) 返回后响应一定尚未开始
- C. 响应开始后再修改状态码或响应头可能抛错或无效
- D. 观察到“下载响应中间件尝试在末尾追加响应头失败”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案A
正确答案直接描述 调用 next 的主规则：调用 next 前后的代码分别包围后续管道，可用于计时、事务边界或响应处理。选项“响应开始后再修改状态码或响应头可能抛错或无效”是使用规则时要验证的边界，不是规则本身；“await next(context) 返回后响应一定尚未开始”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0094 下载响应中间件尝试在末尾追加响应头失败。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“await next(context) 返回后响应一定尚未开始”定性，不再检查配置、身份或运行时证据。
- B. 只增加重试次数或机器资源，暂不核对“响应开始后再修改状态码或响应头可能抛错或无效”。
- C. 先验证“响应开始后再修改状态码或响应头可能抛错或无效”，再依据“调用 next 前后的代码分别包围后续管道，可用于计时、事务边界或响应处理”判断实现是否符合契约。
- D. 以一次成功请求作为结论，不再确认“调用 next 前后的代码分别包围后续管道，可用于计时、事务边界或响应处理”是否成立。
查看答案与解析
正确答案C
场景“下载响应中间件尝试在末尾追加响应头失败”指向 调用 next，但症状本身不能证明根因。正确排查应先确认边界“响应开始后再修改状态码或响应头可能抛错或无效”，再用主规则“调用 next 前后的代码分别包围后续管道，可用于计时、事务边界或响应处理”解释证据。直接采用误区“await next(context) 返回后响应一定尚未开始”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0095 关于 调用 next，以下哪项说法不成立？
难度： 实战
- A. 调用 next 前后的代码分别包围后续管道，可用于计时、事务边界或响应处理
- B. await next(context) 返回后响应一定尚未开始
- C. 响应开始后再修改状态码或响应头可能抛错或无效
- D. 出现“下载响应中间件尝试在末尾追加响应头失败”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案B
题目要求选出不成立的说法，答案“await next(context) 返回后响应一定尚未开始”正是 调用 next 的典型误区。其余三项分别给出了主规则“调用 next 前后的代码分别包围后续管道，可用于计时、事务边界或响应处理”、适用边界“响应开始后再修改状态码或响应头可能抛错或无效”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0096 针对“下载响应中间件尝试在末尾追加响应头失败”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“await next(context) 返回后响应一定尚未开始”修改实现，并把一次请求成功作为验收结果。
- B. 按“调用 next 前后的代码分别包围后续管道，可用于计时、事务边界或响应处理”修改代码后直接上线，不验证“响应开始后再修改状态码或响应头可能抛错或无效”。
- C. 只验证“响应开始后再修改状态码或响应头可能抛错或无效”，但实现仍继续依赖“await next(context) 返回后响应一定尚未开始”。
- D. 按“调用 next 前后的代码分别包围后续管道，可用于计时、事务边界或响应处理”修正实现，并用测试或遥测验证“响应开始后再修改状态码或响应头可能抛错或无效”。
查看答案与解析
正确答案D
完整决策同时覆盖规则与验证：调用 next 前后的代码分别包围后续管道，可用于计时、事务边界或响应处理；并确认 响应开始后再修改状态码或响应头可能抛错或无效。继续接受“await next(context) 返回后响应一定尚未开始”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“下载响应中间件尝试在末尾追加响应头失败”这一生产场景能否安全上线。
0097 在 中间件分支 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 所有分支都会自动合并并执行主管道剩余部分
- B. Map、MapWhen 和 UseWhen 可按路径或谓词创建分支
- C. Map 会消费匹配路径段，UseWhen 通常可在分支后重新加入主管道
- D. 观察到“管理端点意外执行了公开 API 的中间件”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案B
正确答案直接描述 中间件分支 的主规则：Map、MapWhen 和 UseWhen 可按路径或谓词创建分支。选项“Map 会消费匹配路径段，UseWhen 通常可在分支后重新加入主管道”是使用规则时要验证的边界，不是规则本身；“所有分支都会自动合并并执行主管道剩余部分”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0098 管理端点意外执行了公开 API 的中间件。排查时哪项动作最合理？
难度： 进阶
- A. 先验证“Map 会消费匹配路径段，UseWhen 通常可在分支后重新加入主管道”，再依据“Map、MapWhen 和 UseWhen 可按路径或谓词创建分支”判断实现是否符合契约。
- B. 直接按“所有分支都会自动合并并执行主管道剩余部分”定性，不再检查配置、身份或运行时证据。
- C. 只增加重试次数或机器资源，暂不核对“Map 会消费匹配路径段，UseWhen 通常可在分支后重新加入主管道”。
- D. 以一次成功请求作为结论，不再确认“Map、MapWhen 和 UseWhen 可按路径或谓词创建分支”是否成立。
查看答案与解析
正确答案A
场景“管理端点意外执行了公开 API 的中间件”指向 中间件分支，但症状本身不能证明根因。正确排查应先确认边界“Map 会消费匹配路径段，UseWhen 通常可在分支后重新加入主管道”，再用主规则“Map、MapWhen 和 UseWhen 可按路径或谓词创建分支”解释证据。直接采用误区“所有分支都会自动合并并执行主管道剩余部分”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0099 关于 中间件分支，以下哪项说法不成立？
难度： 实战
- A. Map、MapWhen 和 UseWhen 可按路径或谓词创建分支
- B. Map 会消费匹配路径段，UseWhen 通常可在分支后重新加入主管道
- C. 出现“管理端点意外执行了公开 API 的中间件”时，应收集证据并同时核对主规则与适用边界。
- D. 所有分支都会自动合并并执行主管道剩余部分
查看答案与解析
正确答案D
题目要求选出不成立的说法，答案“所有分支都会自动合并并执行主管道剩余部分”正是 中间件分支 的典型误区。其余三项分别给出了主规则“Map、MapWhen 和 UseWhen 可按路径或谓词创建分支”、适用边界“Map 会消费匹配路径段，UseWhen 通常可在分支后重新加入主管道”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0100 针对“管理端点意外执行了公开 API 的中间件”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“所有分支都会自动合并并执行主管道剩余部分”修改实现，并把一次请求成功作为验收结果。
- B. 按“Map、MapWhen 和 UseWhen 可按路径或谓词创建分支”修改代码后直接上线，不验证“Map 会消费匹配路径段，UseWhen 通常可在分支后重新加入主管道”。
- C. 按“Map、MapWhen 和 UseWhen 可按路径或谓词创建分支”修正实现，并用测试或遥测验证“Map 会消费匹配路径段，UseWhen 通常可在分支后重新加入主管道”。
- D. 只验证“Map 会消费匹配路径段，UseWhen 通常可在分支后重新加入主管道”，但实现仍继续依赖“所有分支都会自动合并并执行主管道剩余部分”。
查看答案与解析
正确答案C
完整决策同时覆盖规则与验证：Map、MapWhen 和 UseWhen 可按路径或谓词创建分支；并确认 Map 会消费匹配路径段，UseWhen 通常可在分支后重新加入主管道。继续接受“所有分支都会自动合并并执行主管道剩余部分”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“管理端点意外执行了公开 API 的中间件”这一生产场景能否安全上线。