Workerman 3.5.30 平滑迁移需通过端口隔离与连接级路由实现灰度，禁止依赖 reload；新旧版本分别监听2828/2829端口，Nginx权重分流，验证连通性后逐步切流，稳定24小时再停旧版。
Workerman 3.5.30 经典版本平滑迁移需绕开 reload 对长连接的无效性，避免旧连接持续运行旧逻辑导致灰度失控、状态不一致；必须通过连接级路由切换流量，而非依赖进程级代码重载。
确认新旧版本共存前提
启动新版本前，确保旧版 Workerman 进程仍在运行且监听独立端口（如 【2828】），新版本必须绑定不同端口（如 【2829】）——端口冲突会导致启动失败或旧服务被强制终止。
执行 php start.php status 查看当前运行端口与进程数，确认无其他 PHP 进程占用目标端口。
检查新版本代码中所有 require/include 路径是否已更新为相对路径或 Composer 自动加载，硬编码绝对路径在迁移后会直接报错。
启动新版本并验证基础连通性
在项目根目录下执行：php start.php start -d -p 2829，以守护进程方式启动新版本，监听 2829 端口。
等待 3 秒后，执行 php start.php connections -p 2829，确认返回连接数为 0 或可接受的测试连接数；若提示 “No such file or directory” 或端口未监听，说明 Worker 启动失败，需立即查看 【logs/workerman.log】 最末尾三行错误日志。
用 curl 或 WebSocket 客户端直连新端口（如 ws://localhost:2829），验证握手成功且能收发消息；失败则暂停后续步骤，优先修复协议初始化或 onConnect 逻辑。
配置 Nginx 权重分流实现灰度
第一步：编辑 Nginx 配置文件，在 http 块内新增两个 upstream：
upstream workerman_old { server 127.0.0.1:2828 weight=100; }
upstream workerman_new { server 127.0.0.1:2829 weight=0; }
第二步：修改 location /ws（或其他实际路径）的 proxy_pass 指向 workerman_old，确保当前全部流量仍走旧版。
第三步：执行 nginx -t 验证语法，无误后执行 nginx -s reload 重载配置——【此操作不中断任何现有连接】。
第四步：将 workerman_new 的 weight 改为 5，再次 nginx -s reload，观察监控中 2829 端口的新连接数是否缓慢上升；若无增长，检查 Nginx error.log 中是否有 “upstream timed out” 或 “no live upstreams” 报错。
按用户 ID 动态路由（可选增强）
方法一：在 onWebSocketConnect 或 onConnect 回调开头插入路由判断逻辑：
if (in_array($connection->uid % 100, range(0, 4))) { // 5% 用户走新逻辑
require_once __DIR__ . '/app/v2/handler.php';
return handleV2($connection, $data);
}
方法二：对接配置中心（如 Consul 或自建 HTTP 接口），用 file_get_contents 请求实时灰度策略，缓存结果并设置 30 秒 TTL，避免每次连接都发起远程调用拖慢 handshake。
注意：UID 必须在连接建立时已确定（如通过 URL 参数或 handshake 数据包解析），不能依赖登录后才赋值的 session ——长连接生命周期远超 session 生效窗口。
切断旧版流量并停机
当新版本稳定运行满 24 小时、错误率低于 0.1%、延迟 P95 ≤ 旧版 110%，执行以下操作：
将 Nginx 中 workerman_old 的 weight 设为 0，workerman_new 设为 100，nginx -s reload。
等待 5 分钟，确认旧端口 2828 的连接数归零（watch -n 1 'php start.php connections -p 2828'），再执行 php start.php stop -p 2828。
最后删除旧版启动脚本备份、清理 logs/old_* 日志文件夹——【不要提前删除，留作回滚依据】。
