斜杠结尾是nginx location匹配与转发的关键开关：/api/为严格前缀匹配，/api为宽松匹配；末尾斜杠触发301重定向；proxy_pass路径拼接依赖二者斜杠组合；建议统一使用带斜杠的location与proxy_pass配对。
斜杠结尾不是可有可无的格式习惯，而是直接决定匹配范围和转发行为的关键开关。
location /api/ 和 location /api 的匹配逻辑完全不同
前者是“带斜杠的前缀匹配”，只认以 /api/ 开头的路径；后者是“宽松前缀匹配”，只要 URI 以 /api 这个字符串开头就命中。
-
/api/ ✅ 匹配：
/api/、/api/users、/api/v1/login；❌ 不匹配：/api（缺尾部斜杠）、/apixyz、/API/ -
/api ✅ 匹配：
/api、/api/、/api/users、/apixyz、/api123；❌ 不匹配：/v1/api、/API
误用 location /api 容易导致接口被意外捕获，比如 /api-token 或 /api-v2 也被匹配，后端却不存在对应接口，结果返回 404 或错误响应。
斜杠影响重定向行为（仅对特定请求）
当配置为 location /xxx/ { ... }（末尾带斜杠），且用户访问的是不带斜杠的同名路径（如 /xxx），Nginx 会自动返回 301 重定向到 /xxx/。
- 触发条件很具体：必须是 location 以
/结尾，且请求 URI 恰好等于该前缀去掉末尾斜杠（例如location /films/+ 请求/films） - 这个重定向只针对这一种情况；
/films/cat.jpg或/films/都不会触发 - 如果不想重定向，可显式加一条
location = /films { proxy_pass ...; }精确覆盖
斜杠组合决定 proxy_pass 转发路径怎么拼
location 尾部斜杠和 proxy_pass 尾部斜杠要配对使用，否则转发路径可能多出双斜杠、漏掉路径段，甚至把请求发到错误地址。
-
location /api/ { proxy_pass http://backend/; }→/api/users转发为http://backend/users（推荐） -
location /api { proxy_pass http://backend/; }→/api转发为http://backend//（双斜杠，部分后端拒绝） -
location /static/ { proxy_pass http://cdn; }→/static/logo.png发到http://cdn/static/logo.png（路径被保留） -
location /static/ { proxy_pass http://cdn/; }→ 同样请求发到http://cdn/logo.png（路径被替换）
通用建议：对外暴露的路径段（如 /api/、/static/）统一用带斜杠的 location，proxy_pass 也带斜杠，形成清晰的“路径替换”关系。
优先级与共存风险
如果同时写了 location /api 和 location /api/，Nginx 按最长前缀匹配，/api/ 总是优先生效——但这种写法本身容易引发维护困惑和意外交互。
- 避免在同一 server 块中并存语义相近又不完全重叠的 location
- 需要精确控制目录边界时，只留
/api/；需要兜底或兼容旧路径时，再单独加= /api或location ^~ /api$ - 正则匹配（
~或~*）优先级低于=和^~，但高于普通前缀，慎用于含斜杠的路径判断
