灰度路由通过请求上下文中的分流因子判断版本，优先级为登录态用户标识＞请求头标记＞Cookie回退＞IP哈希；禁用随机数以保证可复现性。
灰度路由怎么判断用户该走旧版还是新版？
核心靠请求上下文里的可识别、可控制的分流因子，比如 user_id、cookie 中的 gray_flag、HTTP header 里的 X-Gray-Version，或者 IP 段哈希。别用随机数——没法复现，排查问题时会抓狂。
推荐优先级：登录态用户标识 > 请求头显式标记 > Cookie 回退 > IP 哈希（仅限无用户态场景）。例如：
if (isset($_SERVER['HTTP_X_GRAY_VERSION']) && $_SERVER['HTTP_X_GRAY_VERSION'] === 'v2') {
$useNew = true;
} elseif (isset($_COOKIE['gray_flag']) && $_COOKIE['gray_flag'] === '1') {
$useNew = true;
} else {
$useNew = (crc32($_SERVER['REMOTE_ADDR']) % 100) < 5; // 5% 流量
}
PHP中如何不侵入业务代码做灰度分发？
在框架入口或中间件层统一拦截，避免每个接口都写判断逻辑。Laravel 可用中间件，原生 PHP 建议在 index.php 或网关层（如 Nginx + FastCGI）注入路由决策。
关键点：
立即学习“PHP免费学习笔记（深入）”；
- 分流逻辑必须幂等：同一用户/请求多次调用结果一致，不能这次走新、下次走旧
- 灰度开关要可动态关闭，建议从配置中心（如 Redis）读取
gray.enabled和gray.ratio，而非硬编码 - 记录日志时务必打上
gray: true/false字段，否则后续查问题无法区分路径
灰度接口返回不一致导致前端报错怎么办？
本质是契约断裂。新版接口字段增减、类型变更、错误码调整，都会让旧前端崩溃。不能只测“能跑”，得测“兼容性”。
实操建议：
- 所有灰度接口响应必须通过 JSON Schema 校验，旧版 schema 和新版 schema 都要加载，用
jsonschema类库做双校验 - 对新增字段加
nullable: true，删除字段至少保留 1 个发布周期，返回空值或默认值 - 用
Acceptheader 或 query 参数（如?api_version=2）显式声明版本，比纯路径分流更可控
为什么上线后灰度流量突然飙升到 100%？
常见原因就三个：Redis 配置键过期失效、Nginx 变量未正确传递（比如 $http_x_gray_version 在 proxy_pass 后丢失）、或者 $_SERVER 数组被框架中间件意外覆盖（ThinkPHP 早期版本有这问题）。
排查顺序：
- 先 curl 带 header 测试：
curl -H "X-Gray-Version: v2" http://api.example.com/user，确认是否生效 - 检查日志里
$_SERVER['HTTP_X_GRAY_VERSION']是否为 null —— 如果是，说明 header 没透传 - 查 Redis：
GET gray:ratio，确认值是字符串"5"而不是整数5（PHP 的==会弱类型转换出错）
最易忽略的是：灰度逻辑写在了 autoload 之后、但某些异常流程（如 404 或中间件提前 exit）绕过了它——务必把分流判断放在整个请求生命周期最早可执行的位置。
