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 本地缓存，动态请求才打到后端 —— 性能与安全兼顾