升级workerman 5.2.3需三步：一查环境兼容性（php≥7.3、pcntl/posix启用且关键函数未禁用）；二执行composer更新并适配api变更（如$pidfile默认值、send()不再自动json_encode、改用worker::$eventloopclass）；三验证reload是否生效（仅重载回调内动态代码，顶层逻辑须stop+start，同时禁用或刷新opcache）。
升级到 Workerman 5.2.3 需要分三步走：确认环境兼容性、执行版本更新、验证逻辑生效。不是简单改个 composer 版本号就能完事，尤其旧项目常卡在 reload 失效、opcache 缓存、API 行为变更这几个点上。
检查 PHP 和扩展是否达标
Workerman 5.2.3 要求 PHP ≥ 7.3（不支持 7.2 及更早），且必须启用 pcntl 和 posix 扩展（Linux/macOS 必需，Windows 不支持）。运行以下命令快速验证：
-
php -v—— 确认版本 ≥ 7.3 -
php --ri pcntl和php --ri posix—— 确保扩展已加载 -
php -i | grep disable_functions—— 检查是否禁用了pcntl_fork、pcntl_signal等关键函数
更新依赖并处理 API 兼容性
进入项目根目录，用 Composer 升级到 5.2.3：
- 执行
composer require workerman/workerman:5.2.3 --update-with-dependencies - 重点检查并修改以下常见不兼容项：
-
Worker::$pidFile默认值从''改为null，若你代码里依赖该路径做进程管理（比如脚本读取 pid 文件杀进程），需显式赋值：Worker::$pidFile = '/path/to/pid'; -
ConnectionInterface::send()不再对数组/对象自动json_encode，发送前必须手动序列化：$connection->send(json_encode($data)); - 废弃了
Worker::setEventLoopClass()，改用静态属性：Worker::$eventLoopClass = MyEventLoop::class;
-
确保代码更新真正生效
升级后业务逻辑没变？大概率是 reload 没触达真实代码，或被 opcache 锁死：
-
reload 只重载回调内动态加载的代码：比如
onMessage中require的处理器文件；但start.php顶层写的require_once 'config.php'或全局函数定义，reload完全不执行——这类必须php start.php stop && php start.php start -d -
关闭 opcache 或强制刷新：若
opcache.enable=1（默认开启），请设opcache.revalidate_freq=0，或在start.php开头加opcache_reset();（仅限开发/测试环境） -
验证信号是否送达：执行
php start.php reload后，用ps aux | grep workerman查看子进程启动时间戳是否更新；也可在onWorkerStart里加日志，确认新进程是否加载了新逻辑
部署时注意 reload 和 stop+start 的区别
CI/CD 自动化中，一句 php start.php reload 很容易“看似成功实则无效”：
- 只改了
onMessage内部逻辑 →reload完全够用，连接无中断 - 改了
start.php本身、$worker->count、监听端口、全局常量或 Worker 构造参数 → 必须stop + start，否则配置不会生效 - 建议在部署后加健康检查：调用
/health接口 +ps查进程时间戳，双重确认
