iOS 中常用的网络请求框架是 AFNetworing，项目中一开始使用了猿题库的 YTKNetwork，该框架是对 AFNetworking 的进一步封装，支持按照指定的时间控制缓存。

不过项目的需求并不需要指定多久的时间来保存缓存数据，而是根据服务器的缓存控制头来确定是否使用缓存，在 YTKNetwork 的文档中并没有与缓存头相关的描述，而且，无论是否在 Request 里手动添加 If-None-Match 缓存头，返回的 code 始终是 200。

然后换成直接使用 AFNetworking 直接来请求，发现也是无论是否手动添加缓存头，返回的 code 都是200。

后来在网上搜索查找了很久，发现有人说 iOS 的 NSURLSession 在默认缓存策略（NSURLRequestUseProtocolCachePolicy）的设置下 ，是会默认处理服务器返回的缓存控制头的，然后如果是返回 304 会产线使用缓存然后回调出来 response，code 是 200，但是这个无法直接验证。后来又在 AFNetworking 的一个 PullRequest 页面 看到相关的讨论，结论就是当缓存策略为 NSURLRequestUseProtocolCachePolicy 时，即跟随HTTP协议的缓存策略，此时 iOS的 NSURL 会自动处理服务器的缓存头，比如 ETag 或者是 Last-Modified 等，如果已经有缓存，且服务器返回 304，就会直接使用缓存，只不过回调出来的 code 是 200。

看到这里大概能够确定了，再加上从实际的调试情况来看，后面的请求返回的时间确实比第一次响应返回的时间有明显的缩短，也从侧面验证了后面应该是使用了本地的缓存。

最后过了几天，自己看到 mitmproxy 这个 HTTP 调试工具的时候，才突然想起来，早应该使用抓包工具来调试看服务器是否返回 304 的，最后装好 mitmproxy 后，验证后，确实和以上结论一致。另外，mitmproxy 真的很好用，开源免费跨平台😄。