缓存 TTL 设计：让 app 又快又省的三层缓存

2026/9/17

背景与问题

app 每次启动都打满 API 请求 = 慢 + 服务器成本高。solo 后端用对 HTTP 缓存指令能免费拿到速度。整理三层（客户端/边缘/源站）缓存的最小设计：TTL 给谁多长、陈旧数据怎么办。

（来源访问日期均为 2026-09-17）

事实（web.dev 的 SWR 解说）：Cache-Control: max-age=60, stale-while-revalidate=300——过期后 1-300 秒内先返回陈旧值、后台拉新（serve stale, update in background）。移动端体感延迟优先于绝对新鲜度时是最佳默认。
事实（OneUptime 2026-01 指南）：HTTP 头到应用层缓存的配置全链路；SWR 模式是移动后端的常用形态。
事实（Cloudflare 社区）：must-revalidate 是反方向——过期即禁止陈旧，用在陈旧数据会造成用户可见错误的端点（余额、权益状态）。
事实（Fastly 文档）：边缘层过期对象会用响应再验证/更新后返回——CDN 层 SWR 与源站 TTL 配合形成分层。
推测：solo 的缓存失败模式只有两个——该缓存的东西没缓存（列表类接口裸奔）与不该缓存的缓存了（权益/余额带 max-age 导致「明明续费了还显示过期」）。端点分级一次就能避开两个坑。

端点分三级：①静态内容（教程/文案/配置）：max-age=86400+SWR ②列表/时间线：max-age=60+SWR=300 ③权益/余额/交易：no-store 或 max-age=0+must-revalidate。每端点定级一次，写进 API 文档。
客户端配合：网络库对 ③ 级不做本地缓存，对 ①② 缓存 + 后台刷新——移动端「先渲染旧数据再静默更新」的体验零成本拿到。
缓存键纪律：带用户身份的响应绝不共享缓存（CDN 层设置 vary/私有标记），否则会串号——这是缓存事故里最伤人的。
与 opc-edge-api-workers 组合：Workers 边缘做 ①② 级缓存命中，源站只接 ③ 级与 cache miss——请求量直接砍半以上。