webman热更新失效因reload仅重载动态加载代码，不重载composer自动加载类、配置文件及静态资源；monitor非平滑重启且后台模式失效；开发期应使用inotifywait/fswatch全进程重启。
Webman 热更新失效，不是 reload 命令没跑，而是它根本没打算重载你改的那部分代码。
php start.php reload 为什么总像没反应？
因为 reload 只触发 Worker 进程重新执行 onWorkerStart、onMessage 等回调里的逻辑，且仅限「动态加载」部分——比如在 onMessage 里用 require 引入的文件。但以下情况它完全不碰：
-
app/controller/Api.php这类被 Composer 自动加载的类，一旦加载进内存就固定了，reload不会重新实例化 -
config/bootstrap.php或onWorkerStart里一次性require 'config.php'的配置，改完 reload 后还是旧值 - 所有
class、const、define()、静态属性，这些符号已驻留内存，reload 不会重新解析 - OPcache 开启且
opcache.enable_cli=1时，CLI 模式下字节码不会自动失效，新 PHP 文件根本没被编译执行
Monitor 文件监听自动重启真的平滑吗？
不平滑。Webman 的 Monitor 进程（默认监听 app/ 和 config/）检测到 PHP 文件变更后，会向主进程发 SIGINT，等效于手动 Ctrl+C —— 它会立即终止所有 Worker，不等待当前 HTTP 请求完成。
这不是 reload 流程，没有 SIGUSR1 + 逐个替换 Worker 的机制。压测中约万分之一的请求会丢失，且数据库连接池、Redis 连接等无法优雅复位。
Webman 2.2.0
下载
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
更关键的是：Worker::$daemonize = true（后台运行）时，FileMonitor 默认不工作，因为后台模式跳过了文件轮询逻辑。
开发期怎么让修改 100% 生效？
别依赖 reload 或 Monitor，直接上全进程自动重启。Linux 下用 inotifywait，macOS 用 fswatch，核心三步：
- 监听
./app和./config目录下的文件变更（modify、move_self、create） - 每次变更前先执行
php start.php stop，再补一句pkill -f "start.php start"清残存子进程（stop经常漏杀） - 最后
php start.php start -d启动新进程
示例命令（Linux）：
while inotifywait -e modify,move_self,create ./app ./config; do php start.php stop; pkill -f "start.php start"; php start.php start -d; done
还有哪些容易被忽略的坑？
真正卡住热更新的，往往不是命令本身，而是环境或加载路径的隐性约束：
-
opcache.revalidate_freq设为 0 也没用，必须同时关掉opcache.enable_cli，否则 CLI 模式仍走缓存 - 中间件、定时任务、自定义进程如果在
onWorkerStart就完成了初始化（比如 DB 单例、Crontab 注册），reload 后它们不会重建，只会复用老实例 - Mac 系统上 Monitor 默认有延迟，有人直接替换了
app/process/Monitor.php为社区修复版才解决“改了十几次才生效”问题 - 检查
runtime/log/worker.log，看是否有new worker#0 started记录——别只信终端输出的Reload success
