map指令不直接用于location匹配，而是将请求特征映射为变量，再通过if或proxy_pass等间接影响路由；它支持正则匹配、多级组合与动态头控制，但须注意作用域限制与执行时机。
在 Nginx 中，map 指令本身不“生成变量”用于 Location 匹配，但它能将请求特征（如 URI、Host、Header）映射为自定义变量值，再通过 if 或 try_files 等指令间接影响匹配行为——这是简化复杂 Location 逻辑的核心技巧。
用 map 提前归类请求特征，替代大量重复 location 块
当需按 URI 前缀、文件类型、API 版本等做不同处理时，直接写多个 location ^~ 或 location ~ 易冗余且难维护。改用 map 将共性提取为变量，再统一用一个 location 处理：
- 在
http块中定义映射关系，例如区分静态资源与动态接口：
map $uri $resource_type {
~*\.(js|css|png|jpg|gif|woff2?)$ static;
~*^/api/v1/ api_v1;
~*^/api/v2/ api_v2;
default app;
}- 在
server块中用单个location /+if分支判断（注意：if在 location 内是安全的）：
location / {
if ($resource_type = static) {
expires 1y;
add_header Cache-Control "public, immutable";
break;
}
if ($resource_type = api_v1) {
proxy_pass http://backend_v1;
break;
}
if ($resource_type = api_v2) {
proxy_pass http://backend_v2;
break;
}
# 默认走主应用
proxy_pass http://app_backend;
}这样避免了写 5–6 个相似的 location，逻辑集中、易读易调。
结合正则捕获组 + map 实现动态后端路由
若需从 URI 中提取 ID、租户名等并转发到对应后端，map 可配合 、 使用（需先用 rewrite 或 set 预处理，因 map 不支持直接捕获）：
- 先用
rewrite提取关键字段到变量（在server或location中）：
set $tenant "";
set $service "";
if ($host ~ "^([a-z0-9\-]+)\.example\.com$") {
set $tenant $1;
}
if ($uri ~ "^/svc/([a-z0-9\-]+)/") {
set $service $1;
}- 再用
map组合决策（如 fallback 到默认集群）：
map "$tenant:$service" $upstream_backend {
"prod:auth" auth-prod;
"staging:auth" auth-staging;
"prod:billing" billing-prod;
default default_backend;
}- 最后统一代理：
location /svc/ {
proxy_pass http://$upstream_backend;
}规避常见陷阱：map 的作用域与执行时机
map 是在请求初始化阶段执行的，仅支持 http 块；它不能引用其他变量的运行时结果（如 $arg_x 在 map 中可用，但 $my_var 若由 set 动态赋值，则可能为空）：
- 确保被映射的源变量（如
$uri、$host）是 Nginx 内置且稳定可用的 - 避免在
map中依赖set、rewrite生成的变量——它们执行晚于map -
map不支持嵌套或条件嵌套，复杂逻辑建议拆成多层 map 或用 Lua（OpenResty）补充
进阶：用 map 控制缓存策略与响应头
根据请求特征动态设置 Cache-Control、Content-Type 或重定向规则，无需为每个路径单独配置：
- 示例：对含
v=xxx查询参数的静态资源启用强缓存，其余设为 no-cache：
map $args $cache_policy {
~v=[a-f0-9]{8,} "public, max-age=31536000, immutable";
default "no-cache, must-revalidate";
}
# 在 location 中直接使用：
add_header Cache-Control $cache_policy;这种写法比用 if ($args ~ v=) 更轻量，且 map 查找是 O(1) 哈希匹配，性能更优。
