ASP.NET Core 试题 18：MVC 模型绑定
0341 在 绑定来源 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 复杂类型一定来自请求正文，简单类型一定来自路由
- B. 模型绑定可从表单、正文、路由、查询和文件等来源获取数据，ApiController 会推断部分来源
- C. 安全敏感或易歧义参数应显式使用 FromRoute、FromQuery、FromBody 等标注
- D. 观察到“查询 DTO 被错误当作正文读取”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案B
正确答案直接描述 绑定来源 的主规则：模型绑定可从表单、正文、路由、查询和文件等来源获取数据，ApiController 会推断部分来源。选项“安全敏感或易歧义参数应显式使用 FromRoute、FromQuery、FromBody 等标注”是使用规则时要验证的边界，不是规则本身；“复杂类型一定来自请求正文，简单类型一定来自路由”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0342 查询 DTO 被错误当作正文读取。排查时哪项动作最合理？
难度： 进阶
- A. 先验证“安全敏感或易歧义参数应显式使用 FromRoute、FromQuery、FromBody 等标注”，再依据“模型绑定可从表单、正文、路由、查询和文件等来源获取数据，ApiController 会推断部分来源”判断实现是否符合契约。
- B. 直接按“复杂类型一定来自请求正文，简单类型一定来自路由”定性，不再检查配置、身份或运行时证据。
- C. 只增加重试次数或机器资源，暂不核对“安全敏感或易歧义参数应显式使用 FromRoute、FromQuery、FromBody 等标注”。
- D. 以一次成功请求作为结论，不再确认“模型绑定可从表单、正文、路由、查询和文件等来源获取数据，ApiController 会推断部分来源”是否成立。
查看答案与解析
正确答案A
场景“查询 DTO 被错误当作正文读取”指向 绑定来源，但症状本身不能证明根因。正确排查应先确认边界“安全敏感或易歧义参数应显式使用 FromRoute、FromQuery、FromBody 等标注”，再用主规则“模型绑定可从表单、正文、路由、查询和文件等来源获取数据，ApiController 会推断部分来源”解释证据。直接采用误区“复杂类型一定来自请求正文，简单类型一定来自路由”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0343 关于 绑定来源，以下哪项说法不成立？
难度： 实战
- A. 模型绑定可从表单、正文、路由、查询和文件等来源获取数据，ApiController 会推断部分来源
- B. 安全敏感或易歧义参数应显式使用 FromRoute、FromQuery、FromBody 等标注
- C. 复杂类型一定来自请求正文，简单类型一定来自路由
- D. 出现“查询 DTO 被错误当作正文读取”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案C
题目要求选出不成立的说法，答案“复杂类型一定来自请求正文，简单类型一定来自路由”正是 绑定来源 的典型误区。其余三项分别给出了主规则“模型绑定可从表单、正文、路由、查询和文件等来源获取数据，ApiController 会推断部分来源”、适用边界“安全敏感或易歧义参数应显式使用 FromRoute、FromQuery、FromBody 等标注”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0344 针对“查询 DTO 被错误当作正文读取”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“复杂类型一定来自请求正文，简单类型一定来自路由”修改实现，并把一次请求成功作为验收结果。
- B. 按“模型绑定可从表单、正文、路由、查询和文件等来源获取数据，ApiController 会推断部分来源”修改代码后直接上线，不验证“安全敏感或易歧义参数应显式使用 FromRoute、FromQuery、FromBody 等标注”。
- C. 只验证“安全敏感或易歧义参数应显式使用 FromRoute、FromQuery、FromBody 等标注”，但实现仍继续依赖“复杂类型一定来自请求正文，简单类型一定来自路由”。
- D. 按“模型绑定可从表单、正文、路由、查询和文件等来源获取数据，ApiController 会推断部分来源”修正实现，并用测试或遥测验证“安全敏感或易歧义参数应显式使用 FromRoute、FromQuery、FromBody 等标注”。
查看答案与解析
正确答案D
完整决策同时覆盖规则与验证：模型绑定可从表单、正文、路由、查询和文件等来源获取数据，ApiController 会推断部分来源；并确认 安全敏感或易歧义参数应显式使用 FromRoute、FromQuery、FromBody 等标注。继续接受“复杂类型一定来自请求正文，简单类型一定来自路由”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“查询 DTO 被错误当作正文读取”这一生产场景能否安全上线。
0345 在 单个请求正文 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 多个 FromBody 参数会按声明顺序分别反序列化同一 JSON
- B. 请求正文通常只能由输入格式化程序读取一次，因此一个 Action 不应有多个 FromBody 参数
- C. 需要多个对象时应组合请求 DTO，读取原始流则要明确缓冲和大小限制
- D. 观察到“应用启动时报 Action 定义无效”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案B
正确答案直接描述 单个请求正文 的主规则：请求正文通常只能由输入格式化程序读取一次，因此一个 Action 不应有多个 FromBody 参数。选项“需要多个对象时应组合请求 DTO，读取原始流则要明确缓冲和大小限制”是使用规则时要验证的边界，不是规则本身；“多个 FromBody 参数会按声明顺序分别反序列化同一 JSON”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0346 应用启动时报 Action 定义无效。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“多个 FromBody 参数会按声明顺序分别反序列化同一 JSON”定性，不再检查配置、身份或运行时证据。
- B. 只增加重试次数或机器资源，暂不核对“需要多个对象时应组合请求 DTO，读取原始流则要明确缓冲和大小限制”。
- C. 以一次成功请求作为结论，不再确认“请求正文通常只能由输入格式化程序读取一次，因此一个 Action 不应有多个 FromBody 参数”是否成立。
- D. 先验证“需要多个对象时应组合请求 DTO，读取原始流则要明确缓冲和大小限制”，再依据“请求正文通常只能由输入格式化程序读取一次，因此一个 Action 不应有多个 FromBody 参数”判断实现是否符合契约。
查看答案与解析
正确答案D
场景“应用启动时报 Action 定义无效”指向 单个请求正文，但症状本身不能证明根因。正确排查应先确认边界“需要多个对象时应组合请求 DTO，读取原始流则要明确缓冲和大小限制”，再用主规则“请求正文通常只能由输入格式化程序读取一次，因此一个 Action 不应有多个 FromBody 参数”解释证据。直接采用误区“多个 FromBody 参数会按声明顺序分别反序列化同一 JSON”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0347 关于 单个请求正文，以下哪项说法不成立？
难度： 实战
- A. 请求正文通常只能由输入格式化程序读取一次，因此一个 Action 不应有多个 FromBody 参数
- B. 需要多个对象时应组合请求 DTO，读取原始流则要明确缓冲和大小限制
- C. 多个 FromBody 参数会按声明顺序分别反序列化同一 JSON
- D. 出现“应用启动时报 Action 定义无效”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案C
题目要求选出不成立的说法，答案“多个 FromBody 参数会按声明顺序分别反序列化同一 JSON”正是 单个请求正文 的典型误区。其余三项分别给出了主规则“请求正文通常只能由输入格式化程序读取一次，因此一个 Action 不应有多个 FromBody 参数”、适用边界“需要多个对象时应组合请求 DTO，读取原始流则要明确缓冲和大小限制”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0348 针对“应用启动时报 Action 定义无效”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“请求正文通常只能由输入格式化程序读取一次，因此一个 Action 不应有多个 FromBody 参数”修正实现，并用测试或遥测验证“需要多个对象时应组合请求 DTO，读取原始流则要明确缓冲和大小限制”。
- B. 按“多个 FromBody 参数会按声明顺序分别反序列化同一 JSON”修改实现，并把一次请求成功作为验收结果。
- C. 按“请求正文通常只能由输入格式化程序读取一次，因此一个 Action 不应有多个 FromBody 参数”修改代码后直接上线，不验证“需要多个对象时应组合请求 DTO，读取原始流则要明确缓冲和大小限制”。
- D. 只验证“需要多个对象时应组合请求 DTO，读取原始流则要明确缓冲和大小限制”，但实现仍继续依赖“多个 FromBody 参数会按声明顺序分别反序列化同一 JSON”。
查看答案与解析
正确答案A
完整决策同时覆盖规则与验证：请求正文通常只能由输入格式化程序读取一次，因此一个 Action 不应有多个 FromBody 参数；并确认 需要多个对象时应组合请求 DTO，读取原始流则要明确缓冲和大小限制。继续接受“多个 FromBody 参数会按声明顺序分别反序列化同一 JSON”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“应用启动时报 Action 定义无效”这一生产场景能否安全上线。
0349 在 绑定失败与验证失败 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. int 转换失败后模型属性默认为零且 ModelState 仍有效
- B. 应区分语法格式、字段验证和领域冲突并返回合适错误
- C. 类型转换失败会记录 ModelState 错误，成功绑定不代表业务数据有效
- D. 观察到“非法数字被当作有效零值写入数据库”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案C
正确答案直接描述 绑定失败与验证失败 的主规则：类型转换失败会记录 ModelState 错误，成功绑定不代表业务数据有效。选项“应区分语法格式、字段验证和领域冲突并返回合适错误”是使用规则时要验证的边界，不是规则本身；“int 转换失败后模型属性默认为零且 ModelState 仍有效”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0350 非法数字被当作有效零值写入数据库。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“int 转换失败后模型属性默认为零且 ModelState 仍有效”定性，不再检查配置、身份或运行时证据。
- B. 只增加重试次数或机器资源，暂不核对“应区分语法格式、字段验证和领域冲突并返回合适错误”。
- C. 以一次成功请求作为结论，不再确认“类型转换失败会记录 ModelState 错误，成功绑定不代表业务数据有效”是否成立。
- D. 先验证“应区分语法格式、字段验证和领域冲突并返回合适错误”，再依据“类型转换失败会记录 ModelState 错误，成功绑定不代表业务数据有效”判断实现是否符合契约。
查看答案与解析
正确答案D
场景“非法数字被当作有效零值写入数据库”指向 绑定失败与验证失败，但症状本身不能证明根因。正确排查应先确认边界“应区分语法格式、字段验证和领域冲突并返回合适错误”，再用主规则“类型转换失败会记录 ModelState 错误，成功绑定不代表业务数据有效”解释证据。直接采用误区“int 转换失败后模型属性默认为零且 ModelState 仍有效”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0351 关于 绑定失败与验证失败，以下哪项说法不成立？
难度： 实战
- A. int 转换失败后模型属性默认为零且 ModelState 仍有效
- B. 类型转换失败会记录 ModelState 错误，成功绑定不代表业务数据有效
- C. 应区分语法格式、字段验证和领域冲突并返回合适错误
- D. 出现“非法数字被当作有效零值写入数据库”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案A
题目要求选出不成立的说法，答案“int 转换失败后模型属性默认为零且 ModelState 仍有效”正是 绑定失败与验证失败 的典型误区。其余三项分别给出了主规则“类型转换失败会记录 ModelState 错误，成功绑定不代表业务数据有效”、适用边界“应区分语法格式、字段验证和领域冲突并返回合适错误”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0352 针对“非法数字被当作有效零值写入数据库”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“int 转换失败后模型属性默认为零且 ModelState 仍有效”修改实现，并把一次请求成功作为验收结果。
- B. 按“类型转换失败会记录 ModelState 错误，成功绑定不代表业务数据有效”修正实现，并用测试或遥测验证“应区分语法格式、字段验证和领域冲突并返回合适错误”。
- C. 按“类型转换失败会记录 ModelState 错误，成功绑定不代表业务数据有效”修改代码后直接上线，不验证“应区分语法格式、字段验证和领域冲突并返回合适错误”。
- D. 只验证“应区分语法格式、字段验证和领域冲突并返回合适错误”，但实现仍继续依赖“int 转换失败后模型属性默认为零且 ModelState 仍有效”。
查看答案与解析
正确答案B
完整决策同时覆盖规则与验证：类型转换失败会记录 ModelState 错误，成功绑定不代表业务数据有效；并确认 应区分语法格式、字段验证和领域冲突并返回合适错误。继续接受“int 转换失败后模型属性默认为零且 ModelState 仍有效”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“非法数字被当作有效零值写入数据库”这一生产场景能否安全上线。
0353 在 集合绑定 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 任意稀疏索引都会被自动压缩且不丢元素
- B. 客户端与服务端应约定稳定格式，大数据集合还要限制数量和正文大小
- C. 观察到“表单索引从 0 跳到 2 后第三项未绑定”即可把一次现象当成完整框架契约。
- D. 集合可使用重复键、下标等约定绑定，但索引间断和命名冲突可能丢失后续元素
查看答案与解析
正确答案D
正确答案直接描述 集合绑定 的主规则：集合可使用重复键、下标等约定绑定，但索引间断和命名冲突可能丢失后续元素。选项“客户端与服务端应约定稳定格式，大数据集合还要限制数量和正文大小”是使用规则时要验证的边界，不是规则本身；“任意稀疏索引都会被自动压缩且不丢元素”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0354 表单索引从 0 跳到 2 后第三项未绑定。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“任意稀疏索引都会被自动压缩且不丢元素”定性，不再检查配置、身份或运行时证据。
- B. 先验证“客户端与服务端应约定稳定格式，大数据集合还要限制数量和正文大小”，再依据“集合可使用重复键、下标等约定绑定，但索引间断和命名冲突可能丢失后续元素”判断实现是否符合契约。
- C. 只增加重试次数或机器资源，暂不核对“客户端与服务端应约定稳定格式，大数据集合还要限制数量和正文大小”。
- D. 以一次成功请求作为结论，不再确认“集合可使用重复键、下标等约定绑定，但索引间断和命名冲突可能丢失后续元素”是否成立。
查看答案与解析
正确答案B
场景“表单索引从 0 跳到 2 后第三项未绑定”指向 集合绑定，但症状本身不能证明根因。正确排查应先确认边界“客户端与服务端应约定稳定格式，大数据集合还要限制数量和正文大小”，再用主规则“集合可使用重复键、下标等约定绑定，但索引间断和命名冲突可能丢失后续元素”解释证据。直接采用误区“任意稀疏索引都会被自动压缩且不丢元素”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0355 关于 集合绑定，以下哪项说法不成立？
难度： 实战
- A. 集合可使用重复键、下标等约定绑定，但索引间断和命名冲突可能丢失后续元素
- B. 客户端与服务端应约定稳定格式，大数据集合还要限制数量和正文大小
- C. 任意稀疏索引都会被自动压缩且不丢元素
- D. 出现“表单索引从 0 跳到 2 后第三项未绑定”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案C
题目要求选出不成立的说法，答案“任意稀疏索引都会被自动压缩且不丢元素”正是 集合绑定 的典型误区。其余三项分别给出了主规则“集合可使用重复键、下标等约定绑定，但索引间断和命名冲突可能丢失后续元素”、适用边界“客户端与服务端应约定稳定格式，大数据集合还要限制数量和正文大小”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0356 针对“表单索引从 0 跳到 2 后第三项未绑定”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“集合可使用重复键、下标等约定绑定，但索引间断和命名冲突可能丢失后续元素”修正实现，并用测试或遥测验证“客户端与服务端应约定稳定格式，大数据集合还要限制数量和正文大小”。
- B. 按“任意稀疏索引都会被自动压缩且不丢元素”修改实现，并把一次请求成功作为验收结果。
- C. 按“集合可使用重复键、下标等约定绑定，但索引间断和命名冲突可能丢失后续元素”修改代码后直接上线，不验证“客户端与服务端应约定稳定格式，大数据集合还要限制数量和正文大小”。
- D. 只验证“客户端与服务端应约定稳定格式，大数据集合还要限制数量和正文大小”，但实现仍继续依赖“任意稀疏索引都会被自动压缩且不丢元素”。
查看答案与解析
正确答案A
完整决策同时覆盖规则与验证：集合可使用重复键、下标等约定绑定，但索引间断和命名冲突可能丢失后续元素；并确认 客户端与服务端应约定稳定格式，大数据集合还要限制数量和正文大小。继续接受“任意稀疏索引都会被自动压缩且不丢元素”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“表单索引从 0 跳到 2 后第三项未绑定”这一生产场景能否安全上线。
0357 在 自定义模型绑定器 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. IModelBinder 适合把请求表示转换为应用类型，并通过 Provider 控制适用类型
- B. 自定义绑定器是执行数据库写入和事务提交的首选位置
- C. 绑定器应专注转换，远程查询和业务授权应留在后续层
- D. 观察到“同一请求因为重新绑定而重复修改数据”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案A
正确答案直接描述 自定义模型绑定器 的主规则：IModelBinder 适合把请求表示转换为应用类型，并通过 Provider 控制适用类型。选项“绑定器应专注转换，远程查询和业务授权应留在后续层”是使用规则时要验证的边界，不是规则本身；“自定义绑定器是执行数据库写入和事务提交的首选位置”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0358 同一请求因为重新绑定而重复修改数据。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“自定义绑定器是执行数据库写入和事务提交的首选位置”定性，不再检查配置、身份或运行时证据。
- B. 只增加重试次数或机器资源，暂不核对“绑定器应专注转换，远程查询和业务授权应留在后续层”。
- C. 先验证“绑定器应专注转换，远程查询和业务授权应留在后续层”，再依据“IModelBinder 适合把请求表示转换为应用类型，并通过 Provider 控制适用类型”判断实现是否符合契约。
- D. 以一次成功请求作为结论，不再确认“IModelBinder 适合把请求表示转换为应用类型，并通过 Provider 控制适用类型”是否成立。
查看答案与解析
正确答案C
场景“同一请求因为重新绑定而重复修改数据”指向 自定义模型绑定器，但症状本身不能证明根因。正确排查应先确认边界“绑定器应专注转换，远程查询和业务授权应留在后续层”，再用主规则“IModelBinder 适合把请求表示转换为应用类型，并通过 Provider 控制适用类型”解释证据。直接采用误区“自定义绑定器是执行数据库写入和事务提交的首选位置”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0359 关于 自定义模型绑定器，以下哪项说法不成立？
难度： 实战
- A. IModelBinder 适合把请求表示转换为应用类型，并通过 Provider 控制适用类型
- B. 自定义绑定器是执行数据库写入和事务提交的首选位置
- C. 绑定器应专注转换，远程查询和业务授权应留在后续层
- D. 出现“同一请求因为重新绑定而重复修改数据”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案B
题目要求选出不成立的说法，答案“自定义绑定器是执行数据库写入和事务提交的首选位置”正是 自定义模型绑定器 的典型误区。其余三项分别给出了主规则“IModelBinder 适合把请求表示转换为应用类型，并通过 Provider 控制适用类型”、适用边界“绑定器应专注转换，远程查询和业务授权应留在后续层”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0360 针对“同一请求因为重新绑定而重复修改数据”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“自定义绑定器是执行数据库写入和事务提交的首选位置”修改实现，并把一次请求成功作为验收结果。
- B. 按“IModelBinder 适合把请求表示转换为应用类型，并通过 Provider 控制适用类型”修改代码后直接上线，不验证“绑定器应专注转换，远程查询和业务授权应留在后续层”。
- C. 只验证“绑定器应专注转换，远程查询和业务授权应留在后续层”，但实现仍继续依赖“自定义绑定器是执行数据库写入和事务提交的首选位置”。
- D. 按“IModelBinder 适合把请求表示转换为应用类型，并通过 Provider 控制适用类型”修正实现，并用测试或遥测验证“绑定器应专注转换，远程查询和业务授权应留在后续层”。
查看答案与解析
正确答案D
完整决策同时覆盖规则与验证：IModelBinder 适合把请求表示转换为应用类型，并通过 Provider 控制适用类型；并确认 绑定器应专注转换，远程查询和业务授权应留在后续层。继续接受“自定义绑定器是执行数据库写入和事务提交的首选位置”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“同一请求因为重新绑定而重复修改数据”这一生产场景能否安全上线。