Nginx location前缀匹配关键在优先级而非书写顺序：^~可截断后续匹配，普通前缀仅参与最长匹配且不阻正则；误用会导致静态资源被正则劫持，应优先用^~锁定路径。
要通过 location 块前缀匹配精确控制请求路径，关键不是“写得越多越准”，而是理解并利用 Nginx 固定的匹配优先级顺序——尤其是 ^~ 和普通前缀（无修饰符）的行为差异。很多配置失效，其实是误以为“先写的先生效”，实际是规则优先级说了算。
用 ^~ 实现高效且确定的前缀拦截
^~ 是前缀匹配中唯一能“截断后续检查”的修饰符。只要 URI 以指定路径开头，Nginx 就立即采用该 location，不再尝试任何正则（哪怕后面有更贴切的 ~ 或 ~* 规则）。
- 适合静态资源、API 前缀、管理路径等需要快速响应、避免被正则干扰的场景
- 例如：
location ^~ /api/v2/ { proxy_pass http://backend; }，请求/api/v2/users会命中，且不会被后面的location ~ \.php$或location ~* \.(js|css)$干扰 - 注意：
^~不支持正则语法，只做纯字符串前缀比对，不区分大小写，也不支持通配符
普通前缀（无修饰符）需配合最长匹配原则使用
像 location /admin/ 这类写法属于普通前缀匹配，它本身优先级低于 = 和 ^~，也低于所有正则；但它会在“没有更高优先级匹配”时，参与最长前缀竞争。
- 多个普通前缀同时匹配时，Nginx 选最长的那个，比如
/admin/user/比/admin/更长，优先级更高 - 但要注意：它不会阻止正则检查。如果后面有
location ~ /admin/.*\.log$，而请求是/admin/access.log，就会走正则而非这个前缀块 - 因此，若想确保某段路径完全由前缀接管，必须用
^~，而不是依赖“写在前面”或“路径够长”
避免常见陷阱：别混淆前缀和正则的执行逻辑
很多人把 location /static 和 location ~* \.js$ 写在一起，却期望 JS 文件走前缀块——这是错的。因为正则优先级高于普通前缀，只要 URI 符合正则，就跳过前缀块。
- 错误示范：
location /static/ { ... }+location ~* \.(js|css|png)$ { ... }→/static/app.js会走正则，不是前缀 - 正确做法：把静态资源路径用
^~锁死，如location ^~ /static/ { root /var/www; }，这样所有以/static/开头的请求都进这里，正则完全不触发 - 如果确实需要按扩展名分流（比如 JS 单独压缩），就把正则放在更上层、更具体的前缀内，或改用内部重写+条件判断
调试技巧：验证实际命中哪个 location
Nginx 不提供运行时 location 匹配日志（默认关闭），但可通过简单手段确认行为是否符合预期：
- 在各 location 块中临时加入
return 200 "matched: /xxx";，用 curl 测试不同路径，直接看返回内容 - 用
nginx -t检查语法没问题后，务必 reload 而非 restart，避免配置未生效被误判 - 注意 URI 归一化：Nginx 在匹配前会自动去除重复斜杠、解析
..，所以/a//b/../../c实际按/c匹配
