Yii框架可通过beforeAction拦截请求并基于Header/Cookie/GET参数打灰度标记，结合缓存驱动的动态配置实现可控灰度发布，关键在于流量入口控制与标记透传。
Yii 框架本身不内置灰度发布能力，但可以通过请求链路拦截 + 缓存/配置驱动的路由决策，在应用层低成本实现可控灰度。关键不在“换框架”，而在“控流量入口”和“透传标记”。
在 Yii 2 中用 beforeAction 拦截请求并打标
灰度的前提是识别灰度用户或请求，Yii 的控制器生命周期钩子是最轻量的切入点。不要依赖中间件（Yii 2 没原生中间件概念），直接在基类控制器里统一处理：
-
beforeAction是唯一可靠时机：它在 action 执行前、视图渲染前、模型加载后触发，能安全读取 Header、Cookie、GET 参数 - 优先从
X-Gray-VersionHeader 取值， fallback 到gray_versionCookie 或g查询参数，避免污染业务逻辑 - 标记必须写入
Yii::$app->params['grayVersion']或自定义组件（如Yii::$app->grayRouter），不能只存在局部变量里 - 示例代码片段：
public function beforeAction($action) { $grayVer = Yii::$app->request->getHeaders()->get('X-Gray-Version') ?: Yii::$app->request->getCookies()->getValue('gray_version') ?: Yii::$app->request->get('g'); if ($grayVer && in_array($grayVer, ['v2', 'canary'])) { Yii::$app->params['grayVersion'] = $grayVer; Yii::$app->session->set('grayVersion', $grayVer); // 可选，用于后续页面透传 } return parent::beforeAction($action); }
用 Yii::$app->cache 控制灰度配置热更新
硬编码灰度比例或白名单等于埋雷。真正可维护的做法是把灰度规则存在缓存里，由外部系统（如配置中心、DB 表）动态写入，Yii 应用只负责读取和判断：
- 缓存 key 建议用
gray:config:{env}（如gray:config:prod），value 是 JSON 字符串：{"weight":15,"users":["u123","u456"],"enabled":true} - 每次请求都调用
Yii::$app->cache->get('gray:config:prod')，失败则 fallback 到本地配置文件（防缓存雪崩） - 注意缓存过期时间设为 30–60 秒，既保证策略及时生效，又避免高频穿透到后端存储
- 权重计算别用
rand()：PHP-FPM 进程间不共享状态，会导致实际比例严重失真；改用用户 ID 哈希取模：abs(crc32($userId) % 100)
在 Model / Service 层做灰度分支调用
标记和配置只是第一步，真正起作用的是业务代码里的条件路由。重点不是“if else”，而是让灰度逻辑与主流程解耦：
- 避免在 Controller 里写
if (Yii::$app->params['grayVersion']) { ... }—— 这会让测试、复用、监控全部失效 - 把灰度适配封装进独立 Service 类，例如
ProductService构造时注入Yii::$app->grayRouter实例，由它决定调用ProductV1Repository还是ProductV2Repository - 数据库查询层可用 Yii 的
Query::addSelect()或andWhere()动态加灰度字段（如is_gray_enabled），但前提是表结构已兼容双版本 - 模板渲染层用
$this->render('@app/views/product/_detail_v2', $data)而非硬编码路径，配合Yii::$app->view->theme切换整套灰度视图
回滚不是删代码，而是关开关
生产环境最怕“改完发现不对，赶紧 git revert”，这会引入合并冲突和部署延迟。灰度回滚必须是秒级、无侵入的操作：
- 所有灰度开关最终落地为缓存中的布尔值或权重数字，
Yii::$app->cache->set('gray:enabled:prod', false)即刻生效 - 严禁在代码中写
if (YII_ENV_PROD && date('H') > 12)这类时间开关 —— 它无法被监控告警捕获，也无法被 SRE 团队统一操作 - 日志中必须记录每条灰度请求的判定依据（如
"gray_decision: user_id=u123, hash=47, weight=15, matched=true"），否则出问题时无法定位是规则错还是执行错 - 特别注意 Session 和 Cookie 的灰度状态清理：用户切回旧版后，要主动删除
grayVersionCookie 并清空 session 中对应字段，否则下次访问仍走灰度路径
真正难的不是写几行 if，而是让灰度规则可观察、可审计、可原子切换。缓存键设计、哈希算法选择、标记透传链路完整性——这些细节漏掉任何一个，灰度就变成黑盒实验。
