在常驻内存php应用中，composer自动加载需在服务启动时一次性引入，避免重复定义或旧代码残留。
在基于 Swoole 或 RoadRunner 的常驻内存 PHP 应用中，使用 Composer 时需要特别注意自动加载机制和类的生命周期管理。由于这类应用是常驻内存的，传统的每次请求都重新加载类和依赖的方式不再适用，稍有不慎就会导致类未找到、重复定义或旧代码残留等问题。
理解常驻内存对 Composer autoloader 的影响
Composer 的自动加载机制（特别是 classmap 和 psr-4）在 CLI 或 FPM 环境下每次请求都会重新初始化。但在 Swoole 或 RoadRunner 中，主进程只启动一次，Composer autoloader 也只会注册一次。如果在运行时动态添加命名空间或修改文件结构，不会被自动感知。
常见问题包括：
- 热更新代码后，旧类仍被使用
- 动态 require 文件导致类重复定义
- 新增类无法被自动加载
正确引入 Composer autoloader
确保在服务启动的最开始阶段就加载 Composer autoloader，并且只加载一次。
错误做法：在每个请求中包含 vendor/autoload.php，这可能导致重复引入或内存泄漏。
在入口文件（如 server.php）中一次性引入：
<?php
require __DIR__ . '/vendor/autoload.php';
// 启动 Swoole 服务或 RoadRunner Worker
$server = new Swoole\Http\Server("127.0.0.1", 9501);
$server->on('request', function ($req, $resp) {
// 业务逻辑，不要再次 require autoload
});
$server->start();
避免运行时修改 autoloader 映射
不要在请求处理过程中调用 ClassLoader::addPsr4() 或 addClassMap()。这些操作会污染全局状态，且在多协程环境下可能引发冲突。
如果你需要动态加载模块，建议：
- 在启动阶段预加载所有可能用到的类
- 使用依赖注入容器统一管理实例化
- 通过配置驱动扩展机制，而非运行时注册命名空间
热重载与开发调试建议
在开发环境中，可以结合文件监控工具实现平滑重启：
- Swoole：使用
--enable-reload和inotify监控文件变化，触发工作进程重启 - RoadRunner：配合
rr的 watch 模式自动重载 worker
注意：重载会重建整个进程，autoloader 也会重新初始化，因此能正确加载新代码。
生产环境不建议开启热重载，应通过发布流程重启服务以保证一致性。
静态分析与优化 autoloader 性能
常驻内存应用对性能敏感，建议优化 Composer autoloader：
- 使用
composer dump-autoload --optimize生成更高效的 classmap - 启用 APCu 缓存（如适用），减少文件系统查找
- 避免使用 files 类型的 autoload（会每次执行脚本）
基本上就这些。关键是把 Composer autoloader 当作启动时的一次性基础设施，而不是每次请求都依赖的组件。只要在进程启动时正确加载，后续请求就能稳定访问所有类。
