灰度发布的核心是“可逆的流量控制”，PHP需通过配置中心（如Apollo、Nacos）主动拉取规则，5秒内切回全量；用户标识优先取$_SERVER['HTTP_X_USER_ID']，切流逻辑应置于PSR-15中间件process()中。
灰度发布的核心不是“自动”，而是“可逆的流量控制”
PHP 本身没有内置灰度能力，所有自动化都建立在外部调度 + PHP 应用配合的基础上。关键不是写多少 PHP 代码，而是让 PHP 能快速响应配置中心下发的规则，并在出问题时 5 秒内切回全量——这点决定了灰度是否真有用。
getenv('GRAY_RULE') 不可靠，改用配置中心 SDK 主动拉取
直接读环境变量或本地 JSON 文件会导致灰度规则延迟、不一致、无法实时生效。必须接入配置中心（如 Nacos、Apollo、Consul），由 PHP 进程主动轮询或监听变更。
- 用
ApolloPHP或nacos-php-sdk，不要自己封装 HTTP 请求 - 务必设置超时：
timeout=3，失败时 fallback 到内存缓存的上一版规则，不能直接报错 - 灰度配置项建议统一用
gray.enabled（bool）、gray.percentage（int）、gray.users（array）三个字段，避免多层嵌套解析 - 轮询间隔别设成 1s——配置中心扛不住；推荐 10s，配合长连接或 webhook 推送更优
用户标识怎么取？$_SERVER['HTTP_X_USER_ID'] 比 $_COOKIE['uid'] 更稳
灰度判断依赖稳定、不可伪造的用户身份。前端传来的 cookie 或 token 解析结果容易被绕过或丢失，而反向代理（如 Nginx）注入的 header 更可控。
- Nginx 配置里加：
proxy_set_header X-User-ID $cookie_uid;或从 JWT claim 提取后透传 - PHP 中优先取
$_SERVER['HTTP_X_USER_ID']，为空再降级到$_REQUEST['uid']，但要记录告警 - 别用 IP 做灰度依据：NAT 环境下千人共 IP，CDN 下全是边缘节点 IP
- 哈希计算用
siphash（PHP 8.1+）或md5($uid . $rule_version)，确保同用户在不同机器结果一致
切流逻辑写在中间件里，但别在 __construct() 里初始化规则
把灰度判断塞进每个 Controller 方法里会重复、难维护；放在构造函数里又会导致规则加载时机错乱（比如 CLI 脚本启动时还没连上配置中心）。
立即学习“PHP免费学习笔记（深入）”；
- 用 PSR-15 中间件，在
process()开头调用$this->grayRouter->shouldEnterGray() -
shouldEnterGray()内部做三件事：检查启用开关 → 获取当前用户 ID → 按百分比/白名单/分组规则返回 bool - 绝对不要在框架启动时（如 Laravel 的
ServiceProvider::register()）加载灰度配置——那时配置中心可能还没 ready - 记录灰度决策日志，字段至少含：
uid、rule_version、hit_gray、reason（比如 “percentage: 5%” 或 “in white_list”）
真正卡住落地的，从来不是 PHP 怎么写 if-else，而是配置中心连不上时要不要阻断请求、灰度接口和主干接口数据库事务怎么隔离、AB 测试指标怎么对齐。这些不在 PHP 代码里，但在每次上线前得有人盯着。
