map 指令仅用于变量映射，不能直接控制访问或分流；需结合 limit_except、location、proxy_pass 等实现静态资源方法限制或后端分流。
Map 指令本身是 Nginx 的 map 模块提供的变量映射功能，**不能直接控制 HTTP 方法的静态资源访问或实现后端分流**。它只负责根据某个输入变量（如 $request_method、$uri 等）生成一个新的变量值，真正的访问控制和路由分流需结合 if、location、proxy_pass 或 try_files 等指令协同完成。
为什么不能单靠 map 实现访问控制与分流
map 是纯变量计算模块，运行在请求解析早期，不参与响应生成、不触发重定向、不拒绝请求、也不转发流量。它只是“翻译”——比如把 GET 映射为 "allowed"，把 DELETE 映射为 "blocked"，但这个结果必须被其他指令消费才有意义。
基于 HTTP 方法的静态资源访问控制（推荐方案）
直接限制特定方法对静态资源路径的访问，无需 map，用 limit_except 最简洁安全：
-
禁止非 GET/HEAD 方法访问 /static/ 下所有文件：
location /static/ {
alias /var/www/static/;
limit_except GET HEAD {
deny all;
}
} - 该配置允许浏览器正常加载图片/CSS/JS（均为 GET），同时阻止 curl -X POST /static/config.json 这类恶意写操作
- 比用 map + if 更高效、更安全（
if在 location 中有已知陷阱）
基于 HTTP 方法的后端分流策略（map 可辅助，但非核心）
若需按请求方法将流量导向不同后端（例如：GET 走缓存集群，POST 走业务 API），可借助 map 预先标记目标 upstream，再由 proxy_pass 消费：
-
定义方法到 upstream 的映射：
map $request_method $backend_target {
default "api_backend";
GET "cache_backend";
HEAD "cache_backend";
OPTIONS "api_backend";
} -
在 server 块中使用该变量分流：
upstream cache_backend { server 10.0.1.10:8080; }
upstream api_backend { server 10.0.2.20:3000; }
server {
location /api/ {
proxy_pass http://$backend_target;
proxy_set_header Host $host;
}
} - 注意：
$backend_target必须是已定义的 upstream 名称，不能是 URL 字符串；且该方式仅适用于简单分流，复杂逻辑（如带 body 的 POST 判断）仍需后端处理
替代方案：更清晰、更可控的选择
多数场景下，以下方式比依赖 map + method 分流更合理：
- 按路径分流：/static/ → 文件服务器，/api/ → 后端服务，/upload/ → 专用上传接口 —— 清晰、符合 REST 约定
-
按请求头分流：用
$http_x_forwarded_for或自定义 header（如X-Route-To: cache）显式指定路由意图，比猜方法更可靠 - 动静分离 + 缓存层前置：静态资源走 CDN 或 Nginx 本地缓存，动态请求才打到后端 —— 性能与安全兼顾
