workerman 升级 php 必须重启进程，无法热切换；需确认 cli 的 php 命令真实版本（非 web 环境），并解决 composer.lock 锁定、扩展缺失（pcntl/posix/sockets）、opcache 缓存旧字节码三类隐蔽问题。
Workerman 本身不支持热切换 PHP 解释器，所谓“业务不间断升级 PHP”本质是错觉——PHP 版本变更必须重启 Workerman 进程才能生效，但可以控制中断范围和时间，做到对终端用户无感。
确认 CLI PHP 版本才是唯一有效的版本
Workerman 是命令行程序，只认 php 命令指向的二进制。Web 环境（如 Nginx + php-fpm）用的 PHP 版本完全无关。
- 执行
which php查路径，再用该路径直接运行/usr/bin/php -v（替换成你看到的实际路径）确认真实版本 - 宝塔用户别只看面板里“网站设置”的 PHP 版本，得跑
bt default php 81或类似命令切 CLI 默认版本 - Ubuntu/Debian 用户常忽略
update-alternatives --config php，它才真正决定php命令指向谁 - Mac 上用 Homebrew 安装多个 PHP？执行
brew unlink php@8.0 && brew link php@8.1才算切换成功
升级 PHP 后 Workerman 启动失败的三个隐蔽原因
明明 php -v 显示 8.2，php start.php start 却报 PHP version too low，大概率卡在这三处：
-
composer.lock锁着旧版：Workerman 5.x 的composer.json有"php": "^8.1"约束，旧 lock 文件可能仍指向 4.x，必须重跑composer update workerman/workerman - 扩展没装全：Workerman 强依赖
pcntl、posix、sockets，某些精简镜像（如 Alpine）要手动装apk add php81-pcntl php81-posix - opcache 缓存了旧字节码：即使 PHP 版本升了，
opcache.enable=1时 reload 仍跑旧逻辑；临时方案是加opcache_reset()到onWorkerStart，生产环境建议设opcache.revalidate_freq=0
reload 不等于升级 PHP，stop+start 才是唯一可靠方式
php start.php reload 只重新加载回调内动态引入的文件（如 onMessage 里 require 的业务类），它不会重启主进程，也不会切换 PHP 解释器。
- 改了
start.php顶层代码、Worker构造参数（如$worker->count）、全局常量 → 必须php start.php stop && php start.php start - CI/CD 流程中写一句
php start.php reload很容易“看起来成功实则无效”，部署后务必用ps aux | grep workerman看进程启动时间戳是否更新 - 如果业务允许秒级中断，stop+start 实际停机时间通常在 200ms 内（取决于子进程退出速度）；若真需零中断，得上双集群滚动切换，Workerman 自身不提供该能力
最易被忽略的一点：PHP 升级后，Workerman 子进程异常退出行为会变敏感——5.0 默认立即重启崩溃进程，可能暴露旧项目里一直存在的内存溢出或段错误，这些在 4.x 下可能被静默吞掉。上线前务必查日志里有没有 Segmentation fault 或 Allowed memory size exhausted。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
