ASP.NET Core 试题 21：MVC 过滤器
0401 在 过滤器管道 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 授权、资源、Action、异常和结果过滤器在 MVC 内部不同阶段执行
- B. 过滤器与中间件完全等价，可以任意互换而不改变覆盖范围
- C. 中间件包围整个 MVC，过滤器只作用于 MVC Action 或页面执行范围
- D. 观察到“Minimal API 没有执行控制器上声明的过滤器”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案A
正确答案直接描述 过滤器管道 的主规则：授权、资源、Action、异常和结果过滤器在 MVC 内部不同阶段执行。选项“中间件包围整个 MVC，过滤器只作用于 MVC Action 或页面执行范围”是使用规则时要验证的边界，不是规则本身；“过滤器与中间件完全等价，可以任意互换而不改变覆盖范围”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0402 Minimal API 没有执行控制器上声明的过滤器。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“过滤器与中间件完全等价，可以任意互换而不改变覆盖范围”定性，不再检查配置、身份或运行时证据。
- B. 只增加重试次数或机器资源，暂不核对“中间件包围整个 MVC，过滤器只作用于 MVC Action 或页面执行范围”。
- C. 先验证“中间件包围整个 MVC，过滤器只作用于 MVC Action 或页面执行范围”，再依据“授权、资源、Action、异常和结果过滤器在 MVC 内部不同阶段执行”判断实现是否符合契约。
- D. 以一次成功请求作为结论，不再确认“授权、资源、Action、异常和结果过滤器在 MVC 内部不同阶段执行”是否成立。
查看答案与解析
正确答案C
场景“Minimal API 没有执行控制器上声明的过滤器”指向 过滤器管道，但症状本身不能证明根因。正确排查应先确认边界“中间件包围整个 MVC，过滤器只作用于 MVC Action 或页面执行范围”，再用主规则“授权、资源、Action、异常和结果过滤器在 MVC 内部不同阶段执行”解释证据。直接采用误区“过滤器与中间件完全等价，可以任意互换而不改变覆盖范围”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0403 关于 过滤器管道，以下哪项说法不成立？
难度： 实战
- A. 授权、资源、Action、异常和结果过滤器在 MVC 内部不同阶段执行
- B. 中间件包围整个 MVC，过滤器只作用于 MVC Action 或页面执行范围
- C. 出现“Minimal API 没有执行控制器上声明的过滤器”时，应收集证据并同时核对主规则与适用边界。
- D. 过滤器与中间件完全等价，可以任意互换而不改变覆盖范围
查看答案与解析
正确答案D
题目要求选出不成立的说法，答案“过滤器与中间件完全等价，可以任意互换而不改变覆盖范围”正是 过滤器管道 的典型误区。其余三项分别给出了主规则“授权、资源、Action、异常和结果过滤器在 MVC 内部不同阶段执行”、适用边界“中间件包围整个 MVC，过滤器只作用于 MVC Action 或页面执行范围”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0404 针对“Minimal API 没有执行控制器上声明的过滤器”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“过滤器与中间件完全等价，可以任意互换而不改变覆盖范围”修改实现，并把一次请求成功作为验收结果。
- B. 按“授权、资源、Action、异常和结果过滤器在 MVC 内部不同阶段执行”修正实现，并用测试或遥测验证“中间件包围整个 MVC，过滤器只作用于 MVC Action 或页面执行范围”。
- C. 按“授权、资源、Action、异常和结果过滤器在 MVC 内部不同阶段执行”修改代码后直接上线，不验证“中间件包围整个 MVC，过滤器只作用于 MVC Action 或页面执行范围”。
- D. 只验证“中间件包围整个 MVC，过滤器只作用于 MVC Action 或页面执行范围”，但实现仍继续依赖“过滤器与中间件完全等价，可以任意互换而不改变覆盖范围”。
查看答案与解析
正确答案B
完整决策同时覆盖规则与验证：授权、资源、Action、异常和结果过滤器在 MVC 内部不同阶段执行；并确认 中间件包围整个 MVC，过滤器只作用于 MVC Action 或页面执行范围。继续接受“过滤器与中间件完全等价，可以任意互换而不改变覆盖范围”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“Minimal API 没有执行控制器上声明的过滤器”这一生产场景能否安全上线。
0405 在 过滤器作用域 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. Action 级过滤器永远最先进入并最后退出
- B. 过滤器可在全局、控制器和 Action 级别配置，嵌套顺序通常是全局包围控制器、控制器包围 Action
- C. Order 和实现的 IOrderedFilter 可改变顺序，必须测试异常与短路路径
- D. 观察到“事务过滤器在缓存短路后仍然提交”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案B
正确答案直接描述 过滤器作用域 的主规则：过滤器可在全局、控制器和 Action 级别配置，嵌套顺序通常是全局包围控制器、控制器包围 Action。选项“Order 和实现的 IOrderedFilter 可改变顺序，必须测试异常与短路路径”是使用规则时要验证的边界，不是规则本身；“Action 级过滤器永远最先进入并最后退出”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0406 事务过滤器在缓存短路后仍然提交。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“Action 级过滤器永远最先进入并最后退出”定性，不再检查配置、身份或运行时证据。
- B. 只增加重试次数或机器资源，暂不核对“Order 和实现的 IOrderedFilter 可改变顺序，必须测试异常与短路路径”。
- C. 先验证“Order 和实现的 IOrderedFilter 可改变顺序，必须测试异常与短路路径”，再依据“过滤器可在全局、控制器和 Action 级别配置，嵌套顺序通常是全局包围控制器、控制器包围 Action”判断实现是否符合契约。
- D. 以一次成功请求作为结论，不再确认“过滤器可在全局、控制器和 Action 级别配置，嵌套顺序通常是全局包围控制器、控制器包围 Action”是否成立。
查看答案与解析
正确答案C
场景“事务过滤器在缓存短路后仍然提交”指向 过滤器作用域，但症状本身不能证明根因。正确排查应先确认边界“Order 和实现的 IOrderedFilter 可改变顺序，必须测试异常与短路路径”，再用主规则“过滤器可在全局、控制器和 Action 级别配置，嵌套顺序通常是全局包围控制器、控制器包围 Action”解释证据。直接采用误区“Action 级过滤器永远最先进入并最后退出”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0407 关于 过滤器作用域，以下哪项说法不成立？
难度： 实战
- A. Action 级过滤器永远最先进入并最后退出
- B. 过滤器可在全局、控制器和 Action 级别配置，嵌套顺序通常是全局包围控制器、控制器包围 Action
- C. Order 和实现的 IOrderedFilter 可改变顺序，必须测试异常与短路路径
- D. 出现“事务过滤器在缓存短路后仍然提交”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案A
题目要求选出不成立的说法，答案“Action 级过滤器永远最先进入并最后退出”正是 过滤器作用域 的典型误区。其余三项分别给出了主规则“过滤器可在全局、控制器和 Action 级别配置，嵌套顺序通常是全局包围控制器、控制器包围 Action”、适用边界“Order 和实现的 IOrderedFilter 可改变顺序，必须测试异常与短路路径”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0408 针对“事务过滤器在缓存短路后仍然提交”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“Action 级过滤器永远最先进入并最后退出”修改实现，并把一次请求成功作为验收结果。
- B. 按“过滤器可在全局、控制器和 Action 级别配置，嵌套顺序通常是全局包围控制器、控制器包围 Action”修改代码后直接上线，不验证“Order 和实现的 IOrderedFilter 可改变顺序，必须测试异常与短路路径”。
- C. 只验证“Order 和实现的 IOrderedFilter 可改变顺序，必须测试异常与短路路径”，但实现仍继续依赖“Action 级过滤器永远最先进入并最后退出”。
- D. 按“过滤器可在全局、控制器和 Action 级别配置，嵌套顺序通常是全局包围控制器、控制器包围 Action”修正实现，并用测试或遥测验证“Order 和实现的 IOrderedFilter 可改变顺序，必须测试异常与短路路径”。
查看答案与解析
正确答案D
完整决策同时覆盖规则与验证：过滤器可在全局、控制器和 Action 级别配置，嵌套顺序通常是全局包围控制器、控制器包围 Action；并确认 Order 和实现的 IOrderedFilter 可改变顺序，必须测试异常与短路路径。继续接受“Action 级过滤器永远最先进入并最后退出”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“事务过滤器在缓存短路后仍然提交”这一生产场景能否安全上线。
0409 在 异常过滤器 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 异常过滤器能捕获服务器管道中任何组件抛出的异常
- B. 它不捕获资源过滤器、结果执行等所有异常，统一兜底通常仍需异常中间件
- C. 异常过滤器处理 Action 创建后、结果执行前的未处理异常，覆盖范围比异常中间件窄
- D. 观察到“响应序列化异常没有被异常过滤器处理”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案C
正确答案直接描述 异常过滤器 的主规则：异常过滤器处理 Action 创建后、结果执行前的未处理异常，覆盖范围比异常中间件窄。选项“它不捕获资源过滤器、结果执行等所有异常，统一兜底通常仍需异常中间件”是使用规则时要验证的边界，不是规则本身；“异常过滤器能捕获服务器管道中任何组件抛出的异常”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0410 响应序列化异常没有被异常过滤器处理。排查时哪项动作最合理？
难度： 进阶
- A. 先验证“它不捕获资源过滤器、结果执行等所有异常，统一兜底通常仍需异常中间件”，再依据“异常过滤器处理 Action 创建后、结果执行前的未处理异常，覆盖范围比异常中间件窄”判断实现是否符合契约。
- B. 直接按“异常过滤器能捕获服务器管道中任何组件抛出的异常”定性，不再检查配置、身份或运行时证据。
- C. 只增加重试次数或机器资源，暂不核对“它不捕获资源过滤器、结果执行等所有异常，统一兜底通常仍需异常中间件”。
- D. 以一次成功请求作为结论，不再确认“异常过滤器处理 Action 创建后、结果执行前的未处理异常，覆盖范围比异常中间件窄”是否成立。
查看答案与解析
正确答案A
场景“响应序列化异常没有被异常过滤器处理”指向 异常过滤器，但症状本身不能证明根因。正确排查应先确认边界“它不捕获资源过滤器、结果执行等所有异常，统一兜底通常仍需异常中间件”，再用主规则“异常过滤器处理 Action 创建后、结果执行前的未处理异常，覆盖范围比异常中间件窄”解释证据。直接采用误区“异常过滤器能捕获服务器管道中任何组件抛出的异常”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0411 关于 异常过滤器，以下哪项说法不成立？
难度： 实战
- A. 异常过滤器处理 Action 创建后、结果执行前的未处理异常，覆盖范围比异常中间件窄
- B. 它不捕获资源过滤器、结果执行等所有异常，统一兜底通常仍需异常中间件
- C. 出现“响应序列化异常没有被异常过滤器处理”时，应收集证据并同时核对主规则与适用边界。
- D. 异常过滤器能捕获服务器管道中任何组件抛出的异常
查看答案与解析
正确答案D
题目要求选出不成立的说法，答案“异常过滤器能捕获服务器管道中任何组件抛出的异常”正是 异常过滤器 的典型误区。其余三项分别给出了主规则“异常过滤器处理 Action 创建后、结果执行前的未处理异常，覆盖范围比异常中间件窄”、适用边界“它不捕获资源过滤器、结果执行等所有异常，统一兜底通常仍需异常中间件”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0412 针对“响应序列化异常没有被异常过滤器处理”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“异常过滤器能捕获服务器管道中任何组件抛出的异常”修改实现，并把一次请求成功作为验收结果。
- B. 按“异常过滤器处理 Action 创建后、结果执行前的未处理异常，覆盖范围比异常中间件窄”修正实现，并用测试或遥测验证“它不捕获资源过滤器、结果执行等所有异常，统一兜底通常仍需异常中间件”。
- C. 按“异常过滤器处理 Action 创建后、结果执行前的未处理异常，覆盖范围比异常中间件窄”修改代码后直接上线，不验证“它不捕获资源过滤器、结果执行等所有异常，统一兜底通常仍需异常中间件”。
- D. 只验证“它不捕获资源过滤器、结果执行等所有异常，统一兜底通常仍需异常中间件”，但实现仍继续依赖“异常过滤器能捕获服务器管道中任何组件抛出的异常”。
查看答案与解析
正确答案B
完整决策同时覆盖规则与验证：异常过滤器处理 Action 创建后、结果执行前的未处理异常，覆盖范围比异常中间件窄；并确认 它不捕获资源过滤器、结果执行等所有异常，统一兜底通常仍需异常中间件。继续接受“异常过滤器能捕获服务器管道中任何组件抛出的异常”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“响应序列化异常没有被异常过滤器处理”这一生产场景能否安全上线。
0413 在 过滤器依赖注入 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 在过滤器 Attribute 构造函数中可直接注入任意 Scoped 服务
- B. Attribute 实例不适合保存每请求可变状态，生命周期必须与依赖匹配
- C. 观察到“应用启动时报 Attribute 没有合适构造函数”即可把一次现象当成完整框架契约。
- D. ServiceFilter、TypeFilter 或实现 IFilterFactory 可让过滤器从 DI 获取依赖
查看答案与解析
正确答案D
正确答案直接描述 过滤器依赖注入 的主规则：ServiceFilter、TypeFilter 或实现 IFilterFactory 可让过滤器从 DI 获取依赖。选项“Attribute 实例不适合保存每请求可变状态，生命周期必须与依赖匹配”是使用规则时要验证的边界，不是规则本身；“在过滤器 Attribute 构造函数中可直接注入任意 Scoped 服务”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0414 应用启动时报 Attribute 没有合适构造函数。排查时哪项动作最合理？
难度： 进阶
- A. 先验证“Attribute 实例不适合保存每请求可变状态，生命周期必须与依赖匹配”，再依据“ServiceFilter、TypeFilter 或实现 IFilterFactory 可让过滤器从 DI 获取依赖”判断实现是否符合契约。
- B. 直接按“在过滤器 Attribute 构造函数中可直接注入任意 Scoped 服务”定性，不再检查配置、身份或运行时证据。
- C. 只增加重试次数或机器资源，暂不核对“Attribute 实例不适合保存每请求可变状态，生命周期必须与依赖匹配”。
- D. 以一次成功请求作为结论，不再确认“ServiceFilter、TypeFilter 或实现 IFilterFactory 可让过滤器从 DI 获取依赖”是否成立。
查看答案与解析
正确答案A
场景“应用启动时报 Attribute 没有合适构造函数”指向 过滤器依赖注入，但症状本身不能证明根因。正确排查应先确认边界“Attribute 实例不适合保存每请求可变状态，生命周期必须与依赖匹配”，再用主规则“ServiceFilter、TypeFilter 或实现 IFilterFactory 可让过滤器从 DI 获取依赖”解释证据。直接采用误区“在过滤器 Attribute 构造函数中可直接注入任意 Scoped 服务”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0415 关于 过滤器依赖注入，以下哪项说法不成立？
难度： 实战
- A. ServiceFilter、TypeFilter 或实现 IFilterFactory 可让过滤器从 DI 获取依赖
- B. 在过滤器 Attribute 构造函数中可直接注入任意 Scoped 服务
- C. Attribute 实例不适合保存每请求可变状态，生命周期必须与依赖匹配
- D. 出现“应用启动时报 Attribute 没有合适构造函数”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案B
题目要求选出不成立的说法，答案“在过滤器 Attribute 构造函数中可直接注入任意 Scoped 服务”正是 过滤器依赖注入 的典型误区。其余三项分别给出了主规则“ServiceFilter、TypeFilter 或实现 IFilterFactory 可让过滤器从 DI 获取依赖”、适用边界“Attribute 实例不适合保存每请求可变状态，生命周期必须与依赖匹配”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0416 针对“应用启动时报 Attribute 没有合适构造函数”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“在过滤器 Attribute 构造函数中可直接注入任意 Scoped 服务”修改实现，并把一次请求成功作为验收结果。
- B. 按“ServiceFilter、TypeFilter 或实现 IFilterFactory 可让过滤器从 DI 获取依赖”修改代码后直接上线，不验证“Attribute 实例不适合保存每请求可变状态，生命周期必须与依赖匹配”。
- C. 按“ServiceFilter、TypeFilter 或实现 IFilterFactory 可让过滤器从 DI 获取依赖”修正实现，并用测试或遥测验证“Attribute 实例不适合保存每请求可变状态，生命周期必须与依赖匹配”。
- D. 只验证“Attribute 实例不适合保存每请求可变状态，生命周期必须与依赖匹配”，但实现仍继续依赖“在过滤器 Attribute 构造函数中可直接注入任意 Scoped 服务”。
查看答案与解析
正确答案C
完整决策同时覆盖规则与验证：ServiceFilter、TypeFilter 或实现 IFilterFactory 可让过滤器从 DI 获取依赖；并确认 Attribute 实例不适合保存每请求可变状态，生命周期必须与依赖匹配。继续接受“在过滤器 Attribute 构造函数中可直接注入任意 Scoped 服务”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“应用启动时报 Attribute 没有合适构造函数”这一生产场景能否安全上线。
0417 在 短路 MVC 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 过滤器设置 Result 后 Action 仍会执行但忽略返回值
- B. 短路仍需保证日志、释放和响应语义正确，不能绕过认证授权边界
- C. 观察到“缓存命中后数据库查询仍发生”即可把一次现象当成完整框架契约。
- D. 资源或 Action 过滤器设置 Result 后可跳过后续阶段或 Action
查看答案与解析
正确答案D
正确答案直接描述 短路 MVC 的主规则：资源或 Action 过滤器设置 Result 后可跳过后续阶段或 Action。选项“短路仍需保证日志、释放和响应语义正确，不能绕过认证授权边界”是使用规则时要验证的边界，不是规则本身；“过滤器设置 Result 后 Action 仍会执行但忽略返回值”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0418 缓存命中后数据库查询仍发生。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“过滤器设置 Result 后 Action 仍会执行但忽略返回值”定性，不再检查配置、身份或运行时证据。
- B. 只增加重试次数或机器资源，暂不核对“短路仍需保证日志、释放和响应语义正确，不能绕过认证授权边界”。
- C. 先验证“短路仍需保证日志、释放和响应语义正确，不能绕过认证授权边界”，再依据“资源或 Action 过滤器设置 Result 后可跳过后续阶段或 Action”判断实现是否符合契约。
- D. 以一次成功请求作为结论，不再确认“资源或 Action 过滤器设置 Result 后可跳过后续阶段或 Action”是否成立。
查看答案与解析
正确答案C
场景“缓存命中后数据库查询仍发生”指向 短路 MVC，但症状本身不能证明根因。正确排查应先确认边界“短路仍需保证日志、释放和响应语义正确，不能绕过认证授权边界”，再用主规则“资源或 Action 过滤器设置 Result 后可跳过后续阶段或 Action”解释证据。直接采用误区“过滤器设置 Result 后 Action 仍会执行但忽略返回值”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0419 关于 短路 MVC，以下哪项说法不成立？
难度： 实战
- A. 资源或 Action 过滤器设置 Result 后可跳过后续阶段或 Action
- B. 过滤器设置 Result 后 Action 仍会执行但忽略返回值
- C. 短路仍需保证日志、释放和响应语义正确，不能绕过认证授权边界
- D. 出现“缓存命中后数据库查询仍发生”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案B
题目要求选出不成立的说法，答案“过滤器设置 Result 后 Action 仍会执行但忽略返回值”正是 短路 MVC 的典型误区。其余三项分别给出了主规则“资源或 Action 过滤器设置 Result 后可跳过后续阶段或 Action”、适用边界“短路仍需保证日志、释放和响应语义正确，不能绕过认证授权边界”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0420 针对“缓存命中后数据库查询仍发生”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“资源或 Action 过滤器设置 Result 后可跳过后续阶段或 Action”修正实现，并用测试或遥测验证“短路仍需保证日志、释放和响应语义正确，不能绕过认证授权边界”。
- B. 按“过滤器设置 Result 后 Action 仍会执行但忽略返回值”修改实现，并把一次请求成功作为验收结果。
- C. 按“资源或 Action 过滤器设置 Result 后可跳过后续阶段或 Action”修改代码后直接上线，不验证“短路仍需保证日志、释放和响应语义正确，不能绕过认证授权边界”。
- D. 只验证“短路仍需保证日志、释放和响应语义正确，不能绕过认证授权边界”，但实现仍继续依赖“过滤器设置 Result 后 Action 仍会执行但忽略返回值”。
查看答案与解析
正确答案A
完整决策同时覆盖规则与验证：资源或 Action 过滤器设置 Result 后可跳过后续阶段或 Action；并确认 短路仍需保证日志、释放和响应语义正确，不能绕过认证授权边界。继续接受“过滤器设置 Result 后 Action 仍会执行但忽略返回值”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“缓存命中后数据库查询仍发生”这一生产场景能否安全上线。