核心是让前端Restful路径被后端正确识别：可原样透传（推荐，用proxy_pass http://backend/;）或转查询参数（如rewrite ^/api/...$ /user?id=$1? break;），关键在正则location捕获、proxy_pass末尾斜杠及避免滥用rewrite。
核心是让前端调用的 Restful 风格路径（如 /api/users/123）被后端服务正确识别——要么原样透传供其解析路径参数，要么转成查询参数（如 /user?id=123）。关键不在 rewrite 本身多复杂，而在匹配方式、捕获逻辑和与 proxy_pass 的配合是否合理。
用正则 location 捕获路径参数
只有带 ~ 或 ~* 的正则 location 才能提取变量。前缀匹配（如 location /api/）做不到。
- 写法示例：
location ~ ^/api/v1/users/(\d+)$——(\d+)捕获 ID，后续用$1引用 - 命名捕获更清晰（需 Nginx ≥ 1.11.0）：
location ~ ^/api/v1/users/(?<id>\d+)$</id>，引用为$id - 避免写成
location ~ /users/(\d+)这类宽泛匹配，容易误伤其他路径
rewrite 转成查询参数（适合老后端）
当后端只认 ?id=123 这种形式时，rewrite 是必要手段：
- 规则示例：
rewrite ^/api/v1/users/(\d+)$ /user?id=$1? break; - 末尾
?很关键：它清空原始 query string，防止变成/user?id=123&origin=q - 用
break终止当前 location 内 rewrite，直接走proxy_pass；用last会重新匹配 location，易引发循环
保持路径结构，仅剥离前缀透传（推荐做法）
现代框架（Spring Boot、Express 等）原生支持路径参数，无需改写。此时 rewrite 反而是冗余的：
- 简洁写法：
location /api/ { proxy_pass http://backend/; } - 注意
proxy_pass末尾的/：它会把请求/api/v1/users/123转发为http://backend/v1/users/123 - 若漏掉斜杠（
proxy_pass http://backend;），则完整路径/api/v1/users/123会被转发过去，后端可能收不到预期路径
避开常见坑
rewrite 不是万能胶，滥用反而增加维护成本：
- 别在同一个 location 里堆多个 rewrite；优先用
proxy_pass截断 + 后端解析 - 避免
if块套 rewrite，Nginx 官方明确不推荐，行为难预测 - 调试时加
error_log /var/log/nginx/rewrite.log notice;，配合rewrite_log on;查执行过程
