Workerman 5.2版本并不存在，所谓“升级到5.2”实为迁移到官方真实版本v5.1.x（如v5.1.24）；需确认实际版本、清除非法版本约束、以GitHub Latest release为准，并严格遵循v5.1.x的PHP要求、API变更与reload限制。
Workerman 3.5项目升级到所谓“5.2”版本时，实际要面对的是迁移到官方真实存在的v5.1.x系列（如v5.1.24），因为【Workerman 5.2版本并不存在，所有声称的5.2均为误传、私有魔改或环境组合误解】。直接按“5.2”去改配置、查文档、调API，必然踩坑。
确认真实目标版本
第一步：执行composer show workerman/workerman或查看vendor/workerman/workerman/VERSION文件内容，确认当前实际版本与待升级目标版本。若显示v5.1.24，则一切操作均以v5.1.x官方CHANGELOG为准，而非虚构的5.2。
第二步：删除composer.json中所有形如"^5.2"或"5.2.*"的非法版本约束——这会导致composer update失败或意外降级。
第三步：访问GitHub Releases页面，认准Latest release标签下的v5.1.x版本号，以此为唯一可信依据。
PHP与扩展兼容性强制检查
Workerman v5.1要求PHP ≥ 7.3，且必须启用pcntl、posix扩展（Linux专属）；event扩展虽非强制，但高并发场景下缺失会导致CPU利用率飙升。
运行php -v和php --ri opcache，确保CLI与Web SAPI的PHP版本一致；若opcache.enable=1（默认开启），必须同步设置opcache.revalidate_freq=0，否则reload后仍运行旧字节码。
【不要跳过opcache重置验证——这是代码不生效最常见原因】
启动脚本与Worker构造变更
方法一：Worker构造参数迁移
旧写法：$worker = new Worker('text://0.0.0.0:8181');
新写法：$worker = new Worker('websocket://0.0.0.0:8181');——协议头必须显式声明，text协议已被弃用，强行使用会静默失败。
方法二：全局配置项重赋值
Worker::$pidFile默认值从空字符串''改为null，若你依赖该路径做进程管理（如kill -USR1 $(cat /var/run/workerman.pid)），必须在start.php开头显式赋值：Worker::$pidFile = '/var/run/workerman.pid';
方法三：事件循环类设置方式变更
废弃Worker::setEventLoopClass()，改用静态属性：Worker::$eventLoopClass = \Workerman\Events\Select::class;（若需指定）。
连接层与消息发送行为修正
ConnectionInterface::send()不再对数组/对象自动json_encode。旧代码$connection->send(['code'=>0,'msg'=>'ok'])会直接报错。
必须手动序列化：$connection->send(json_encode(['code'=>0,'msg'=>'ok'], JSON_UNESCAPED_UNICODE));
注意：WebSocket客户端接收的是字符串，不是原生JSON对象；前端需自行JSON.parse()，这点与旧版隐式转换逻辑完全不同。
生命周期回调加载范围收缩
php start.php reload只重新加载onMessage/onConnect/onClose等回调内动态引入的文件，start.php顶层require_once的配置文件、全局函数定义、常量声明不会被重载。
若修改了数据库配置或路由映射表，必须执行php start.php stop && php start.php start -d，而非reload。
这一步不可省略——否则你会看到日志里反复打印旧配置，却找不到问题在哪。
