在我的 iOS 应用程序中，我想缓存从不同目的地请求的图像。对于下载图像，我使用 URLSessionDataTasks 和 URLSession.shared 提供的默认缓存机制，它使用 NSURLRequestUseProtocolCachePolicy。
缓存基本上可以正常工作。正在缓存响应，并且正在正确处理诸如 etag 和缓存控制“max-age”之类的缓存标头。但是，如果服务器响应缓存控制标头设置为“no-cache”，则 URLSession 的 URLCache 仍在缓存图像。我可以通过 URLCache.shared.cachedResponse(for: request) 访问缓存的响应，并且具有相同请求的新数据任务将从缓存中返回时间图像（我使用 Charles 代理进行了验证，但我没有看到请求我正在等待）。
为什么它不能正确处理响应的缓存头？我是否需要手动检查响应的缓存标头？
该no-cache指令并不意味着“不要将其存储在缓存中”。相反，它指示缓存在没有先与服务器验证的情况下不提供缓存的响应。[RFC7234][1] 规范对no-cache指令进行了以下说明。
“no-cache”响应指令指示响应不能用于满足后续请求，而无需在源服务器上成功验证。这允许原始服务器阻止缓存使用它来满足请求而不联系它，即使是通过已配置为发送陈旧响应的缓存也是如此。
如果 no-cache 响应指令指定一个或多个字段名，则缓存可以使用响应来满足后续请求，但受缓存的任何其他限制。但是，如果没有与源服务器成功重新验证，则响应中包含字段名称的任何标头字段都不得在后续请求的响应中发送。这允许源服务器防止在响应中重复使用某些标头字段，同时仍然允许缓存响应的其余部分。
所以将会发生的是，对于带有no-cache指令的“新鲜”响应，将发送一个条件请求来验证是否可以使用存储的响应。如果响应仍然有效，服务器将发送304 - Not Modified响应。收到304响应后，缓存将使用no-cache指令提供存储的响应。如果存储的响应不再有效，服务器将发送一个新的响应。[1]：https ://www.rfc-editor.org/rfc/rfc7234#section-5.2.2