RoadRunner热重载默认不生效，因其为常驻进程且不监听文件变化；需通过rr serve --watch（配合spiral/roadrunner-cli）或inotifywait等工具手动触发reload。
为什么 roadrunner 的热重载默认不生效
因为 RoadRunner 本身是常驻进程，PHP 文件修改后不会自动 reload —— 它不像 Laravel Valet 或内置服务器那样监听文件变化。你改了代码却看到旧结果，不是配置错，是根本没启用热加载机制。
真正起作用的是 rr 命令搭配 watch 插件，或靠第三方工具（如 inotifywait）触发 rr reload。Spiral 框架自带的 spiral/roadrunner-cli 包提供了开箱即用的 watch 能力，但需显式启用。
- 确认已安装
spiral/roadrunner-cli：运行composer require spiral/roadrunner-cli --dev - 确保
.rr.yaml中启用了http: {pool: {num_workers: 4}}等基础配置，否则rr serve启动失败 - Linux/macOS 下推荐用
rr serve --watch；Windows 用户需额外装fsnotify兼容层，否则--watch会静默失效
rr serve --watch 实际监听哪些文件
它不是全量扫描项目目录，而是按预设规则过滤：只响应 app/、config/、src/、routes/ 下的 PHP、YAML、ENV 文件变更。你改了 public/index.php 或 vendor/ 里的东西，它不会 reload。
这个行为由 spiral/roadrunner-cli 内部的 Watcher 类控制，无法通过命令行参数扩展路径，必须改源码或换方案。
立即学习“PHP免费学习笔记（深入）”；
- 想监听
templates/？得自己写脚本调用inotifywait -m -e modify,create ./templates | while read; do rr reload; done -
--watch不监听 .env 变更，环境变量更新需手动rr reload或重启进程 - 修改
.rr.yaml本身不会触发 reload，必须手动rr reload才生效
开发时 rr reload 和 rr reset 的区别
rr reload 是软重载：保持主进程运行，仅重启 worker 进程，耗时约 100–300ms，适合日常编码迭代；rr reset 是硬重启：杀掉整个 RoadRunner 进程再拉起，含 TCP 监听重建，耗时明显更长，且会导致短时请求 502。
多数情况用 rr reload 就够了，但遇到内存泄漏、协程状态污染、或 Swoole 扩展级缓存残留时，rr reset 才能彻底清理上下文。
- IDE 自动保存触发 reload？可配 File Watcher 执行
rr reload，但避免高频触发（如每秒多次），否则 worker 频繁启停影响稳定性 -
rr reload失败时常见错误：rpc error: code = Unavailable desc = connection closed，说明主进程已挂，此时必须rr reset - 使用
spiral/frameworkv3.0+ 时，rr reload会自动清空spiral/cache组件的 APCu 缓存，老版本需手动apcu_clear_cache()
PHP 8.2+ + RoadRunner 2023.x 的兼容性陷阱
RoadRunner 2023.3 开始要求 PHP >= 8.1，但部分扩展（如 spiral/jobs 的 SQS 驱动）在 PHP 8.2 下会因 ReturnTypeWillChange 报错，这不是你代码的问题，是依赖包未适配。
更隐蔽的是 opcache 配置：RoadRunner 强依赖 opcache 启用，但默认 opcache.enable_cli=0，导致 CLI 模式下 rr 命令本身无法利用 opcode 缓存，启动变慢且易出错。
- 必须在
php.ini中设opcache.enable_cli=1，否则rr serve可能卡在 “Loading config…” - 若用 Docker，注意基础镜像是否含
opcache.so，Alpine 的php82-opcache包名和 Debian 不同 -
rr二进制本身是 Go 写的，与 PHP 版本无关，但rr调用的 PHP-FPM bridge 模块受 PHP ABI 影响，混用不同 minor 版本（如 PHP 8.2.1 和 8.2.8）可能引发段错误
