ngx_http_random_index_module 不支持灰度随机测试，仅能无状态随机选索引文件，缺乏用户一致性、权重控制和条件路由能力；应改用 map + split_clients 或 Lua 实现可配置、可追踪、可收敛的网关层灰度分流。
ngx_http_random_index_module 本身并不支持灰度随机测试，它仅用于在指定目录下**随机选择一个文件作为索引页**（如从 index.html、index-v2.html、theme-a.html 中随机选一个返回），且**无用户维度一致性、无权重控制、无条件路由能力**。因此，它不能直接实现“网关层多套首页主题的灰度随机测试”——这类需求本质需要的是**可配置、可追踪、可收敛的流量分发机制**。
为什么 random_index 不适合灰度测试
该模块工作在静态文件服务阶段，特点如下：
- 纯服务端随机：每次请求都重新随机，同一用户刷新页面可能看到不同主题，无法维持体验一致性
- 无上下文感知：不识别 Cookie、Header、IP、User-Agent 等灰度依据，无法按用户分群或设备类型分流
- 无权重策略：不能设置 5% 用户看 v2、95% 看 v1；所有文件被选概率均等（除非手动调整文件数量）
- 不支持 fallback 或降级：选不到有效文件时直接 403/404，无优雅兜底逻辑
真正可行的网关层灰度方案（Nginx 实现）
推荐使用 map + split_clients 或 lua-resty-balancer（OpenResty）组合，配合 Nginx 变量控制响应内容。以下是轻量级纯 Nginx 方案：
-
基于用户标识做稳定哈希分流：用
$cookie_uid或$arg_uid计算哈希，映射到固定版本，保证同用户始终看到同一主题 -
用 map 定义主题路径映射：
map $theme_version $index_file { default "index-v1.html"; "v2" "index-v2.html"; "theme-a" "theme-a/index.html"; "theme-b" "theme-b/index.html"; } -
用 split_clients 实现可控灰度比例（需在 http 块中）：
split_clients "$remote_addr$remote_port" $theme_version { 5% "v2"; 10% "theme-a"; 0% "theme-b"; # 暂未启用 * "v1"; } -
在 server 块中接入逻辑：
location = / { try_files /$index_file =404; }
增强建议：加一层 Lua 做动态决策（OpenResty）
若需更灵活策略（如：仅对登录用户、特定地域、新 iOS 设备启用 v2 主题），建议用 access_by_lua_block 动态设置 $theme_version：
- 读取
Cookie: abtest=theme-b强制指定 - 解析
User-Agent匹配微信内置浏览器，固定返回weixin-theme.html - 调用内部 API 查询用户实验分组（需异步非阻塞，建议预加载或缓存）
- 记录日志：
log_by_lua_block { ngx.log(ngx.INFO, "uid:", ngx.var.cookie_uid, " → theme:", ngx.var.theme_version) }
配套动作不可少
灰度不是只改 Nginx 配置，还需：
-
静态资源按主题隔离部署：如
/theme-v1/、/theme-v2/，避免文件名冲突 -
前端打点上报主题版本：PV 埋点携带
theme=v2，便于数据平台归因分析 -
提供手动切换开关（临时调试用）：如请求带
?theme=v2&debug=1覆盖默认策略（生产环境应限制 IP 或权限） - 监控异常比例：统计各主题 4xx/5xx、首屏时间、JS 错误率，及时熔断问题版本
不复杂但容易忽略：random_index 是个好用的“随机文件服务器”，但不是灰度网关。把分流逻辑交给 map、split_clients 或 Lua，才能真正支撑可运营、可回滚、可度量的主题灰度发布。
