我们看到一些行为，我们没有在OkHttp中缓存响应，并且每次都会访问服务器。但是，响应在将来会有一个Expires时间，所以理想情况下它会被缓存。
下面是我们在响应中看到的头的一个简单示例(请求已发送，响应已在Sat, 16 Jan 2021 00:40:36 GMT接收)：
date: Sat, 16 Jan 2021 00:40:36 GMT
age: 6
expires: Sat, 16 Jan 2021 00:40:40 GMT
last-modified: Sat, 16 Jan 2021 00:40:30 GMT
从我对CacheStrategy的观察来看，问题是它将日期+年龄加在一起，看看它是否超过了到期时间。在这种情况下，00:40:36 + 6 = 00:40:42 > 00:40:40，因此它最终不会被添加到缓存中。
因此，我认为理想情况下，要么响应日期等于上次修改日期(在本例中为2021年1月16日星期六格林尼治标准时间00:40:30)，要么我们需要有一个自定义的CacheStrategy来使用上次修改日期而不是日期进行这些计算。
如果有人对我是否做出了任何错误的假设有任何见解，或者以上选项之一是否更可取，请告诉我。我看过一些日期/年龄标题的规格，我有点不清楚在这种情况下它们应该是什么。
我还发现在OkHttp中调试缓存行为有点困难，现在我只是使用条件断点来尝试跟踪它，但如果有人有更好的想法，我也会很感激。
将expires标头替换为设置最大年龄指令的Cache Control标头：
Cache-Control: max-age=86400
这将导致OkHttp缓存响应24小时，而不管它何时被服务。过期标头有问题，因为CloudFlare将其视为特定的过期时间，而不是持续时间。
我建议尝试使用；高速缓存控制"；标题带有您选择的max-age。
我这样做的主要原因是官方文档中的一个示例也显示了这一点，请参阅：https://square.github.io/okhttp/interceptors/#rewriting-响应
.header("Cache-Control", "max-age=60")
这样做的首选方式显然是在后端。如果您不能修改后端，那么我想拦截器将是第二种选择请注意，这是最后一个不鼓励的选项
除了你的后端，我还想看看cloudflare本身提供的选项：https://support.cloudflare.com/hc/en-us/articles/360021806811-Getting-Started-with-Cloudflare-Caching