ASP.NET Core 试题 34：内存、分布式与输出缓存
0661 在 IMemoryCache 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. IMemoryCache 会由框架自动同步到所有 Pod
- B. 多副本一致性或会话场景要评估分布式缓存，不能依赖负载均衡永久粘滞
- C. 观察到“用户在不同副本读取到不同缓存”即可把一次现象当成完整框架契约。
- D. 内存缓存位于单进程内，访问快但实例间不共享且会随进程丢失
查看答案与解析
正确答案D
正确答案直接描述 IMemoryCache 的主规则：内存缓存位于单进程内，访问快但实例间不共享且会随进程丢失。选项“多副本一致性或会话场景要评估分布式缓存，不能依赖负载均衡永久粘滞”是使用规则时要验证的边界，不是规则本身；“IMemoryCache 会由框架自动同步到所有 Pod”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0662 用户在不同副本读取到不同缓存。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“IMemoryCache 会由框架自动同步到所有 Pod”定性，不再检查配置、身份或运行时证据。
- B. 只增加重试次数或机器资源，暂不核对“多副本一致性或会话场景要评估分布式缓存，不能依赖负载均衡永久粘滞”。
- C. 先验证“多副本一致性或会话场景要评估分布式缓存，不能依赖负载均衡永久粘滞”，再依据“内存缓存位于单进程内，访问快但实例间不共享且会随进程丢失”判断实现是否符合契约。
- D. 以一次成功请求作为结论，不再确认“内存缓存位于单进程内，访问快但实例间不共享且会随进程丢失”是否成立。
查看答案与解析
正确答案C
场景“用户在不同副本读取到不同缓存”指向 IMemoryCache，但症状本身不能证明根因。正确排查应先确认边界“多副本一致性或会话场景要评估分布式缓存，不能依赖负载均衡永久粘滞”，再用主规则“内存缓存位于单进程内，访问快但实例间不共享且会随进程丢失”解释证据。直接采用误区“IMemoryCache 会由框架自动同步到所有 Pod”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0663 关于 IMemoryCache，以下哪项说法不成立？
难度： 实战
- A. IMemoryCache 会由框架自动同步到所有 Pod
- B. 内存缓存位于单进程内，访问快但实例间不共享且会随进程丢失
- C. 多副本一致性或会话场景要评估分布式缓存，不能依赖负载均衡永久粘滞
- D. 出现“用户在不同副本读取到不同缓存”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案A
题目要求选出不成立的说法，答案“IMemoryCache 会由框架自动同步到所有 Pod”正是 IMemoryCache 的典型误区。其余三项分别给出了主规则“内存缓存位于单进程内，访问快但实例间不共享且会随进程丢失”、适用边界“多副本一致性或会话场景要评估分布式缓存，不能依赖负载均衡永久粘滞”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0664 针对“用户在不同副本读取到不同缓存”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“IMemoryCache 会由框架自动同步到所有 Pod”修改实现，并把一次请求成功作为验收结果。
- B. 按“内存缓存位于单进程内，访问快但实例间不共享且会随进程丢失”修正实现，并用测试或遥测验证“多副本一致性或会话场景要评估分布式缓存，不能依赖负载均衡永久粘滞”。
- C. 按“内存缓存位于单进程内，访问快但实例间不共享且会随进程丢失”修改代码后直接上线，不验证“多副本一致性或会话场景要评估分布式缓存，不能依赖负载均衡永久粘滞”。
- D. 只验证“多副本一致性或会话场景要评估分布式缓存，不能依赖负载均衡永久粘滞”，但实现仍继续依赖“IMemoryCache 会由框架自动同步到所有 Pod”。
查看答案与解析
正确答案B
完整决策同时覆盖规则与验证：内存缓存位于单进程内，访问快但实例间不共享且会随进程丢失；并确认 多副本一致性或会话场景要评估分布式缓存，不能依赖负载均衡永久粘滞。继续接受“IMemoryCache 会由框架自动同步到所有 Pod”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“用户在不同副本读取到不同缓存”这一生产场景能否安全上线。
0665 在 IDistributedCache 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 分布式缓存提供基于字节或字符串的跨实例存取抽象
- B. IDistributedCache 调用只访问本机内存且不会超时
- C. 序列化、网络失败、过期和缓存服务容量都要设计，不能把它当永不失败数据库
- D. 观察到“Redis 故障导致请求延迟级联”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案A
正确答案直接描述 IDistributedCache 的主规则：分布式缓存提供基于字节或字符串的跨实例存取抽象。选项“序列化、网络失败、过期和缓存服务容量都要设计，不能把它当永不失败数据库”是使用规则时要验证的边界，不是规则本身；“IDistributedCache 调用只访问本机内存且不会超时”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0666 Redis 故障导致请求延迟级联。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“IDistributedCache 调用只访问本机内存且不会超时”定性，不再检查配置、身份或运行时证据。
- B. 只增加重试次数或机器资源，暂不核对“序列化、网络失败、过期和缓存服务容量都要设计，不能把它当永不失败数据库”。
- C. 先验证“序列化、网络失败、过期和缓存服务容量都要设计，不能把它当永不失败数据库”，再依据“分布式缓存提供基于字节或字符串的跨实例存取抽象”判断实现是否符合契约。
- D. 以一次成功请求作为结论，不再确认“分布式缓存提供基于字节或字符串的跨实例存取抽象”是否成立。
查看答案与解析
正确答案C
场景“Redis 故障导致请求延迟级联”指向 IDistributedCache，但症状本身不能证明根因。正确排查应先确认边界“序列化、网络失败、过期和缓存服务容量都要设计，不能把它当永不失败数据库”，再用主规则“分布式缓存提供基于字节或字符串的跨实例存取抽象”解释证据。直接采用误区“IDistributedCache 调用只访问本机内存且不会超时”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0667 关于 IDistributedCache，以下哪项说法不成立？
难度： 实战
- A. 分布式缓存提供基于字节或字符串的跨实例存取抽象
- B. 序列化、网络失败、过期和缓存服务容量都要设计，不能把它当永不失败数据库
- C. 出现“Redis 故障导致请求延迟级联”时，应收集证据并同时核对主规则与适用边界。
- D. IDistributedCache 调用只访问本机内存且不会超时
查看答案与解析
正确答案D
题目要求选出不成立的说法，答案“IDistributedCache 调用只访问本机内存且不会超时”正是 IDistributedCache 的典型误区。其余三项分别给出了主规则“分布式缓存提供基于字节或字符串的跨实例存取抽象”、适用边界“序列化、网络失败、过期和缓存服务容量都要设计，不能把它当永不失败数据库”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0668 针对“Redis 故障导致请求延迟级联”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“IDistributedCache 调用只访问本机内存且不会超时”修改实现，并把一次请求成功作为验收结果。
- B. 按“分布式缓存提供基于字节或字符串的跨实例存取抽象”修正实现，并用测试或遥测验证“序列化、网络失败、过期和缓存服务容量都要设计，不能把它当永不失败数据库”。
- C. 按“分布式缓存提供基于字节或字符串的跨实例存取抽象”修改代码后直接上线，不验证“序列化、网络失败、过期和缓存服务容量都要设计，不能把它当永不失败数据库”。
- D. 只验证“序列化、网络失败、过期和缓存服务容量都要设计，不能把它当永不失败数据库”，但实现仍继续依赖“IDistributedCache 调用只访问本机内存且不会超时”。
查看答案与解析
正确答案B
完整决策同时覆盖规则与验证：分布式缓存提供基于字节或字符串的跨实例存取抽象；并确认 序列化、网络失败、过期和缓存服务容量都要设计，不能把它当永不失败数据库。继续接受“IDistributedCache 调用只访问本机内存且不会超时”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“Redis 故障导致请求延迟级联”这一生产场景能否安全上线。
0669 在 Output Cache 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 给授权端点调用 CacheOutput 就一定按当前用户自动隔离
- B. 输出缓存可按策略缓存端点响应，并支持 vary、标签和失效等服务器控制
- C. 认证响应、用户个性化、Cookie 和动态权限必须避免误共享，默认策略不会缓存所有响应
- D. 观察到“一个用户看到另一个用户的响应”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案B
正确答案直接描述 Output Cache 的主规则：输出缓存可按策略缓存端点响应，并支持 vary、标签和失效等服务器控制。选项“认证响应、用户个性化、Cookie 和动态权限必须避免误共享，默认策略不会缓存所有响应”是使用规则时要验证的边界，不是规则本身；“给授权端点调用 CacheOutput 就一定按当前用户自动隔离”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0670 一个用户看到另一个用户的响应。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“给授权端点调用 CacheOutput 就一定按当前用户自动隔离”定性，不再检查配置、身份或运行时证据。
- B. 只增加重试次数或机器资源，暂不核对“认证响应、用户个性化、Cookie 和动态权限必须避免误共享，默认策略不会缓存所有响应”。
- C. 先验证“认证响应、用户个性化、Cookie 和动态权限必须避免误共享，默认策略不会缓存所有响应”，再依据“输出缓存可按策略缓存端点响应，并支持 vary、标签和失效等服务器控制”判断实现是否符合契约。
- D. 以一次成功请求作为结论，不再确认“输出缓存可按策略缓存端点响应，并支持 vary、标签和失效等服务器控制”是否成立。
查看答案与解析
正确答案C
场景“一个用户看到另一个用户的响应”指向 Output Cache，但症状本身不能证明根因。正确排查应先确认边界“认证响应、用户个性化、Cookie 和动态权限必须避免误共享，默认策略不会缓存所有响应”，再用主规则“输出缓存可按策略缓存端点响应，并支持 vary、标签和失效等服务器控制”解释证据。直接采用误区“给授权端点调用 CacheOutput 就一定按当前用户自动隔离”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0671 关于 Output Cache，以下哪项说法不成立？
难度： 实战
- A. 给授权端点调用 CacheOutput 就一定按当前用户自动隔离
- B. 输出缓存可按策略缓存端点响应，并支持 vary、标签和失效等服务器控制
- C. 认证响应、用户个性化、Cookie 和动态权限必须避免误共享，默认策略不会缓存所有响应
- D. 出现“一个用户看到另一个用户的响应”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案A
题目要求选出不成立的说法，答案“给授权端点调用 CacheOutput 就一定按当前用户自动隔离”正是 Output Cache 的典型误区。其余三项分别给出了主规则“输出缓存可按策略缓存端点响应，并支持 vary、标签和失效等服务器控制”、适用边界“认证响应、用户个性化、Cookie 和动态权限必须避免误共享，默认策略不会缓存所有响应”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0672 针对“一个用户看到另一个用户的响应”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“给授权端点调用 CacheOutput 就一定按当前用户自动隔离”修改实现，并把一次请求成功作为验收结果。
- B. 按“输出缓存可按策略缓存端点响应，并支持 vary、标签和失效等服务器控制”修改代码后直接上线，不验证“认证响应、用户个性化、Cookie 和动态权限必须避免误共享，默认策略不会缓存所有响应”。
- C. 只验证“认证响应、用户个性化、Cookie 和动态权限必须避免误共享，默认策略不会缓存所有响应”，但实现仍继续依赖“给授权端点调用 CacheOutput 就一定按当前用户自动隔离”。
- D. 按“输出缓存可按策略缓存端点响应，并支持 vary、标签和失效等服务器控制”修正实现，并用测试或遥测验证“认证响应、用户个性化、Cookie 和动态权限必须避免误共享，默认策略不会缓存所有响应”。
查看答案与解析
正确答案D
完整决策同时覆盖规则与验证：输出缓存可按策略缓存端点响应，并支持 vary、标签和失效等服务器控制；并确认 认证响应、用户个性化、Cookie 和动态权限必须避免误共享，默认策略不会缓存所有响应。继续接受“给授权端点调用 CacheOutput 就一定按当前用户自动隔离”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“一个用户看到另一个用户的响应”这一生产场景能否安全上线。
0673 在 Response Caching 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. Response Caching 会忽略 Cache-Control 并强制缓存所有 GET
- B. 它与 Output Cache 的服务器策略模型不同，不能只根据名称互换使用
- C. 响应缓存遵循 HTTP 缓存头和客户端请求语义，服务端行为受规范约束
- D. 观察到“客户端 no-cache 请求仍命中错误缓存”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案C
正确答案直接描述 Response Caching 的主规则：响应缓存遵循 HTTP 缓存头和客户端请求语义，服务端行为受规范约束。选项“它与 Output Cache 的服务器策略模型不同，不能只根据名称互换使用”是使用规则时要验证的边界，不是规则本身；“Response Caching 会忽略 Cache-Control 并强制缓存所有 GET”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0674 客户端 no-cache 请求仍命中错误缓存。排查时哪项动作最合理？
难度： 进阶
- A. 先验证“它与 Output Cache 的服务器策略模型不同，不能只根据名称互换使用”，再依据“响应缓存遵循 HTTP 缓存头和客户端请求语义，服务端行为受规范约束”判断实现是否符合契约。
- B. 直接按“Response Caching 会忽略 Cache-Control 并强制缓存所有 GET”定性，不再检查配置、身份或运行时证据。
- C. 只增加重试次数或机器资源，暂不核对“它与 Output Cache 的服务器策略模型不同，不能只根据名称互换使用”。
- D. 以一次成功请求作为结论，不再确认“响应缓存遵循 HTTP 缓存头和客户端请求语义，服务端行为受规范约束”是否成立。
查看答案与解析
正确答案A
场景“客户端 no-cache 请求仍命中错误缓存”指向 Response Caching，但症状本身不能证明根因。正确排查应先确认边界“它与 Output Cache 的服务器策略模型不同，不能只根据名称互换使用”，再用主规则“响应缓存遵循 HTTP 缓存头和客户端请求语义，服务端行为受规范约束”解释证据。直接采用误区“Response Caching 会忽略 Cache-Control 并强制缓存所有 GET”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0675 关于 Response Caching，以下哪项说法不成立？
难度： 实战
- A. 响应缓存遵循 HTTP 缓存头和客户端请求语义，服务端行为受规范约束
- B. 它与 Output Cache 的服务器策略模型不同，不能只根据名称互换使用
- C. 出现“客户端 no-cache 请求仍命中错误缓存”时，应收集证据并同时核对主规则与适用边界。
- D. Response Caching 会忽略 Cache-Control 并强制缓存所有 GET
查看答案与解析
正确答案D
题目要求选出不成立的说法，答案“Response Caching 会忽略 Cache-Control 并强制缓存所有 GET”正是 Response Caching 的典型误区。其余三项分别给出了主规则“响应缓存遵循 HTTP 缓存头和客户端请求语义，服务端行为受规范约束”、适用边界“它与 Output Cache 的服务器策略模型不同，不能只根据名称互换使用”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0676 针对“客户端 no-cache 请求仍命中错误缓存”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“Response Caching 会忽略 Cache-Control 并强制缓存所有 GET”修改实现，并把一次请求成功作为验收结果。
- B. 按“响应缓存遵循 HTTP 缓存头和客户端请求语义，服务端行为受规范约束”修正实现，并用测试或遥测验证“它与 Output Cache 的服务器策略模型不同，不能只根据名称互换使用”。
- C. 按“响应缓存遵循 HTTP 缓存头和客户端请求语义，服务端行为受规范约束”修改代码后直接上线，不验证“它与 Output Cache 的服务器策略模型不同，不能只根据名称互换使用”。
- D. 只验证“它与 Output Cache 的服务器策略模型不同，不能只根据名称互换使用”，但实现仍继续依赖“Response Caching 会忽略 Cache-Control 并强制缓存所有 GET”。
查看答案与解析
正确答案B
完整决策同时覆盖规则与验证：响应缓存遵循 HTTP 缓存头和客户端请求语义，服务端行为受规范约束；并确认 它与 Output Cache 的服务器策略模型不同，不能只根据名称互换使用。继续接受“Response Caching 会忽略 Cache-Control 并强制缓存所有 GET”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“客户端 no-cache 请求仍命中错误缓存”这一生产场景能否安全上线。
0677 在 缓存击穿 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 给所有键相同 TTL 能保证回源均匀分散
- B. 可用单飞、锁、提前刷新或随机过期缓解，同时保留超时和失败降级
- C. 观察到“整批缓存同时过期压垮数据库”即可把一次现象当成完整框架契约。
- D. 大量请求同时发现热点键过期可能并发回源，形成缓存击穿
查看答案与解析
正确答案D
正确答案直接描述 缓存击穿 的主规则：大量请求同时发现热点键过期可能并发回源，形成缓存击穿。选项“可用单飞、锁、提前刷新或随机过期缓解，同时保留超时和失败降级”是使用规则时要验证的边界，不是规则本身；“给所有键相同 TTL 能保证回源均匀分散”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0678 整批缓存同时过期压垮数据库。排查时哪项动作最合理？
难度： 进阶
- A. 先验证“可用单飞、锁、提前刷新或随机过期缓解，同时保留超时和失败降级”，再依据“大量请求同时发现热点键过期可能并发回源，形成缓存击穿”判断实现是否符合契约。
- B. 直接按“给所有键相同 TTL 能保证回源均匀分散”定性，不再检查配置、身份或运行时证据。
- C. 只增加重试次数或机器资源，暂不核对“可用单飞、锁、提前刷新或随机过期缓解，同时保留超时和失败降级”。
- D. 以一次成功请求作为结论，不再确认“大量请求同时发现热点键过期可能并发回源，形成缓存击穿”是否成立。
查看答案与解析
正确答案A
场景“整批缓存同时过期压垮数据库”指向 缓存击穿，但症状本身不能证明根因。正确排查应先确认边界“可用单飞、锁、提前刷新或随机过期缓解，同时保留超时和失败降级”，再用主规则“大量请求同时发现热点键过期可能并发回源，形成缓存击穿”解释证据。直接采用误区“给所有键相同 TTL 能保证回源均匀分散”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0679 关于 缓存击穿，以下哪项说法不成立？
难度： 实战
- A. 大量请求同时发现热点键过期可能并发回源，形成缓存击穿
- B. 给所有键相同 TTL 能保证回源均匀分散
- C. 可用单飞、锁、提前刷新或随机过期缓解，同时保留超时和失败降级
- D. 出现“整批缓存同时过期压垮数据库”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案B
题目要求选出不成立的说法，答案“给所有键相同 TTL 能保证回源均匀分散”正是 缓存击穿 的典型误区。其余三项分别给出了主规则“大量请求同时发现热点键过期可能并发回源，形成缓存击穿”、适用边界“可用单飞、锁、提前刷新或随机过期缓解，同时保留超时和失败降级”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0680 针对“整批缓存同时过期压垮数据库”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“给所有键相同 TTL 能保证回源均匀分散”修改实现，并把一次请求成功作为验收结果。
- B. 按“大量请求同时发现热点键过期可能并发回源，形成缓存击穿”修改代码后直接上线，不验证“可用单飞、锁、提前刷新或随机过期缓解，同时保留超时和失败降级”。
- C. 按“大量请求同时发现热点键过期可能并发回源，形成缓存击穿”修正实现，并用测试或遥测验证“可用单飞、锁、提前刷新或随机过期缓解，同时保留超时和失败降级”。
- D. 只验证“可用单飞、锁、提前刷新或随机过期缓解，同时保留超时和失败降级”，但实现仍继续依赖“给所有键相同 TTL 能保证回源均匀分散”。
查看答案与解析
正确答案C
完整决策同时覆盖规则与验证：大量请求同时发现热点键过期可能并发回源，形成缓存击穿；并确认 可用单飞、锁、提前刷新或随机过期缓解，同时保留超时和失败降级。继续接受“给所有键相同 TTL 能保证回源均匀分散”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“整批缓存同时过期压垮数据库”这一生产场景能否安全上线。