Nginx可通过location前缀/正则匹配、map映射、hash一致性哈希四种原生机制实现URI路径分流；location最常用，map适合多规则复用，hash保障路径到节点的稳定性。
在 Nginx 中根据请求路径特征做流量分流，本质是识别 URI 的结构规律，并将不同模式的请求导向对应后端。不依赖外部模块，纯靠 location、map、hash 等原生机制就能实现清晰、可维护、高性能的路由策略。
用 location 前缀匹配做基础路径分流
这是最常用也最直观的方式，适合路径有明确层级或业务域划分的场景，比如 /api/、/admin/、/static/、/upload/ 等。
- location 指令按最长前缀匹配，Nginx 自动选择最精确的块，无需手动排序
- 每个块内用 proxy_pass 指向不同 upstream，注意末尾斜杠影响路径重写逻辑：proxy_pass 后带 / 会剥离 location 匹配部分；不带则保留
- 示例：访问 /api/v1/user → 匹配 location /api/ → 转发到 http://backend-api/（路径变为 /v1/user）
用正则匹配处理动态或复杂路径规则
当路径含变量、版本号、ID 或需提取参数时，正则 location（~ 或 ~*）更灵活。
- 用 ~* 实现大小写不敏感匹配，如 location ~* ^/json/\d{4}/ 可捕获年份路径
- 配合 $1、$2 等捕获组，可在 proxy_pass 中复用，例如 proxy_pass http://backend-json/$1/;
- 慎用 if + proxy_pass：if 在 location 外部属于非标准用法，易引发意外交互，推荐优先用正则 location 替代
用 map 指令统一管理多条件路径映射
当分流规则较多（如几十个路径前缀）、需组合多个维度（路径+Header+参数）或要复用变量时，map 是更健壮的选择。
- map 定义在 http 块中，把 $uri 或 $request_uri 映射为自定义变量（如 $backend_group）
- 支持嵌套判断和默认值（default），便于兜底和灰度控制
- 相比多个 location 块，map 更易读、易测试、性能开销更低，尤其适合网关层统一路由策略
用 hash $uri 或 hash $request_uri 做一致性分发
适用于需要“相同路径总到同一节点”的场景，比如缓存亲和、减少重复初始化、A/B 测试固定体验。
- hash $uri 对路径（不含查询参数）哈希，忽略参数变化，适合 RESTful 资源级路由
- hash $request_uri 包含完整 URI（含 ? 后参数），对参数顺序、大小写敏感；加 consistent 可缓解节点伸缩时的映射抖动
- 若需参数归一化（如忽略 utm_*、统一小写），需先用 map 或 rewrite 预处理变量，再哈希
