workerman 5.2.3 的 reload 需关闭或重置 opcache、业务逻辑须置于 onmessage/onconnect 回调中、通过 pid 变化和日志时间戳验证生效、配置变更必须用 restart 而非 reload。
Workerman 5.2.3 的 reload 操作本身机制没变，但版本升级后对环境和代码结构更敏感。想让它真正生效、不中断连接、逻辑也更新到位，得盯住这几个关键点。
OPcache 必须关或重置
PHP CLI 模式下，opcache.enable_cli=1 是 reload 失效最常见原因——旧字节码锁死，新文件根本没加载。5.2.3 默认可能仍开启该配置。
- 推荐做法：在
onWorkerStart回调里加一行opcache_reset();，确保每次子进程启动时清空缓存 - 替代方案：修改
php.ini，设opcache.enable_cli=0，然后重启 PHP CLI 环境（不是 reload） - 别依赖
opcache_invalidate()单个文件——它在 CLI 下不一定可靠
业务逻辑必须“活”在 onMessage/onConnect 里
reload 只会重建 Worker 子进程，不会重建主进程，也不会重新执行 new Worker() 后的初始化代码。
- ✅ 安全写法：所有路由分发、服务调用、配置读取，都放在
$worker->onMessage或onConnect回调内部，用require/include或自动加载动态引入 - ❌ 危险写法：在 Worker 实例化后直接 new 对象、赋值常量、调用
class_exists()预加载类——这些 reload 不会刷新 - 特别注意：静态变量（
static $cache = []）在单个子进程内跨 reload 持久存在，容易导致状态错乱
确认 reload 真成功，不能只看终端提示
Reload success 这句话只是主进程收到了信号，不代表子进程已更新或代码已生效。
- 查 PID 变化：运行
php start.php status，对比 reload 前后各 Worker 进程的 PID，有变化才说明新进程已拉起 - 看日志时间戳：检查
workerman.log或 stdout 日志，搜索worker#0 started这类记录，确认是否带最新时间 - 验证逻辑：用简单测试数据触发
onMessage，输出一句带版本号或时间戳的调试信息，确认执行的是新代码
别混淆 reload 和 restart
5.2.3 对配置变更更严格，误用命令会导致“看似 reload 了，实际没加载新配置”。
- 改了
$worker->count、监听地址、SSL 参数、或start.php自身内容 → 必须用php start.php restart - 只改了消息处理逻辑、中间件、数据库查询语句等运行时代码 → 用
php start.php reload即可 -
php start.php reload -d是无效命令：-d 只在 start 阶段解析，reload 不识别任何额外参数
