Nginx 的 map 指令可实现基于 Cookie 的静态资源灰度加载，通过 $cookie_version 映射 $resource_prefix 变量，再在 location 中用 alias 动态指向 /static/v1/ 或 /static/v2/ 目录，无需改业务代码、不依赖 Ingress，适合纯前端容器化部署。
直接用 Nginx 的 map 指令实现基于 Cookie 的静态资源灰度加载，核心是让不同用户看到不同版本的 JS/CSS/HTML 文件，无需改业务代码、不依赖 Ingress，适合纯前端容器化部署（如 Nginx 容器托管静态资源）。
明确目标与前提条件
该方案适用于：静态资源已容器化（例如打包进 Nginx 镜像），且需对真实终端用户按 Cookie 做灰度分流（比如 version=canary 的用户加载 /static/v2/ 下的资源）。它不涉及后端服务路由，只控制前端资源路径映射。
关键前提：
- 静态资源按版本目录组织，例如：
/static/v1/（稳定版）、/static/v2/（灰度版） - Nginx 容器中启用
map模块（默认内置，无需额外编译） - 用户请求中携带可识别的 Cookie，如
gray=on或version=canary
配置 map 指令动态映射资源路径
在 Nginx 主配置（nginx.conf 或 http 块）中定义变量映射：
map $cookie_version $resource_prefix {
default "/static/v1/";
"canary" "/static/v2/";
"beta" "/static/v2/";
}
这段配置表示：若请求 Cookie 中 version=canary 或 version=beta，则变量 $resource_prefix 被设为 /static/v2/；否则使用默认的 /static/v1/。
注意：$cookie_XXX 是 Nginx 内置变量，自动提取名为 XXX 的 Cookie 值，大小写敏感，空值或不存在时返回空字符串。
在 location 中应用映射结果
在 server 块中处理静态资源请求时，用 alias 或 root 结合该变量：
location /static/ {
alias $resource_prefix;
expires 1y;
add_header Cache-Control "public, immutable";
}
这样，当用户带 Cookie: version=canary 访问 /static/app.js，Nginx 实际读取的是容器内 /static/v2/app.js；其他用户则读取 /static/v1/app.js。
补充建议：
- HTML 入口页本身也建议做灰度（例如通过
map+try_files加载不同版本的index.html） - 确保灰度版资源构建时路径一致，避免因相对引用出错
- 可配合
add_header Set-Cookie "version=canary; Path=/; Max-Age=86400"主动种灰度 Cookie（需在对应响应 location 中配置）
容器化落地要点
将上述配置集成进容器镜像：
- 构建时把多版本资源一并 COPY 进镜像，例如：
COPY dist-v1/ /usr/share/nginx/html/static/v1/和COPY dist-v2/ /usr/share/nginx/html/static/v2/ - 覆盖默认
nginx.conf，或通过include加载自定义配置片段 - 运行时无需挂载配置卷，利于镜像不可变性与环境一致性
- 如需动态开关灰度，可用环境变量注入（如 Docker
--env NGINX_GRAY_ENABLE=true），再结合env指令与map条件判断
这种方式轻量、可靠，绕过复杂网关和 Ingress 注解，特别适合 CDN 回源层或边缘 Nginx 容器做静态资源灰度。
