移动端App接口代理缓存需按语义精准控制：HTML入口禁用强缓存并强制校验，静态资源哈希化后设immutable长期缓存，API默认no-store，特定接口按时效设max-age，统一用Cache-Control而非expires。
移动端 App 接口代理场景下的浏览器缓存配置，关键不是“统一加缓存”，而是按接口语义做精准控制：HTML 页面必须可更新、静态资源必须强缓存、API 响应默认不缓存。Nginx 层不参与业务逻辑判断，只依据路径、文件名特征和响应头约定执行策略。
区分接口类型，用 location 精准匹配
App 接口通常走 /api/ 或 /v1/ 路径，需与静态资源、HTML 入口严格隔离：
- 对 /api/ 和 *.json 路径，显式禁用缓存：
location ~ ^/api/ { add_header Cache-Control "no-store" always; }location ~ \.json$ { add_header Cache-Control "no-store" always; } - 对已明确支持弱缓存的接口（如天气、公告类），按业务时效设 max-age：
location = /api/weather { add_header Cache-Control "public, max-age=600, stale-while-revalidate=30" always; } - 避免用正则模糊匹配 HTML（如
location ~ \.html$）去覆盖接口路径，防止误伤。
静态资源走哈希化 + immutable 长期缓存
App 内嵌 WebView 或 PWA 场景中，JS/CSS/字体等资源若未哈希化，极易因缓存导致白屏或样式错乱：
- 确保构建产物含内容哈希（如
app.d41d8cd9.js），再在 Nginx 中精准匹配：location ~* "\.[a-f0-9]{8,}\.(js|css|woff2|png|jpg)$" { add_header Cache-Control "public, max-age=31536000, immutable" always; } - 不用
?v=1.2.3类查询参数——微信、部分安卓 WebView 会忽略参数变化，仍读旧缓存。 - 配合
expires 1y自动补全 Expires 头，但以Cache-Control为准。
HTML 入口强制校验，防 PWA 启动页卡旧版
App 内 WebView 加载的 index.html 或 manifest 引用页，iOS Safari 可能将其固化为 PWA 启动页，必须杜绝强缓存：
- 对根路径或主 HTML 文件，禁用强缓存并启用验证：
location = / { add_header Cache-Control "private, max-age=0, no-cache, must-revalidate" always; }location ~* ^/index\.html$ { add_header Cache-Control "no-store, must-revalidate" always; } - 确保后端稳定返回一致 ETag（关闭 gzip 差异导致 ETag 变化）；否则协商缓存失效，反而增加请求数。
- 绝对不使用
expires 1h或max-age=300——短时间强缓存仍可能跳过服务器，用户看不到新版结构。
规避移动端特有坑点：别依赖 expires，慎用 UA 判断
低端安卓机时钟不准、iOS Safari 对缓存行为更激进，配置需更保守：
- 统一用
Cache-Control: max-age，不用expires——前者基于相对时间，不受客户端时钟偏差影响；后者依赖绝对时间，偏差超数小时即失效。 - 不推荐在 Nginx 层用
map $http_user_agent区分移动端 API 缓存策略——UA 易伪造、维护成本高；更合理的方式是后端在响应头中动态输出Cache-Control，Nginx 仅做透传或兜底覆盖。 - 对 SVG、字体等低频更新资源，可追加
stale-while-revalidate：add_header Cache-Control "public, max-age=31536000, stale-while-revalidate=86400" always;
