PHP Webman环境下的热更新配置_开发调试无需重启服务【技巧】

顺亿

2026-09-21 • 👁 0人浏览过

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 8.5.5 PHP 8.5.5 是 PHP 8.5 分支的维护更新版本。该版本延续了“小步快跑”的迭代逻辑，通过深度错误修复、底层性能微调以及安全加固，旨在为开发者提供一个更健壮、更高效的运行环境。该版本严格遵守语义化版本规范，不包含破坏性变更。下载立即学习 “ 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。

相关文章