国内镜像源在octane下更关键，因其启动时一次性加载全部类和autoloader映射，若因网络卡顿导致包下载失败或超时，composer install会中断致使octane无法启动；且部分旧镜像对swoole/roadrunner扩展包同步滞后，可能拉不到最新兼容版本。
Octane 环境下不能靠“装完就跑”来管理依赖——镜像配置必须在启动前生效，composer install 必须配合 --optimize-autoloader --no-dev，且任何 composer update 都得停服务再操作。
为什么国内镜像源在 Octane 下更关键？
Octane 启动时一次性加载全部类和 autoloader 映射，如果因网络卡顿导致某个包下载失败或超时，composer install 会中断，而 Octane 进程根本起不来；更糟的是，部分镜像（如旧版腾讯云源）对 Swoole/RoadRunner 相关扩展包同步滞后，可能拉不到最新 laravel/octane 或 swooletw/laravel-swoole 的兼容版本。
- 推荐用阿里云镜像：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 若项目用私有包，需额外配
repositories并确保auth.json在部署用户 HOME 目录下（Octane 进程读取的是运行用户的配置，不是 root） - 执行
composer diagnose检查源是否可用，避免启动时静默失败
生产部署时 composer install 的强制参数组合
Octane 不是 FPM，没有每次请求重载 autoload 的机会。不加优化参数，类加载会慢、内存占用高，还容易触发 Swoole 的内存限制告警。
- 必须用：
composer install --optimize-autoloader --no-dev -
--optimize-autoloader生成 class-map，跳过 PSR-4 文件扫描，对常驻进程至关重要 -
--no-dev不只是省空间——dev 包里的命令行工具（如 phpunit）可能注册全局事件监听器，在多请求间残留状态 - CI/CD 中严禁只写
composer install，漏掉参数会导致线上性能陡降
什么时候能 reload，什么时候必须 stop/start？
文件变更 ≠ 代码生效。Octane 的 reload 本质是杀掉 worker 进程并拉起新实例，但前提是 autoloader 和 vendor 内容没变；一旦 vendor 被 composer install 修改过，reload 无效，只会复用旧的类引用。
- 仅修改 PHP 文件（如
app/Http/Controllers）：可php artisan octane:reload - 执行过
composer install或dump-autoload：必须php artisan octane:stop && php artisan octane:start - 误在运行中执行
composer update：立刻停服务，删掉vendor和composer.lock，重新install，否则大概率出现Class not found或方法不存在
最易被忽略的一点：第三方包里带的 files 类型自动加载（比如 helpers.php），哪怕只改了一行，也得 composer dump-autoload -o + 重启 Octane——因为这些函数不是按命名空间加载的，而是启动时直接 require_once，缓存在内存里出不来。
