Workerman 5.0 升级后代码不生效，需确认 reload 是否触达业务逻辑、opcache 是否禁用、是否兼容 API 变更及 PHP 版本，并区分 reload 与 stop+start 场景，验证信号送达与进程真实重启。
Workerman 5.0 升级后代码不生效？先确认 reload 能否触达业务逻辑
Workerman 的 php start.php reload 只会重新加载在 onConnect、onMessage、onClose 等回调中动态引入的文件（比如通过 require、include 或自动加载器加载的类），而启动脚本里直接 require_once 'config.php' 或写死的全局逻辑，reload 不会重新执行。
- 检查你的业务代码是否都封装在 Worker 实例的回调内，而不是放在
start.php顶层作用域 - 若用了
opcache.enable=1（默认开启），务必关闭或配置opcache.revalidate_freq=0，否则 PHP 缓存了旧字节码，reload 后仍运行旧逻辑 - Opcache 插件是常见“静默失效”元凶——卸载它或加
opcache_reset()到 reload 流程中（但注意：生产环境慎用）
升级前必须验证的兼容性断点
Workerman 5.0 移除了对 PHP 7.2 及更早版本的支持，且部分 API 行为有实质性变更。不是所有 4.x 项目都能无感升级。
-
Worker::$pidFile默认值从''改为null，若你依赖该路径做进程管理，需显式赋值 -
ConnectionInterface::send()对非字符串参数不再自动json_encode，传数组/对象前必须手动序列化 - 废弃了
Worker::setEventLoopClass()，改用Worker::$eventLoopClass静态属性设置，旧调用会报Deprecated警告 - PHP 版本至少为 7.3 —— 运行
php -v和php --ri opcache是升级前两步必做动作
自动化部署中 reload 失效？CI/CD 流程要分两类场景
CI/CD 里一句 php start.php reload 很容易“看起来成功，实则没更新”。关键看改的是什么。
- 只改业务逻辑（如
onMessage内部处理）→reload完全够用，子进程逐个替换，无连接中断 - 改了启动脚本本身（
start.php）、Worker 构造参数（如$worker->count）、或全局常量定义 → 必须走stop+start，否则新配置不会加载 - GitLab CI 中建议加健康检查：部署后请求一次
/health接口，并用ps aux | grep workerman确认进程启动时间戳已更新
升级后连接数突降或子进程异常退出？检查资源与信号接管
Workerman 5.0 加强了对子进程异常退出的响应，默认会立即重启失败进程。这在旧项目里可能暴露隐藏问题。
- 检查日志中是否有
Segmentation fault或Allowed memory size exhausted—— 5.0 对内存超限更敏感，建议在start.php开头加ini_set('memory_limit', '512M') - 若使用 systemd 管理服务，确保
KillMode=control-group未启用，否则reload发送的SIGUSR1会被 systemd 拦截，导致主进程收不到信号 - 某些云主机安全组或容器 runtime（如 containerd）会拦截
SIGUSR1，可在测试机用strace -e trace=signal php start.php reload验证信号是否真正送达主进程
Workerman 升级不是换版本号那么简单，reload 是否真 reload、进程是否真重启、opcache 是否真失效——这三个“真”字背后，藏着最多线上事故。别信日志里那句 “reload success”，得看进程 ID、看请求返回内容、看内存占用曲线。
