ASP.NET Core 试题 20：内容协商与格式化程序
0381 在 Accept 头 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 客户端声明任何 Accept 值时服务器都必须安装对应格式化程序
- B. 默认可能忽略浏览器的宽泛 Accept；是否返回 406 由 ReturnHttpNotAcceptable 等配置决定
- C. 观察到“请求 application/xml 却得到 JSON”即可把一次现象当成完整框架契约。
- D. MVC 内容协商根据 Accept 头和已配置输出格式化程序选择响应格式
查看答案与解析
正确答案D
正确答案直接描述 Accept 头 的主规则：MVC 内容协商根据 Accept 头和已配置输出格式化程序选择响应格式。选项“默认可能忽略浏览器的宽泛 Accept；是否返回 406 由 ReturnHttpNotAcceptable 等配置决定”是使用规则时要验证的边界，不是规则本身；“客户端声明任何 Accept 值时服务器都必须安装对应格式化程序”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0382 请求 application/xml 却得到 JSON。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“客户端声明任何 Accept 值时服务器都必须安装对应格式化程序”定性，不再检查配置、身份或运行时证据。
- B. 先验证“默认可能忽略浏览器的宽泛 Accept；是否返回 406 由 ReturnHttpNotAcceptable 等配置决定”，再依据“MVC 内容协商根据 Accept 头和已配置输出格式化程序选择响应格式”判断实现是否符合契约。
- C. 只增加重试次数或机器资源，暂不核对“默认可能忽略浏览器的宽泛 Accept；是否返回 406 由 ReturnHttpNotAcceptable 等配置决定”。
- D. 以一次成功请求作为结论，不再确认“MVC 内容协商根据 Accept 头和已配置输出格式化程序选择响应格式”是否成立。
查看答案与解析
正确答案B
场景“请求 application/xml 却得到 JSON”指向 Accept 头，但症状本身不能证明根因。正确排查应先确认边界“默认可能忽略浏览器的宽泛 Accept；是否返回 406 由 ReturnHttpNotAcceptable 等配置决定”，再用主规则“MVC 内容协商根据 Accept 头和已配置输出格式化程序选择响应格式”解释证据。直接采用误区“客户端声明任何 Accept 值时服务器都必须安装对应格式化程序”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0383 关于 Accept 头，以下哪项说法不成立？
难度： 实战
- A. 客户端声明任何 Accept 值时服务器都必须安装对应格式化程序
- B. MVC 内容协商根据 Accept 头和已配置输出格式化程序选择响应格式
- C. 默认可能忽略浏览器的宽泛 Accept；是否返回 406 由 ReturnHttpNotAcceptable 等配置决定
- D. 出现“请求 application/xml 却得到 JSON”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案A
题目要求选出不成立的说法，答案“客户端声明任何 Accept 值时服务器都必须安装对应格式化程序”正是 Accept 头 的典型误区。其余三项分别给出了主规则“MVC 内容协商根据 Accept 头和已配置输出格式化程序选择响应格式”、适用边界“默认可能忽略浏览器的宽泛 Accept；是否返回 406 由 ReturnHttpNotAcceptable 等配置决定”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0384 针对“请求 application/xml 却得到 JSON”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“客户端声明任何 Accept 值时服务器都必须安装对应格式化程序”修改实现，并把一次请求成功作为验收结果。
- B. 按“MVC 内容协商根据 Accept 头和已配置输出格式化程序选择响应格式”修改代码后直接上线，不验证“默认可能忽略浏览器的宽泛 Accept；是否返回 406 由 ReturnHttpNotAcceptable 等配置决定”。
- C. 按“MVC 内容协商根据 Accept 头和已配置输出格式化程序选择响应格式”修正实现，并用测试或遥测验证“默认可能忽略浏览器的宽泛 Accept；是否返回 406 由 ReturnHttpNotAcceptable 等配置决定”。
- D. 只验证“默认可能忽略浏览器的宽泛 Accept；是否返回 406 由 ReturnHttpNotAcceptable 等配置决定”，但实现仍继续依赖“客户端声明任何 Accept 值时服务器都必须安装对应格式化程序”。
查看答案与解析
正确答案C
完整决策同时覆盖规则与验证：MVC 内容协商根据 Accept 头和已配置输出格式化程序选择响应格式；并确认 默认可能忽略浏览器的宽泛 Accept；是否返回 406 由 ReturnHttpNotAcceptable 等配置决定。继续接受“客户端声明任何 Accept 值时服务器都必须安装对应格式化程序”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“请求 application/xml 却得到 JSON”这一生产场景能否安全上线。
0385 在 输出格式化程序 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. ObjectResult 由匹配的输出格式化程序序列化，JsonResult 则明确选择 JSON 处理
- B. 把响应 Content-Type 改成 XML 会自动把对象序列化为 XML
- C. 自定义格式必须注册格式化程序并声明支持媒体类型，不能只改 Content-Type
- D. 观察到“响应头声称 XML 而正文仍是 JSON”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案A
正确答案直接描述 输出格式化程序 的主规则：ObjectResult 由匹配的输出格式化程序序列化，JsonResult 则明确选择 JSON 处理。选项“自定义格式必须注册格式化程序并声明支持媒体类型，不能只改 Content-Type”是使用规则时要验证的边界，不是规则本身；“把响应 Content-Type 改成 XML 会自动把对象序列化为 XML”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0386 响应头声称 XML 而正文仍是 JSON。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“把响应 Content-Type 改成 XML 会自动把对象序列化为 XML”定性，不再检查配置、身份或运行时证据。
- B. 先验证“自定义格式必须注册格式化程序并声明支持媒体类型，不能只改 Content-Type”，再依据“ObjectResult 由匹配的输出格式化程序序列化，JsonResult 则明确选择 JSON 处理”判断实现是否符合契约。
- C. 只增加重试次数或机器资源，暂不核对“自定义格式必须注册格式化程序并声明支持媒体类型，不能只改 Content-Type”。
- D. 以一次成功请求作为结论，不再确认“ObjectResult 由匹配的输出格式化程序序列化，JsonResult 则明确选择 JSON 处理”是否成立。
查看答案与解析
正确答案B
场景“响应头声称 XML 而正文仍是 JSON”指向 输出格式化程序，但症状本身不能证明根因。正确排查应先确认边界“自定义格式必须注册格式化程序并声明支持媒体类型，不能只改 Content-Type”，再用主规则“ObjectResult 由匹配的输出格式化程序序列化，JsonResult 则明确选择 JSON 处理”解释证据。直接采用误区“把响应 Content-Type 改成 XML 会自动把对象序列化为 XML”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0387 关于 输出格式化程序，以下哪项说法不成立？
难度： 实战
- A. ObjectResult 由匹配的输出格式化程序序列化，JsonResult 则明确选择 JSON 处理
- B. 自定义格式必须注册格式化程序并声明支持媒体类型，不能只改 Content-Type
- C. 出现“响应头声称 XML 而正文仍是 JSON”时，应收集证据并同时核对主规则与适用边界。
- D. 把响应 Content-Type 改成 XML 会自动把对象序列化为 XML
查看答案与解析
正确答案D
题目要求选出不成立的说法，答案“把响应 Content-Type 改成 XML 会自动把对象序列化为 XML”正是 输出格式化程序 的典型误区。其余三项分别给出了主规则“ObjectResult 由匹配的输出格式化程序序列化，JsonResult 则明确选择 JSON 处理”、适用边界“自定义格式必须注册格式化程序并声明支持媒体类型，不能只改 Content-Type”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0388 针对“响应头声称 XML 而正文仍是 JSON”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“把响应 Content-Type 改成 XML 会自动把对象序列化为 XML”修改实现，并把一次请求成功作为验收结果。
- B. 按“ObjectResult 由匹配的输出格式化程序序列化，JsonResult 则明确选择 JSON 处理”修改代码后直接上线，不验证“自定义格式必须注册格式化程序并声明支持媒体类型，不能只改 Content-Type”。
- C. 按“ObjectResult 由匹配的输出格式化程序序列化，JsonResult 则明确选择 JSON 处理”修正实现，并用测试或遥测验证“自定义格式必须注册格式化程序并声明支持媒体类型，不能只改 Content-Type”。
- D. 只验证“自定义格式必须注册格式化程序并声明支持媒体类型，不能只改 Content-Type”，但实现仍继续依赖“把响应 Content-Type 改成 XML 会自动把对象序列化为 XML”。
查看答案与解析
正确答案C
完整决策同时覆盖规则与验证：ObjectResult 由匹配的输出格式化程序序列化，JsonResult 则明确选择 JSON 处理；并确认 自定义格式必须注册格式化程序并声明支持媒体类型，不能只改 Content-Type。继续接受“把响应 Content-Type 改成 XML 会自动把对象序列化为 XML”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“响应头声称 XML 而正文仍是 JSON”这一生产场景能否安全上线。
0389 在 字符串返回值 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 任何 string 返回值都会自动加引号成为 application/json
- B. 控制器直接返回 string 可能由 StringOutputFormatter 生成 text/plain，而对象包装会走 JSON
- C. API 契约要求 JSON 字符串时应显式返回 JsonResult 或对象结果
- D. 观察到“客户端 JSON 解析器收到纯文本失败”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案B
正确答案直接描述 字符串返回值 的主规则：控制器直接返回 string 可能由 StringOutputFormatter 生成 text/plain，而对象包装会走 JSON。选项“API 契约要求 JSON 字符串时应显式返回 JsonResult 或对象结果”是使用规则时要验证的边界，不是规则本身；“任何 string 返回值都会自动加引号成为 application/json”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0390 客户端 JSON 解析器收到纯文本失败。排查时哪项动作最合理？
难度： 进阶
- A. 先验证“API 契约要求 JSON 字符串时应显式返回 JsonResult 或对象结果”，再依据“控制器直接返回 string 可能由 StringOutputFormatter 生成 text/plain，而对象包装会走 JSON”判断实现是否符合契约。
- B. 直接按“任何 string 返回值都会自动加引号成为 application/json”定性，不再检查配置、身份或运行时证据。
- C. 只增加重试次数或机器资源，暂不核对“API 契约要求 JSON 字符串时应显式返回 JsonResult 或对象结果”。
- D. 以一次成功请求作为结论，不再确认“控制器直接返回 string 可能由 StringOutputFormatter 生成 text/plain，而对象包装会走 JSON”是否成立。
查看答案与解析
正确答案A
场景“客户端 JSON 解析器收到纯文本失败”指向 字符串返回值，但症状本身不能证明根因。正确排查应先确认边界“API 契约要求 JSON 字符串时应显式返回 JsonResult 或对象结果”，再用主规则“控制器直接返回 string 可能由 StringOutputFormatter 生成 text/plain，而对象包装会走 JSON”解释证据。直接采用误区“任何 string 返回值都会自动加引号成为 application/json”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0391 关于 字符串返回值，以下哪项说法不成立？
难度： 实战
- A. 控制器直接返回 string 可能由 StringOutputFormatter 生成 text/plain，而对象包装会走 JSON
- B. API 契约要求 JSON 字符串时应显式返回 JsonResult 或对象结果
- C. 任何 string 返回值都会自动加引号成为 application/json
- D. 出现“客户端 JSON 解析器收到纯文本失败”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案C
题目要求选出不成立的说法，答案“任何 string 返回值都会自动加引号成为 application/json”正是 字符串返回值 的典型误区。其余三项分别给出了主规则“控制器直接返回 string 可能由 StringOutputFormatter 生成 text/plain，而对象包装会走 JSON”、适用边界“API 契约要求 JSON 字符串时应显式返回 JsonResult 或对象结果”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0392 针对“客户端 JSON 解析器收到纯文本失败”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“任何 string 返回值都会自动加引号成为 application/json”修改实现，并把一次请求成功作为验收结果。
- B. 按“控制器直接返回 string 可能由 StringOutputFormatter 生成 text/plain，而对象包装会走 JSON”修改代码后直接上线，不验证“API 契约要求 JSON 字符串时应显式返回 JsonResult 或对象结果”。
- C. 只验证“API 契约要求 JSON 字符串时应显式返回 JsonResult 或对象结果”，但实现仍继续依赖“任何 string 返回值都会自动加引号成为 application/json”。
- D. 按“控制器直接返回 string 可能由 StringOutputFormatter 生成 text/plain，而对象包装会走 JSON”修正实现，并用测试或遥测验证“API 契约要求 JSON 字符串时应显式返回 JsonResult 或对象结果”。
查看答案与解析
正确答案D
完整决策同时覆盖规则与验证：控制器直接返回 string 可能由 StringOutputFormatter 生成 text/plain，而对象包装会走 JSON；并确认 API 契约要求 JSON 字符串时应显式返回 JsonResult 或对象结果。继续接受“任何 string 返回值都会自动加引号成为 application/json”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“客户端 JSON 解析器收到纯文本失败”这一生产场景能否安全上线。
0393 在 输入格式化程序 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. Accept: application/json 会强制服务器按 JSON 解析请求正文
- B. FromBody 参数由与请求 Content-Type 匹配的输入格式化程序读取
- C. Content-Type 描述实际正文格式，Accept 描述期望响应，两者不能混用
- D. 观察到“发送 XML 正文但只设置 Accept 后得到 415”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案B
正确答案直接描述 输入格式化程序 的主规则：FromBody 参数由与请求 Content-Type 匹配的输入格式化程序读取。选项“Content-Type 描述实际正文格式，Accept 描述期望响应，两者不能混用”是使用规则时要验证的边界，不是规则本身；“Accept: application/json 会强制服务器按 JSON 解析请求正文”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0394 发送 XML 正文但只设置 Accept 后得到 415。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“Accept: application/json 会强制服务器按 JSON 解析请求正文”定性，不再检查配置、身份或运行时证据。
- B. 只增加重试次数或机器资源，暂不核对“Content-Type 描述实际正文格式，Accept 描述期望响应，两者不能混用”。
- C. 以一次成功请求作为结论，不再确认“FromBody 参数由与请求 Content-Type 匹配的输入格式化程序读取”是否成立。
- D. 先验证“Content-Type 描述实际正文格式，Accept 描述期望响应，两者不能混用”，再依据“FromBody 参数由与请求 Content-Type 匹配的输入格式化程序读取”判断实现是否符合契约。
查看答案与解析
正确答案D
场景“发送 XML 正文但只设置 Accept 后得到 415”指向 输入格式化程序，但症状本身不能证明根因。正确排查应先确认边界“Content-Type 描述实际正文格式，Accept 描述期望响应，两者不能混用”，再用主规则“FromBody 参数由与请求 Content-Type 匹配的输入格式化程序读取”解释证据。直接采用误区“Accept: application/json 会强制服务器按 JSON 解析请求正文”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0395 关于 输入格式化程序，以下哪项说法不成立？
难度： 实战
- A. FromBody 参数由与请求 Content-Type 匹配的输入格式化程序读取
- B. Content-Type 描述实际正文格式，Accept 描述期望响应，两者不能混用
- C. Accept: application/json 会强制服务器按 JSON 解析请求正文
- D. 出现“发送 XML 正文但只设置 Accept 后得到 415”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案C
题目要求选出不成立的说法，答案“Accept: application/json 会强制服务器按 JSON 解析请求正文”正是 输入格式化程序 的典型误区。其余三项分别给出了主规则“FromBody 参数由与请求 Content-Type 匹配的输入格式化程序读取”、适用边界“Content-Type 描述实际正文格式，Accept 描述期望响应，两者不能混用”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0396 针对“发送 XML 正文但只设置 Accept 后得到 415”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“FromBody 参数由与请求 Content-Type 匹配的输入格式化程序读取”修正实现，并用测试或遥测验证“Content-Type 描述实际正文格式，Accept 描述期望响应，两者不能混用”。
- B. 按“Accept: application/json 会强制服务器按 JSON 解析请求正文”修改实现，并把一次请求成功作为验收结果。
- C. 按“FromBody 参数由与请求 Content-Type 匹配的输入格式化程序读取”修改代码后直接上线，不验证“Content-Type 描述实际正文格式，Accept 描述期望响应，两者不能混用”。
- D. 只验证“Content-Type 描述实际正文格式，Accept 描述期望响应，两者不能混用”，但实现仍继续依赖“Accept: application/json 会强制服务器按 JSON 解析请求正文”。
查看答案与解析
正确答案A
完整决策同时覆盖规则与验证：FromBody 参数由与请求 Content-Type 匹配的输入格式化程序读取；并确认 Content-Type 描述实际正文格式，Accept 描述期望响应，两者不能混用。继续接受“Accept: application/json 会强制服务器按 JSON 解析请求正文”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“发送 XML 正文但只设置 Accept 后得到 415”这一生产场景能否安全上线。
0397 在 格式协商与缓存 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 内容协商只发生在客户端，不影响服务器缓存键
- B. API 和缓存层必须共同验证媒体类型维度，不能只按 URL 缓存所有表示
- C. 同一 URL 因 Accept 返回不同表示时，代理缓存需要正确处理 Vary 等语义
- D. 观察到“JSON 请求拿到先前缓存的 XML 正文”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案C
正确答案直接描述 格式协商与缓存 的主规则：同一 URL 因 Accept 返回不同表示时，代理缓存需要正确处理 Vary 等语义。选项“API 和缓存层必须共同验证媒体类型维度，不能只按 URL 缓存所有表示”是使用规则时要验证的边界，不是规则本身；“内容协商只发生在客户端，不影响服务器缓存键”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0398 JSON 请求拿到先前缓存的 XML 正文。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“内容协商只发生在客户端，不影响服务器缓存键”定性，不再检查配置、身份或运行时证据。
- B. 只增加重试次数或机器资源，暂不核对“API 和缓存层必须共同验证媒体类型维度，不能只按 URL 缓存所有表示”。
- C. 以一次成功请求作为结论，不再确认“同一 URL 因 Accept 返回不同表示时，代理缓存需要正确处理 Vary 等语义”是否成立。
- D. 先验证“API 和缓存层必须共同验证媒体类型维度，不能只按 URL 缓存所有表示”，再依据“同一 URL 因 Accept 返回不同表示时，代理缓存需要正确处理 Vary 等语义”判断实现是否符合契约。
查看答案与解析
正确答案D
场景“JSON 请求拿到先前缓存的 XML 正文”指向 格式协商与缓存，但症状本身不能证明根因。正确排查应先确认边界“API 和缓存层必须共同验证媒体类型维度，不能只按 URL 缓存所有表示”，再用主规则“同一 URL 因 Accept 返回不同表示时，代理缓存需要正确处理 Vary 等语义”解释证据。直接采用误区“内容协商只发生在客户端，不影响服务器缓存键”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0399 关于 格式协商与缓存，以下哪项说法不成立？
难度： 实战
- A. 内容协商只发生在客户端，不影响服务器缓存键
- B. 同一 URL 因 Accept 返回不同表示时，代理缓存需要正确处理 Vary 等语义
- C. API 和缓存层必须共同验证媒体类型维度，不能只按 URL 缓存所有表示
- D. 出现“JSON 请求拿到先前缓存的 XML 正文”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案A
题目要求选出不成立的说法，答案“内容协商只发生在客户端，不影响服务器缓存键”正是 格式协商与缓存 的典型误区。其余三项分别给出了主规则“同一 URL 因 Accept 返回不同表示时，代理缓存需要正确处理 Vary 等语义”、适用边界“API 和缓存层必须共同验证媒体类型维度，不能只按 URL 缓存所有表示”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0400 针对“JSON 请求拿到先前缓存的 XML 正文”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“内容协商只发生在客户端，不影响服务器缓存键”修改实现，并把一次请求成功作为验收结果。
- B. 按“同一 URL 因 Accept 返回不同表示时，代理缓存需要正确处理 Vary 等语义”修正实现，并用测试或遥测验证“API 和缓存层必须共同验证媒体类型维度，不能只按 URL 缓存所有表示”。
- C. 按“同一 URL 因 Accept 返回不同表示时，代理缓存需要正确处理 Vary 等语义”修改代码后直接上线，不验证“API 和缓存层必须共同验证媒体类型维度，不能只按 URL 缓存所有表示”。
- D. 只验证“API 和缓存层必须共同验证媒体类型维度，不能只按 URL 缓存所有表示”，但实现仍继续依赖“内容协商只发生在客户端，不影响服务器缓存键”。
查看答案与解析
正确答案B
完整决策同时覆盖规则与验证：同一 URL 因 Accept 返回不同表示时，代理缓存需要正确处理 Vary 等语义；并确认 API 和缓存层必须共同验证媒体类型维度，不能只按 URL 缓存所有表示。继续接受“内容协商只发生在客户端，不影响服务器缓存键”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“JSON 请求拿到先前缓存的 XML 正文”这一生产场景能否安全上线。