列表接口配了 max-age=60, stale-while-revalidate=600，过期后的第一批请求耗时还是 800 毫秒，跟回源一样，没有出现先返回旧数据的效果。日志里能对上时间点，这种反而好排。
这个指令要缓存层支持才生效，浏览器和部分 CDN 会忽略。请求经过的代理不认这个参数时，过期就只能同步回源。响应头写了不等于链路每一层都执行。这一点先确认清楚，后面就不用反复试。
curl -sI http://127.0.0.1/api/list | grep -i cache-control # 期望 public, max-age=60, stale-while-revalidate=600
这次卡住的地方就在「stale-while-revalidate」这一环，单独把它拎出来验证，别和其他改动混在同一次发布里。先做最小复现，能稳定跑出来的问题，排查成本会低一个数量级。
别只看报错的最后一行，往上看几行，真正的起因通常在上面。
处理上按这个顺序：确认链路上的 CDN 是否支持该指令；不支持的层上改用 stale-if-error 或延长 max-age；在边缘节点开 SWR 功能 而不是只在源站写头；观察过期后首批请求的 TTFB 判断是否真的异步刷新。
结果对不对很好判断，过期后的首批请求在几十毫秒内返回旧数据 后台再回源刷新 TTFB 不再跳到 800 毫秒。