ThinkPHP灰度发布需手动实现分流逻辑，核心是动态控制Route::rule()的目标控制器映射，通过URL通配符或Header提取版本号，结合中间件与配置中心实现可热更新的灵活路由分发。
ThinkPHP 本身不提供开箱即用的灰度发布能力，所有分流逻辑必须由你手动植入路由、中间件或业务层，框架只负责执行你定义的规则。
怎么让不同用户走不同版本的控制器
核心不是改框架，而是控制 Route::rule() 的目标控制器映射。常见做法是把版本号从 URL 或 Header 提取出来，再动态拼接类名或方法名。
- URL 路径带版本（如
/api/v2/user/123）：用:version通配符捕获，但必须放在分组第一段，例如Route::group('api', function(){ Route::rule(':version/user/:id', 'api.v<code>version.User/read'); }); —— 注意这里v<code>version是字符串拼接，不是变量插值，得靠 PHP 字符串处理或闭包回调实现真实路由分发 - Header 带版本（如
Accept: application/vnd.myapp.v2+json）：在中间件里调用$request->header('accept')，用正则提取v\d+，再存入$request->attr('api_version', $v)，后续控制器可通过$this->request->attr('api_version')获取 - 避免直接在路由规则里写死
v1或v2，否则每次加版本都要改路由文件，违背灰度可配置原则
中间件里做分流容易踩哪些坑
中间件是做灰度最灵活的位置，但也是最容易破坏 ThinkPHP 原生流程的地方。
- 不要在中间件里直接修改
$request->action或$request->controller，ThinkPHP 后续仍会按原始 URL 匹配路由，导致 404；正确做法是提前返回响应，或通过think\Response重定向到内部 URL - 分流逻辑别写死比例（如固定 5%），应从配置中心或数据库读取开关状态，支持运行时热更新；否则每次调整都要重启服务
- 如果用了多级中间件，确保灰度中间件在路由中间件（
think\middleware\LoadLangPack等）之前执行，否则请求可能已被拦截或参数已解析完毕 - 测试时记得清空
/runtime/cache/，否则路由缓存可能导致新规则不生效
如何配合数据库字段灰度平滑升级
API 版本灰度和数据库结构灰度要同步设计，否则会出现“新接口读不到新字段”或“旧接口写崩新结构”的问题。
立即学习“PHP免费学习笔记（深入）”；
- 新增字段必须允许
NULL或设默认值，禁止直接加NOT NULL，否则旧代码 INSERT 会报错 - 读操作建议统一走 DAO 层封装：根据当前 API 版本决定查
status还是status_v2，而不是在每个控制器里重复判断 - 写操作坚持“兼容写”——新老字段都更新，哪怕只是冗余赋值，确保下游无论哪个版本都能读到一致数据
- 上线后监控
fallback日志，比如某次请求同时读了status和status_v2且值不一致，就说明灰度逻辑或数据回填有问题
真正难的不是写分流代码，而是让灰度策略能被观测、可回滚、不耦合业务逻辑。比如把用户 ID 哈希值作为分流依据时，必须保证哈希算法稳定（不能用 siphash 这种 PHP 版本差异大的），否则同个用户在不同服务器上可能被分到不同版本，引发状态混乱。
