php start.php reload 只重载 Worker 进程内动态 require 的文件，如 onMessage 中引入的业务逻辑；不重载 Composer 自动加载类、配置文件、const/define/静态属性、OPcache 缓存代码等已驻留内存的内容。
php start.php reload 能做到不中断业务，但前提是代码加载方式、OPcache 和进程生命周期都符合它的作用边界——它只重载 Worker 进程内动态 require 的文件，其余一概不管。
reload 命令到底重载什么？
Webman 的 php start.php reload 本质是向主进程发 SIGUSR1，触发 Worker 进程逐个退出并重启。但它只对以下内容生效：
- 在
onMessage、onRequest等回调里用require或include动态引入的 PHP 文件（比如路由分发后加载的 controller） - Worker 进程运行时重新解析的逻辑（前提是没被 OPcache 缓存或类定义已加载）
它完全不触碰这些：
Webman 2.2.0
下载
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
-
onWorkerStart中一次性require的配置或类 -
const、define()、静态属性、类定义等已加载进内存的符号 - OPcache 缓存的字节码（尤其当
opcache.enable_cli=1时） - 通过 Composer autoloader 加载的控制器（如
app/controller/Api.php），因为 autoload 是全局注册、一次加载终身有效
为什么改了代码 reload 后接口还是旧结果？
典型现象：你改了 app/controller/Api.php，执行 php start.php reload，curl 却仍返回旧值。这不是命令失败，而是加载路径根本没走 reload 覆盖范围。
- 确认控制器是否被动态
require：Webman 默认走 Composer autoload，而 autoload 类不会因 reload 重新加载 - 临时验证：加
-d opcache.enable_cli=0再 reload，比如php -d opcache.enable_cli=0 start.php reload；若此时生效，说明是 OPcache 搞的鬼 - 检查有没有在
config/bootstrap.php或webman\support\Bootstrap中提前require了业务类——这些都在 Worker 初始化阶段完成，reload 不会重跑 - 别只信终端输出的 “Reload success”：查
php start.php status输出的 Worker PID 是否变化，或翻runtime/log/worker.log看是否有新worker#0 started记录
真正平滑的前提：避免 reload 失效的关键点
想让 reload 生效，就得把变更控制在它的“作用域”里：
- 把需要热更的逻辑抽出来，放在单独文件中，并在
onMessage或onRequest回调里用require动态加载（注意路径和变量作用域） - 禁用 CLI 模式下的 OPcache：
opcache.enable_cli=0，或设opcache.revalidate_freq=0（开发环境可接受，生产慎用） - 定时任务更新必须 reload：改了
app/process/Task.php后，php start.php reload才能刷新 Crontab 实例；restart会中断任务 - WebSocket 或 TCP 自定义进程也受 reload 影响，但前提是它们的业务逻辑同样走动态加载，而非在
onWorkerStart里写死
最常被忽略的是：reload 不是“重跑整个 Worker”，它只是让旧进程做完手头活就退休，新进程带着新代码上线——所以长时间阻塞操作（如未设 timeout 的 curl）、没捕获的异常、或共享内存状态丢失，都会让“平滑”变成假象。
