ASP.NET Core 试题 41：gRPC 服务
0801 在 Protocol Buffers 契约 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 重命名字段后可以把原编号立即分配给不同语义字段
- B. 已发布字段编号不能重用，删除字段应 reserved，演进还需兼容旧客户端
- C. 观察到“旧客户端把新数据解析成错误字段”即可把一次现象当成完整框架契约。
- D. gRPC 使用 proto 文件声明服务、消息和字段编号，并生成强类型客户端与服务端代码
查看答案与解析
正确答案D
正确答案直接描述 Protocol Buffers 契约 的主规则：gRPC 使用 proto 文件声明服务、消息和字段编号，并生成强类型客户端与服务端代码。选项“已发布字段编号不能重用，删除字段应 reserved，演进还需兼容旧客户端”是使用规则时要验证的边界，不是规则本身；“重命名字段后可以把原编号立即分配给不同语义字段”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0802 旧客户端把新数据解析成错误字段。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“重命名字段后可以把原编号立即分配给不同语义字段”定性，不再检查配置、身份或运行时证据。
- B. 只增加重试次数或机器资源，暂不核对“已发布字段编号不能重用，删除字段应 reserved，演进还需兼容旧客户端”。
- C. 先验证“已发布字段编号不能重用，删除字段应 reserved，演进还需兼容旧客户端”，再依据“gRPC 使用 proto 文件声明服务、消息和字段编号，并生成强类型客户端与服务端代码”判断实现是否符合契约。
- D. 以一次成功请求作为结论，不再确认“gRPC 使用 proto 文件声明服务、消息和字段编号，并生成强类型客户端与服务端代码”是否成立。
查看答案与解析
正确答案C
场景“旧客户端把新数据解析成错误字段”指向 Protocol Buffers 契约，但症状本身不能证明根因。正确排查应先确认边界“已发布字段编号不能重用，删除字段应 reserved，演进还需兼容旧客户端”，再用主规则“gRPC 使用 proto 文件声明服务、消息和字段编号，并生成强类型客户端与服务端代码”解释证据。直接采用误区“重命名字段后可以把原编号立即分配给不同语义字段”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0803 关于 Protocol Buffers 契约，以下哪项说法不成立？
难度： 实战
- A. gRPC 使用 proto 文件声明服务、消息和字段编号，并生成强类型客户端与服务端代码
- B. 重命名字段后可以把原编号立即分配给不同语义字段
- C. 已发布字段编号不能重用，删除字段应 reserved，演进还需兼容旧客户端
- D. 出现“旧客户端把新数据解析成错误字段”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案B
题目要求选出不成立的说法，答案“重命名字段后可以把原编号立即分配给不同语义字段”正是 Protocol Buffers 契约 的典型误区。其余三项分别给出了主规则“gRPC 使用 proto 文件声明服务、消息和字段编号，并生成强类型客户端与服务端代码”、适用边界“已发布字段编号不能重用，删除字段应 reserved，演进还需兼容旧客户端”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0804 针对“旧客户端把新数据解析成错误字段”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“gRPC 使用 proto 文件声明服务、消息和字段编号，并生成强类型客户端与服务端代码”修正实现，并用测试或遥测验证“已发布字段编号不能重用，删除字段应 reserved，演进还需兼容旧客户端”。
- B. 按“重命名字段后可以把原编号立即分配给不同语义字段”修改实现，并把一次请求成功作为验收结果。
- C. 按“gRPC 使用 proto 文件声明服务、消息和字段编号，并生成强类型客户端与服务端代码”修改代码后直接上线，不验证“已发布字段编号不能重用，删除字段应 reserved，演进还需兼容旧客户端”。
- D. 只验证“已发布字段编号不能重用，删除字段应 reserved，演进还需兼容旧客户端”，但实现仍继续依赖“重命名字段后可以把原编号立即分配给不同语义字段”。
查看答案与解析
正确答案A
完整决策同时覆盖规则与验证：gRPC 使用 proto 文件声明服务、消息和字段编号，并生成强类型客户端与服务端代码；并确认 已发布字段编号不能重用，删除字段应 reserved，演进还需兼容旧客户端。继续接受“重命名字段后可以把原编号立即分配给不同语义字段”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“旧客户端把新数据解析成错误字段”这一生产场景能否安全上线。
0805 在 HTTP/2 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 标准 ASP.NET Core gRPC 通常依赖 HTTP/2，TLS 与终结点协议配置会影响协商
- B. gRPC 会自动把任何 HTTP/1.1 连接升级且无须代理支持
- C. 代理和负载均衡器必须端到端支持所需 gRPC 协议，不能按普通 HTTP/1.1 转发
- D. 观察到“经过旧代理后调用返回协议错误”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案A
正确答案直接描述 HTTP/2 的主规则：标准 ASP.NET Core gRPC 通常依赖 HTTP/2，TLS 与终结点协议配置会影响协商。选项“代理和负载均衡器必须端到端支持所需 gRPC 协议，不能按普通 HTTP/1.1 转发”是使用规则时要验证的边界，不是规则本身；“gRPC 会自动把任何 HTTP/1.1 连接升级且无须代理支持”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0806 经过旧代理后调用返回协议错误。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“gRPC 会自动把任何 HTTP/1.1 连接升级且无须代理支持”定性，不再检查配置、身份或运行时证据。
- B. 只增加重试次数或机器资源，暂不核对“代理和负载均衡器必须端到端支持所需 gRPC 协议，不能按普通 HTTP/1.1 转发”。
- C. 以一次成功请求作为结论，不再确认“标准 ASP.NET Core gRPC 通常依赖 HTTP/2，TLS 与终结点协议配置会影响协商”是否成立。
- D. 先验证“代理和负载均衡器必须端到端支持所需 gRPC 协议，不能按普通 HTTP/1.1 转发”，再依据“标准 ASP.NET Core gRPC 通常依赖 HTTP/2，TLS 与终结点协议配置会影响协商”判断实现是否符合契约。
查看答案与解析
正确答案D
场景“经过旧代理后调用返回协议错误”指向 HTTP/2，但症状本身不能证明根因。正确排查应先确认边界“代理和负载均衡器必须端到端支持所需 gRPC 协议，不能按普通 HTTP/1.1 转发”，再用主规则“标准 ASP.NET Core gRPC 通常依赖 HTTP/2，TLS 与终结点协议配置会影响协商”解释证据。直接采用误区“gRPC 会自动把任何 HTTP/1.1 连接升级且无须代理支持”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0807 关于 HTTP/2，以下哪项说法不成立？
难度： 实战
- A. 标准 ASP.NET Core gRPC 通常依赖 HTTP/2，TLS 与终结点协议配置会影响协商
- B. gRPC 会自动把任何 HTTP/1.1 连接升级且无须代理支持
- C. 代理和负载均衡器必须端到端支持所需 gRPC 协议，不能按普通 HTTP/1.1 转发
- D. 出现“经过旧代理后调用返回协议错误”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案B
题目要求选出不成立的说法，答案“gRPC 会自动把任何 HTTP/1.1 连接升级且无须代理支持”正是 HTTP/2 的典型误区。其余三项分别给出了主规则“标准 ASP.NET Core gRPC 通常依赖 HTTP/2，TLS 与终结点协议配置会影响协商”、适用边界“代理和负载均衡器必须端到端支持所需 gRPC 协议，不能按普通 HTTP/1.1 转发”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0808 针对“经过旧代理后调用返回协议错误”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“gRPC 会自动把任何 HTTP/1.1 连接升级且无须代理支持”修改实现，并把一次请求成功作为验收结果。
- B. 按“标准 ASP.NET Core gRPC 通常依赖 HTTP/2，TLS 与终结点协议配置会影响协商”修改代码后直接上线，不验证“代理和负载均衡器必须端到端支持所需 gRPC 协议，不能按普通 HTTP/1.1 转发”。
- C. 按“标准 ASP.NET Core gRPC 通常依赖 HTTP/2，TLS 与终结点协议配置会影响协商”修正实现，并用测试或遥测验证“代理和负载均衡器必须端到端支持所需 gRPC 协议，不能按普通 HTTP/1.1 转发”。
- D. 只验证“代理和负载均衡器必须端到端支持所需 gRPC 协议，不能按普通 HTTP/1.1 转发”，但实现仍继续依赖“gRPC 会自动把任何 HTTP/1.1 连接升级且无须代理支持”。
查看答案与解析
正确答案C
完整决策同时覆盖规则与验证：标准 ASP.NET Core gRPC 通常依赖 HTTP/2，TLS 与终结点协议配置会影响协商；并确认 代理和负载均衡器必须端到端支持所需 gRPC 协议，不能按普通 HTTP/1.1 转发。继续接受“gRPC 会自动把任何 HTTP/1.1 连接升级且无须代理支持”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“经过旧代理后调用返回协议错误”这一生产场景能否安全上线。
0809 在 Deadline 与取消 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 设置 Deadline 后服务器线程会在时刻到达时被强制终止
- B. 客户端可设置 Deadline，服务端从 ServerCallContext 观察取消并传给下游调用
- C. 超时不会强制停止忽略取消的业务代码，也不能自动撤销已提交副作用
- D. 观察到“客户端超时后数据库查询仍运行”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案B
正确答案直接描述 Deadline 与取消 的主规则：客户端可设置 Deadline，服务端从 ServerCallContext 观察取消并传给下游调用。选项“超时不会强制停止忽略取消的业务代码，也不能自动撤销已提交副作用”是使用规则时要验证的边界，不是规则本身；“设置 Deadline 后服务器线程会在时刻到达时被强制终止”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0810 客户端超时后数据库查询仍运行。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“设置 Deadline 后服务器线程会在时刻到达时被强制终止”定性，不再检查配置、身份或运行时证据。
- B. 只增加重试次数或机器资源，暂不核对“超时不会强制停止忽略取消的业务代码，也不能自动撤销已提交副作用”。
- C. 先验证“超时不会强制停止忽略取消的业务代码，也不能自动撤销已提交副作用”，再依据“客户端可设置 Deadline，服务端从 ServerCallContext 观察取消并传给下游调用”判断实现是否符合契约。
- D. 以一次成功请求作为结论，不再确认“客户端可设置 Deadline，服务端从 ServerCallContext 观察取消并传给下游调用”是否成立。
查看答案与解析
正确答案C
场景“客户端超时后数据库查询仍运行”指向 Deadline 与取消，但症状本身不能证明根因。正确排查应先确认边界“超时不会强制停止忽略取消的业务代码，也不能自动撤销已提交副作用”，再用主规则“客户端可设置 Deadline，服务端从 ServerCallContext 观察取消并传给下游调用”解释证据。直接采用误区“设置 Deadline 后服务器线程会在时刻到达时被强制终止”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0811 关于 Deadline 与取消，以下哪项说法不成立？
难度： 实战
- A. 客户端可设置 Deadline，服务端从 ServerCallContext 观察取消并传给下游调用
- B. 超时不会强制停止忽略取消的业务代码，也不能自动撤销已提交副作用
- C. 出现“客户端超时后数据库查询仍运行”时，应收集证据并同时核对主规则与适用边界。
- D. 设置 Deadline 后服务器线程会在时刻到达时被强制终止
查看答案与解析
正确答案D
题目要求选出不成立的说法，答案“设置 Deadline 后服务器线程会在时刻到达时被强制终止”正是 Deadline 与取消 的典型误区。其余三项分别给出了主规则“客户端可设置 Deadline，服务端从 ServerCallContext 观察取消并传给下游调用”、适用边界“超时不会强制停止忽略取消的业务代码，也不能自动撤销已提交副作用”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0812 针对“客户端超时后数据库查询仍运行”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“客户端可设置 Deadline，服务端从 ServerCallContext 观察取消并传给下游调用”修正实现，并用测试或遥测验证“超时不会强制停止忽略取消的业务代码，也不能自动撤销已提交副作用”。
- B. 按“设置 Deadline 后服务器线程会在时刻到达时被强制终止”修改实现，并把一次请求成功作为验收结果。
- C. 按“客户端可设置 Deadline，服务端从 ServerCallContext 观察取消并传给下游调用”修改代码后直接上线，不验证“超时不会强制停止忽略取消的业务代码，也不能自动撤销已提交副作用”。
- D. 只验证“超时不会强制停止忽略取消的业务代码，也不能自动撤销已提交副作用”，但实现仍继续依赖“设置 Deadline 后服务器线程会在时刻到达时被强制终止”。
查看答案与解析
正确答案A
完整决策同时覆盖规则与验证：客户端可设置 Deadline，服务端从 ServerCallContext 观察取消并传给下游调用；并确认 超时不会强制停止忽略取消的业务代码，也不能自动撤销已提交副作用。继续接受“设置 Deadline 后服务器线程会在时刻到达时被强制终止”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“客户端超时后数据库查询仍运行”这一生产场景能否安全上线。
0813 在 流式调用 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 双向流允许任意数量线程同时写同一个响应流且自动排序
- B. 长流应处理背压、取消、消息大小和中途失败，不能无界缓存全部消息
- C. gRPC 支持服务端流、客户端流和双向流，读写需遵守单读单写等并发约束
- D. 观察到“并发写响应流引发异常或乱序”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案C
正确答案直接描述 流式调用 的主规则：gRPC 支持服务端流、客户端流和双向流，读写需遵守单读单写等并发约束。选项“长流应处理背压、取消、消息大小和中途失败，不能无界缓存全部消息”是使用规则时要验证的边界，不是规则本身；“双向流允许任意数量线程同时写同一个响应流且自动排序”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0814 并发写响应流引发异常或乱序。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“双向流允许任意数量线程同时写同一个响应流且自动排序”定性，不再检查配置、身份或运行时证据。
- B. 先验证“长流应处理背压、取消、消息大小和中途失败，不能无界缓存全部消息”，再依据“gRPC 支持服务端流、客户端流和双向流，读写需遵守单读单写等并发约束”判断实现是否符合契约。
- C. 只增加重试次数或机器资源，暂不核对“长流应处理背压、取消、消息大小和中途失败，不能无界缓存全部消息”。
- D. 以一次成功请求作为结论，不再确认“gRPC 支持服务端流、客户端流和双向流，读写需遵守单读单写等并发约束”是否成立。
查看答案与解析
正确答案B
场景“并发写响应流引发异常或乱序”指向 流式调用，但症状本身不能证明根因。正确排查应先确认边界“长流应处理背压、取消、消息大小和中途失败，不能无界缓存全部消息”，再用主规则“gRPC 支持服务端流、客户端流和双向流，读写需遵守单读单写等并发约束”解释证据。直接采用误区“双向流允许任意数量线程同时写同一个响应流且自动排序”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0815 关于 流式调用，以下哪项说法不成立？
难度： 实战
- A. 双向流允许任意数量线程同时写同一个响应流且自动排序
- B. gRPC 支持服务端流、客户端流和双向流，读写需遵守单读单写等并发约束
- C. 长流应处理背压、取消、消息大小和中途失败，不能无界缓存全部消息
- D. 出现“并发写响应流引发异常或乱序”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案A
题目要求选出不成立的说法，答案“双向流允许任意数量线程同时写同一个响应流且自动排序”正是 流式调用 的典型误区。其余三项分别给出了主规则“gRPC 支持服务端流、客户端流和双向流，读写需遵守单读单写等并发约束”、适用边界“长流应处理背压、取消、消息大小和中途失败，不能无界缓存全部消息”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0816 针对“并发写响应流引发异常或乱序”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“双向流允许任意数量线程同时写同一个响应流且自动排序”修改实现，并把一次请求成功作为验收结果。
- B. 按“gRPC 支持服务端流、客户端流和双向流，读写需遵守单读单写等并发约束”修改代码后直接上线，不验证“长流应处理背压、取消、消息大小和中途失败，不能无界缓存全部消息”。
- C. 只验证“长流应处理背压、取消、消息大小和中途失败，不能无界缓存全部消息”，但实现仍继续依赖“双向流允许任意数量线程同时写同一个响应流且自动排序”。
- D. 按“gRPC 支持服务端流、客户端流和双向流，读写需遵守单读单写等并发约束”修正实现，并用测试或遥测验证“长流应处理背压、取消、消息大小和中途失败，不能无界缓存全部消息”。
查看答案与解析
正确答案D
完整决策同时覆盖规则与验证：gRPC 支持服务端流、客户端流和双向流，读写需遵守单读单写等并发约束；并确认 长流应处理背压、取消、消息大小和中途失败，不能无界缓存全部消息。继续接受“双向流允许任意数量线程同时写同一个响应流且自动排序”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“并发写响应流引发异常或乱序”这一生产场景能否安全上线。
0817 在 Interceptor 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. Interceptor 中看到 role 头即可安全授权管理员调用
- B. 授权仍应使用标准策略和可信身份，拦截器不能靠客户端元数据自行认定权限
- C. 观察到“攻击者伪造元数据获得管理权限”即可把一次现象当成完整框架契约。
- D. Interceptor 可处理日志、认证信息、异常映射等跨调用逻辑
查看答案与解析
正确答案D
正确答案直接描述 Interceptor 的主规则：Interceptor 可处理日志、认证信息、异常映射等跨调用逻辑。选项“授权仍应使用标准策略和可信身份，拦截器不能靠客户端元数据自行认定权限”是使用规则时要验证的边界，不是规则本身；“Interceptor 中看到 role 头即可安全授权管理员调用”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0818 攻击者伪造元数据获得管理权限。排查时哪项动作最合理？
难度： 进阶
- A. 先验证“授权仍应使用标准策略和可信身份，拦截器不能靠客户端元数据自行认定权限”，再依据“Interceptor 可处理日志、认证信息、异常映射等跨调用逻辑”判断实现是否符合契约。
- B. 直接按“Interceptor 中看到 role 头即可安全授权管理员调用”定性，不再检查配置、身份或运行时证据。
- C. 只增加重试次数或机器资源，暂不核对“授权仍应使用标准策略和可信身份，拦截器不能靠客户端元数据自行认定权限”。
- D. 以一次成功请求作为结论，不再确认“Interceptor 可处理日志、认证信息、异常映射等跨调用逻辑”是否成立。
查看答案与解析
正确答案A
场景“攻击者伪造元数据获得管理权限”指向 Interceptor，但症状本身不能证明根因。正确排查应先确认边界“授权仍应使用标准策略和可信身份，拦截器不能靠客户端元数据自行认定权限”，再用主规则“Interceptor 可处理日志、认证信息、异常映射等跨调用逻辑”解释证据。直接采用误区“Interceptor 中看到 role 头即可安全授权管理员调用”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0819 关于 Interceptor，以下哪项说法不成立？
难度： 实战
- A. Interceptor 可处理日志、认证信息、异常映射等跨调用逻辑
- B. 授权仍应使用标准策略和可信身份，拦截器不能靠客户端元数据自行认定权限
- C. Interceptor 中看到 role 头即可安全授权管理员调用
- D. 出现“攻击者伪造元数据获得管理权限”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案C
题目要求选出不成立的说法，答案“Interceptor 中看到 role 头即可安全授权管理员调用”正是 Interceptor 的典型误区。其余三项分别给出了主规则“Interceptor 可处理日志、认证信息、异常映射等跨调用逻辑”、适用边界“授权仍应使用标准策略和可信身份，拦截器不能靠客户端元数据自行认定权限”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0820 针对“攻击者伪造元数据获得管理权限”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“Interceptor 中看到 role 头即可安全授权管理员调用”修改实现，并把一次请求成功作为验收结果。
- B. 按“Interceptor 可处理日志、认证信息、异常映射等跨调用逻辑”修正实现，并用测试或遥测验证“授权仍应使用标准策略和可信身份，拦截器不能靠客户端元数据自行认定权限”。
- C. 按“Interceptor 可处理日志、认证信息、异常映射等跨调用逻辑”修改代码后直接上线，不验证“授权仍应使用标准策略和可信身份，拦截器不能靠客户端元数据自行认定权限”。
- D. 只验证“授权仍应使用标准策略和可信身份，拦截器不能靠客户端元数据自行认定权限”，但实现仍继续依赖“Interceptor 中看到 role 头即可安全授权管理员调用”。
查看答案与解析
正确答案B
完整决策同时覆盖规则与验证：Interceptor 可处理日志、认证信息、异常映射等跨调用逻辑；并确认 授权仍应使用标准策略和可信身份，拦截器不能靠客户端元数据自行认定权限。继续接受“Interceptor 中看到 role 头即可安全授权管理员调用”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“攻击者伪造元数据获得管理权限”这一生产场景能否安全上线。