proxy_pass路径末尾是否加斜杠决定URI处理方式：不加则保留拼接，加则替换前缀；具体分四种情况——仅协议主机端口、结尾带/、非/结尾路径、带路径且结尾带/，各自对应不同转发逻辑。
proxy_pass 路径末尾加不加斜杠，本质是决定 Nginx 如何处理请求 URI 的路径部分——是“保留并拼接”，还是“替换前缀”。这个行为不取决于 location 是否带斜杠，而完全由 proxy_pass 后面是否包含 URI（哪怕只是一个 /）来触发。下面分四种典型组合说明，每种都对应明确的转发逻辑。
proxy_pass 不带任何路径（如 http://backend）
这是最易理解也最常误用的情况：proxy_pass 只有协议、主机和端口，末尾既无路径也无斜杠。
- location 匹配的部分会被原样保留在转发路径中
- Nginx 把整个原始请求 URI（包括 location 前缀）直接拼到 proxy_pass 后面
- 例如：location /api/ { proxy_pass http://127.0.0.1:3000; }，请求 /api/users → 后端收到 /api/users
- 适用场景：后端服务路由与前端路径结构完全一致，比如后端本身也以 /api 开头提供接口
proxy_pass 以斜杠结尾（如 http://backend/）
proxy_pass 显式指定了一个根路径 URI（/），Nginx 会执行“前缀替换”。
- location 匹配的完整路径前缀（如 /api/）被彻底剥离
- 剩余路径（如 /users）直接追加到 proxy_pass 的 / 后面
- 例如：location /api/ { proxy_pass http://127.0.0.1:3000/; }，请求 /api/users → 后端收到 /users
- 适用场景：后端部署在根路径（如 Spring Boot 默认、Express 根路由），不需要前缀
proxy_pass 带非斜杠结尾的路径（如 http://backend/v1）
proxy_pass 包含一个不以 / 结尾的子路径（如 /v1），Nginx 将其视为“替换目标”。
- location 匹配的路径部分（如 /api/）被整个替换成 proxy_pass 中的路径（/v1）
- 注意：因为末尾无 /，新路径与剩余 URI 之间**无分隔符**，会连在一起
- 例如：location /api/ { proxy_pass http://127.0.0.1:3000/v1; }，请求 /api/users → 后端收到 /v1users（不是 /v1/users！）
- 这种写法极易出错，一般应避免；若需该效果，建议显式补上 /
proxy_pass 带路径且以斜杠结尾（如 http://backend/v1/）
proxy_pass 提供了一个完整、规范的子路径（如 /v1/），Nginx 同样执行前缀替换，但拼接更安全。
- location 匹配的路径（如 /api/）被 /v1/ 替换
- 剩余路径（如 /users）被干净地追加到 /v1/ 后，自动形成正确层级
- 例如：location /api/ { proxy_pass http://127.0.0.1:3000/v1/; }，请求 /api/users → 后端收到 /v1/users
- 适用场景：前后端路径结构不同但有固定映射关系，比如前端 /api → 后端 /v1
