ThinkPHP 本身不内置热更新，但通过 think-swoole 可实现文件监听+平滑 reload：修改 app/ 等目录下 PHP 文件后，inotify 检测变更并发送 SIGUSR1 信号触发 Swoole $server->reload() 仅重启 Worker 进程，不中断服务。
ThinkPHP 本身不内置热更新（Hot Reload）能力，但通过生态扩展（如 think-swoole）或搭配 Swoole 运行时，可实现开发阶段的「代码修改后自动重载 Worker 进程」效果——这常被开发者称为“热更新”，实际是文件监听 + 平滑 reload，不是 PHP 层面的字节码热替换。
think-swoole 的 hot_update 是怎么工作的？
它依赖 Swoole 的 $server->reload() 接口，只重启 Worker 进程，不重启 Master，因此 HTTP 服务几乎不中断。
- 启用前提：APP_DEBUG = true（即
.env中设APP_DEBUG=true），且未显式关闭 - 默认监听目录：
app/、config/、route/、provider/等（具体见config/swoole.php的hot_update.watch_dirs） - 修改任意匹配的
.php文件后，watcher 检测到变更 → 向 Swoole 主进程发SIGUSR1→ 触发reload() - 注意：
public/下的静态资源、.env或runtime/不在默认监听范围内
inotifywait -m -r -e modify,create,delete ./app --format '%w%f' | while read file; do [[ $file == *.php ]] && kill -USR1 $(cat runtime/swoole.pid) 2>/dev/null done
为什么改了代码却没 reload？常见卡点
不是所有修改都会触发重载，尤其容易忽略以下几点：
-
hot_update.enable在config/swoole.php中被设为false（即使 APP_DEBUG=true 也会被覆盖） - 监听路径没包含你修改的文件位置，比如你在
extend/下写了新服务类，但该目录不在watch_dirs列表里 - 使用了
opcache.enable=1且未配置opcache.validate_timestamps=1，导致 PHP 缓存旧字节码，reload 后仍执行旧逻辑 - Swoole 进程未以守护模式运行（
daemonize => false），某些终端环境下信号无法正确送达 -
runtime/swoole.pid文件权限不对或路径错误，导致脚本找不到主进程 PID
PHP-FPM 环境下能用 think-swoole 热更新吗？
不能。这是根本性不兼容：
立即学习“PHP免费学习笔记（深入）”；
-
think-swoole是为 Swoole Server 设计的，依赖Swoole/Http/Server实例和进程模型 - PHP-FPM 是 CGI 模式，每个请求 fork 新进程，没有长期运行的 Master/Worker 架构，无法
reload() - 如果你用的是 Nginx + PHP-FPM，所谓“热更新”只能靠：
- 软链接切换发布目录（
/www/site → /www/releases/20260113） - 平滑重启 PHP-FPM（
sudo systemctl reload php-fpm） - 配合 opcache 配置（
opcache.revalidate_freq=0）让脚本每次检查时间戳
- 软链接切换发布目录（
上线环境要不要开 hot_update？
不要。生产环境应严格禁用：
- 文件监听会持续占用 inotify 句柄，高并发下易耗尽（Linux 默认 8192 个，Swoole 多 worker 会放大消耗）
- 每次文件变动都触发 reload，若部署中存在临时文件（如 .swp、.tmp）、编辑器备份，可能引发误 reload
- 更关键的是：未经测试的代码直接上线 = 生产事故。热更新掩盖了“构建 → 测试 → 发布”的必要流程
真正需要的不是“自动 reload”，而是「可控、可回滚、可观测」的发布机制——比如用 Docker 镜像 + 标签版本 + Kubernetes rolling update。
Swoole 的 reload 很快，但快不等于安全；开发图省事可以开，上线前务必关掉 hot_update.enable。