nginx通过location精确匹配静态资源路径（如~*.(js|css|png)$或^~/static/），配合proxy_pass显式转发至专用静态服务或cdn，并启用强缓存与哈希资源策略，实现动静分离；需避免规则顺序错误、误捕html/api及通用代理覆盖。
反向代理本身不“提取”流量，而是按规则显式分发——所谓“精准提取静态代理流”，本质是通过 location 匹配与 proxy_pass 的明确指向，把静态资源请求从 SPA 入口流量中剥离出来，交由专用路径或服务处理，避免和 API 或 HTML 混淆。
用 location 精确拦截静态资源路径
关键不是“提取”，而是“识别并分流”。Nginx 依靠 URI 前缀或后缀做第一层筛选：
- 匹配常见静态扩展名：用 location ~* \.(js|css|png|jpg|woff2|svg)$ 直接命中资源文件，内部直接 serve 或转发到 CDN/静态服务器
- 匹配约定前缀：如所有静态资源统一放在 /static/ 或 /assets/ 下，就写 location ^~ /static/，优先级高于正则，更稳定
- 避免误伤：必须排除 /index.html 和 API 路径（如 /api/、/auth/），否则会导致 HTML 被当成静态文件缓存或转发错位
显式绑定静态服务源站，不依赖默认 fallback
SPA 的 index.html 通常由后端或 Nginx 自身返回，但 JS/CSS 等应指向独立静态源——不能靠 proxy_pass 指向同一后端再靠它分发，那样仍会走应用逻辑，增加延迟且易出错：
- 配置独立 upstream：例如 upstream static-srv { server 10.0.1.10:8080; }，专供静态资源
- 在对应 location 中显式调用：proxy_pass http://static-srv;，而非模糊的 http://backend
- 若静态资源已托管在对象存储（如 OSS/S3）或 CDN，直接 proxy_pass https://cdn.example.com;，省去中间转发环节
配合缓存策略，让“静态流”真正可复用
仅分流还不够，要让浏览器和中间层确认这是“纯静态”，才不会反复校验或降级回源：
- 对哈希命名资源（如 app.a1b2c3.js）启用强缓存：expires 1y; add_header Cache-Control "public, immutable";
- 对未哈希资源（如 favicon.ico、robots.txt）设合理缓存：expires 7d;，避免频繁验证
- 禁用 proxy_cache 对 index.html 生效，但可为静态资源开启：proxy_cache static_cache;，配合 proxy_cache_valid 200 1y;
堵住 SPA 路由干扰：防止前端路由被误判为静态路径
Vue Router / React Router 的 history 模式依赖服务端 fallback 到 index.html，若 location 规则写得太宽，可能把 /user/123 这类前端路由当成静态路径拦截：
- 确保静态规则在配置文件中排在通用 fallback 之前，Nginx 按顺序匹配，先命中静态再 fallback
- 避免使用 location / 统一代理全部请求；改用 location /api/ 和 location /static/ 显式定义，其余留给 location / { try_files $uri $uri/ /index.html; }
- 检查日志：log_format main '$request_uri $status $upstream_addr';，确认 /xxx.js 确实打到了静态 upstream，而非 backend
