开发与生产环境需分别配置Nginx：开发环境用本地Nginx代理解决跨域与真实网关模拟，监听同源端口、设置proxy_set_header及WebSocket支持；生产环境则静态托管+API反向代理，分离路径、慎用sub_filter注入变量，优先构建时固化配置。
开发环境和生产环境用同一套 Nginx 配置是不可行的，因为目标不同：开发阶段要解决跨域、快速联调；生产阶段要稳定转发、安全防护、支持高并发。关键不是“一套配置切环境”，而是按场景分清用途、分别配置。
开发环境：本地 Nginx 代理（替代 devServer）
适用于后端未开 CORS、或需模拟真实网关行为（如鉴权头、SLB 转发逻辑）的场景。不依赖前端框架内置代理，更贴近线上链路。
- 监听与前端同源的端口（如 8080），避免浏览器跨域拦截
- 用 location /api/ 拦截请求，proxy_pass 转发到测试/预发后端地址（如
http://test-api.example.com/） - 必须设置 proxy_set_header 系列，确保后端能拿到真实客户端 IP 和协议信息
- WebSocket 支持需额外加
proxy_http_version 1.1和Upgrade头
生产环境：反向代理 + 静态托管
React/Vue 构建产物是纯静态文件，Nginx 同时承担两件事：托管 index.html 和代理 API 请求。二者路径需明确分离。
-
root 指向构建输出目录（如
/var/www/my-app），配合try_files $uri $uri/ /index.html支持前端路由 -
location /api/ 单独配置，proxy_pass 指向线上后端服务（注意结尾
/的语义：带斜杠表示重写根路径） - 若 API 地址随环境变化（如测试/正式共用同一份构建包），可用 sub_filter 在返回 HTML 时注入
window.__RUNTIME_CONFIG__变量 - 禁用 gzip 对 sub_filter 的干扰（加
gzip off;或控制gzip_proxied）
环境变量解耦：构建时注入为主，运行时注入为辅
绝大多数情况推荐构建时固化配置，更安全、可追溯、无运行时开销。
- Create React App 或 Vite 项目中，用
.env.production定义REACT_APP_API_BASE_URL=https://api.prod.com/v1 - 构建后变量直接内联进 JS，无需 Nginx 参与，也避免因 sub_filter 失效导致白屏
- 仅当需要“一份包部署多环境”（如运维一键切测试/预发/正式）时，才启用 Nginx sub_filter 注入 runtime config
- 注意：sub_filter 不处理压缩响应，务必检查 gzip 配置是否影响替换生效
常见陷阱提醒
很多问题不是配置写错，而是对 Nginx 路径重写的理解偏差。
-
proxy_pass http://backend/（结尾有/）→ 原路径中的/api/被丢弃，只转发/users -
proxy_pass http://backend（结尾无/）→ 完整转发/api/users，后端需能处理该前缀 - rewrite 中
break和last行为不同，调试时建议先用return 200 "path: $request_uri";打印实际路径 - 开发环境 Nginx 若监听
localhost:8080，而前端代码里写了绝对 URL（如fetch("https://...")），代理完全不生效
