可通过Nginx split_clients模块结合稳定客户端指纹（如cookie_uid）实现一致性A/B灰度分流，利用rewrite将/static/请求重写为/static/a/或/static/b/路径，确保同一客户端始终命中同一分组且资源隔离。
可以通过 Nginx 的 split_clients 模块，结合客户端指纹（如 User-Agent、IP、Cookie 等）对静态资源请求做一致性分流，实现轻量、无侵入的 A/B 灰度测试。关键在于指纹提取要稳定、分流要一致、资源路径可区分。
1. 构建稳定可复用的客户端指纹
灰度效果依赖“同一客户端始终命中同一分组”，所以指纹需满足：确定性、低碰撞、服务端可提取。推荐组合方式：
-
优先使用 Cookie 中的自定义 ID（如
uid=abc123），由前端首次访问时生成并持久化，最稳定可靠 -
备选方案：IP + User-Agent 哈希，例如
md5($remote_addr $http_user_agent)，但注意 NAT 环境下 IP 可能共用，需评估精度 - 避免单独用 $remote_addr，因代理或移动网络易导致 IP 频繁变化；也避免纯随机值，无法保证一致性
2. 使用 split\_clients 定义灰度分组与变量
在 http 块中定义指纹源与分流逻辑，生成可用于 rewrite 或 proxy 的变量：
split_clients "${cookie_uid}${remote_addr}${http_user_agent}" $ab_group {
0.1% "a";
99.9% "b";
}
# 或更精细：50% A / 50% B
split_clients "${cookie_uid}" $ab_group {
50.0% "a";
* "b";
}
注意：split_clients 内部基于 MurmurHash2 计算，输入相同则输出恒定；* 表示兜底，确保全覆盖。
3. 将分组映射到静态资源路径
不修改业务代码，通过 Nginx 重写 URL 实现资源隔离。假设 JS/CSS/图片等静态资源放在 /static/ 下：
-
方式一：路径前缀区分 —— 将
/static/app.js重写为/static/a/app.js或/static/b/app.js -
方式二：版本参数透传（适合 CDN 场景） —— 添加
?v=a或&ab=a，后端或 CDN 根据参数回源不同版本 - 推荐方式一，因静态资源通常按路径缓存，天然支持 CDN 多版本并存，且无需后端解析参数
配置示例：
location ^~ /static/ {
rewrite ^/static/(.*)$ /static/$ab_group/$1 break;
root /var/www/html;
expires 1y;
}
4. 验证与上线注意事项
上线前务必验证分流一致性与资源可达性：
- 用同一浏览器（带固定 cookie_uid）多次请求，检查响应的资源路径或 HTTP 响应头（如自定义
X-AB-Group: a）是否稳定 - 确认
/static/a/xxx.js和/static/b/xxx.js在文件系统或对象存储中真实存在，避免 404 - 若使用 CDN，确保其未缓存原始路径（如
/static/app.js），而是缓存带分组前缀的路径，或配置忽略$ab_group相关变量的缓存键 - 灰度比例变更时，仅需调整
split_clients配置并 reload Nginx，无需重启或发版
不复杂但容易忽略的是指纹稳定性与缓存键设计——只要客户端每次带相同标识、Nginx 每次算出相同分组、CDN 每次缓存对应路径，整个链路就可持续支撑小时级甚至周级灰度实验。
