Composer 在 Swoole 常驻内存场景下必须改造 autoload 机制：启动前重置 PSR-4 映射、禁止运行时动态 require、避免 Worker 中执行 composer 命令、将 files 脚本移至 onWorkerStart 加载，并确保所有 autoloader 生成在 start() 前完成。
Composer 本身不感知 Swoole 的常驻内存特性，直接照搬传统 Web 项目用法会导致内存泄漏、类重复加载、配置失效等问题。关键不是“能不能用”，而是“哪些环节必须改”。
autoload 配置不能依赖默认 PSR-4 自动重载
Swoole 进程常驻后，composer autoload 生成的 vendor/autoload.php 只执行一次，后续 require 或 use 不会重新解析路径。若你在热更新时修改了命名空间或文件位置，旧映射仍留在 $loader->prefixesPsr4 中，导致类找不到或加载错版本。
- 启动前显式调用
$loader->setPsr4()重置映射（适合开发期配合 inotify） - 避免在运行时动态
require新类文件；统一走 Composer 自动加载，且确保所有类文件在启动前已存在 - 检查
vendor/composer/autoload_psr4.php是否含冗余/冲突条目（比如多个包声明同一命名空间）
不要在 Worker 进程中执行 composer install 或 dump-autoload
Worker 进程无权写入 vendor/，且并发执行会破坏 autoload 文件一致性。错误现象包括：Class not found、Cannot redeclare class、include(): Failed opening 'xxx.php'。
- 所有依赖安装和 autoloader 生成必须在 Master 进程启动前完成，即在
swoole_server->start()之前 - CI/CD 构建阶段就跑
composer install --no-dev --optimize-autoloader，生成静态映射表 - 如需热更类，用
opcache_reset()+ 文件级 reload（非 Composer 级），并确保类定义无全局副作用
composer.json 中禁用自动加载的插件类要特别小心
某些包（如 Laravel Octane 兼容层、Swoole 扩展桥接器）会在 autoload 的 files 段注册全局函数或 register_shutdown_function。这些代码在 Worker 启动时执行一次，但 Swoole 多进程下每个 Worker 都会执行——可能造成重复注册、资源抢占或信号 handler 冲突。
- 把
"files"数组中的脚本移到 Swoole 的onWorkerStart回调中按需加载 - 检查第三方包是否使用
classmap加载方式：它比 PSR-4 更快，且无命名空间解析开销，适合高频调用场景 - 用
composer show --profile查看 autoload 加载耗时，确认瓶颈是否在文件 I/O 而非逻辑
最易被忽略的是：Swoole 的 reload_async 或 max_request 触发的 Worker 重启，并不会重建 Composer autoloader 实例——它仍是启动那一刻的状态。这意味着任何依赖运行时修改的 autoload 行为（比如动态添加命名空间）都不可靠。
