Webman 的 reload 命令不是“全量热更新”，它只对特定路径、特定加载方式的代码生效；改了控制器或模型却没反应，大概率是加载机制没对上，而不是命令没跑。
哪些代码 reload 后能生效？
Webman 的 php start.php reload 本质是向 Worker 进程发送 SIGUSR1，触发 Worker 逐个退出并重启——但仅限于「运行时动态加载」的 PHP 文件。这类文件必须满足两个条件：在 onMessage、onRequest 或类似回调中通过 require/include 显式引入，且不能被 Composer 自动加载器提前注册。
-
app/controller/Api.php这类由路由自动加载的类 —— reload 无效（Composer autoloader 已缓存类定义） -
app/logic/OrderSync.php被onWorkerStart一次性require—— reload 无效（初始化阶段就载入内存） -
runtime/tmp/handler.php在onRequest中require __DIR__ . '/tmp/handler.php'—— reload 有效（每次请求都重新读取）
为什么禁用 OPcache 才能看到 reload 效果？
CLI 模式下若开启 opcache.enable_cli=1（常见于 Docker 镜像或本地开发环境），PHP 会把 require 的文件也编译进 OPcache。即使 reload 触发了新 Worker 启动，只要文件路径没变，OPcache 就直接返回旧字节码。
- 临时验证：执行
php -d opcache.enable_cli=0 start.php reload - 长期方案：在
php.ini中设opcache.revalidate_freq=0（开发环境），或彻底关闭opcache.enable_cli - 注意：
clearstatcache()对 OPcache 无效，别白费力气
Monitor 进程自动 reload 是真平滑吗？
Webman 的 Monitor 进程（默认监听 app/ 和 config/ 目录）检测到变更时，调用的是 posix_kill($pid, SIGINT)，等效于你手动按 Ctrl+C。它不走 SIGUSR1 流程，而是强制终止所有 Worker：
立即学习“PHP免费学习笔记（深入）”；
- 当前正在处理的 HTTP 请求可能被中断（压测中约 0.01% 失败率）
- 数据库连接、Redis 订阅等未优雅关闭，可能留下脏状态
- 它不会等待 Worker 完成任务，和
reload的语义完全不同 - 仅在调试模式（启动不加
-d）下启用，生产环境默认关闭
真正需要 restart 的配置有哪些？
Webman 明确不支持 reload 的配置项，改了就必须 php start.php restart：
-
config/server.php（端口、SSL、进程数等） -
config/process.php（自定义进程定义，如定时任务入口） - 新增或删除
config/bootstrap.php中的预加载逻辑 - 修改
composer.json并执行composer dump-autoload后，类映射已变更
这些改动直接影响主进程行为或 Worker 初始化流程，reload 无法重建上下文。最容易忽略的是：哪怕只是给 config/process.php 里加了一行注释，也得 restart。
