Laravel Octane 在 Swoole 或 RoadRunner 下常驻内存运行，Composer 依赖仅在启动时加载一次，代码变更或执行 composer install 后必须重启服务才能生效。部署时应先停止服务，再运行 composer install --optimize-autoloader --no-dev，必要时 dump-autoload，最后重启。禁止运行中执行 composer update，避免类错乱。开发环境可通过文件监听实现热重载，如 RoadRunner watcher 或 inotifywait 触发 octane:reload。需注意第三方包的全局状态和静态缓存可能导致请求间污染，优先选用支持 PSR 标准及 Swoole/RoadRunner 的库，并利用 Octane::flush 钩子清理静态数据。核心是遵循“变更即重启”原则，确保依赖一致性与应用稳定性。
在 Laravel Octane 中使用 Swoole 或 RoadRunner 作为底层服务时，虽然能显著提升应用性能，但与传统 FPM 模式不同，它会长期驻留内存运行。这种模式对 Composer 依赖的加载和管理带来了新的挑战。正确处理 Composer 依赖是确保应用稳定、避免内存泄漏和类加载问题的关键。
理解 Octane 的常驻内存机制
Laravel Octane 利用 Swoole 或 RoadRunner 将 Laravel 应用常驻内存中，避免每次请求都重新加载框架和服务。这意味着：
- Composer 的自动加载器（如 ClassLoader）只在启动时注册一次
- 所有已加载的类、静态属性、单例对象会持续存在于内存中
- 代码变更后不会自动生效，必须重启服务
因此，一旦依赖被加载，后续请求不会再重新解析 autoload 映射。如果在运行时动态修改了 vendor 目录或执行了 composer install，这些更改不会被识别，除非重启 Octane 服务。
部署时的 Composer 操作建议
在生产环境中更新依赖时，需遵循安全流程以避免服务异常：
- 先停止 Octane 服务：php artisan octane:stop
- 执行 composer install --optimize-autoloader --no-dev 确保 autoloader 高效且不含开发依赖
- 如有必要，运行 composer dump-autoload --optimize 强制刷新映射
- 重新启动服务：php artisan octane:start
切勿在 Octane 运行期间执行 composer update，这可能导致类版本错乱或文件被覆盖引发 fatal error。
热重载与开发环境配置
在本地开发时，可通过监听文件变化实现近似“热重载”：
- 使用 robo watch 或 inotifywait 监控 vendor/ 或 composer.json
- 检测到变更后自动触发 php artisan octane:reload
- RoadRunner 支持 .rr.yaml 中配置 watcher 插件实现自动重启
Swoole 用户可启用 track_request 或结合 hot-reload 工具辅助调试，但注意频繁重启会影响开发体验。
第三方包的兼容性注意事项
某些 Composer 包依赖全局状态或静态初始化逻辑，在常驻内存环境下可能出问题：
- 避免使用在全局作用域直接执行逻辑的包（如某些 SDK 在 .php 文件中写函数调用）
- 检查包是否使用静态缓存（如单例工厂、静态数组），防止跨请求数据污染
- 优先选择支持 PSR-15、PSR-17 或明确声明支持 Swoole/RoadRunner 的库
可借助 laravel/octane 提供的 Octane::flush* 钩子清理自定义静态状态。
基本上就这些。关键在于意识到 Octane 不是传统 PHP 生命周期，Composer 依赖一旦加载就固定，任何变更都需主动重启服务来生效。保持部署流程严谨，能有效避免大部分运行时问题。
