composer 无法实现框架常驻内存，真正常驻需 swoole/roadrunner；classmap 仅加速类加载但不改变 fpm 进程生命周期；opcache preload 才是关键，须配合显式 require 和 opcache.enable_cli=1。
Composer 本身不支持“预加载实现框架常驻内存”——这是常见误解。真正的常驻内存依赖 Swoole 或 RoadRunner 等运行时，而 Composer 的 autoload_files 或 classmap 预加载仅能减少类加载开销，无法让 PHP 进程长期存活。
为什么 composer dump-autoload --optimize 不能替代 Swoole
该命令生成 vendor/composer/autoload_classmap.php，把所有类路径映射进一个数组，跳过 PSR-4 的文件系统查找。但它仍运行在传统 FPM 模式下：每次请求都新建进程、加载全部类、执行完即销毁。内存不会“常驻”，只是“加载更快”。
- 实际效果：类加载耗时从 ~0.5ms 降到 ~0.05ms，但整体请求生命周期未变
- 误用风险：过度依赖 classmap 会导致
vendor/变更后缓存失效，需手动重跑 dump 命令 - 不解决根本瓶颈：数据库连接、配置解析、路由匹配等仍重复执行
composer config autoloader-suffix 在协程环境中的陷阱
某些项目试图用自定义 autoloader suffix（如 MyAppAutoloader）配合 Swoole 实现“隔离加载”，但极易引发协程间类定义冲突。Swoole 的协程共享同一进程的 PHP 符号表，若不同请求通过不同 autoloader 加载同名类，会触发 Fatal error: Cannot redeclare class。
- 正确做法：禁用动态注册，全部走 Composer 自动生成的
autoload_static.php - 必须确保所有
require语句在Swoole\Server::start()前完成，否则协程中首次new类时可能触发 autoload 竞态 - 避免在
onRequest回调里require_once任何框架文件——这会破坏常驻前提
真正起效的预加载组合：OPcache + Swoole + Composer classmap
三者协同才能逼近“一次加载、永久复用”的效果。其中 OPcache 是关键粘合剂：它把已解析的 PHP 文件（含 classmap）字节码固化在共享内存，Swoole 进程复用这些 opcode，不再重复编译。
- 必须启用
opcache.enable_cli=1（Swoole 运行在 CLI 模式） - 设置
opcache.preload指向一个 preload.php 文件，里面显式require所有核心类文件（非自动扫描） - Composer classmap 仅作为兜底：当 preload 失败或类未被预载时，仍能快速定位
- 验证是否生效：
opcache_get_status()['preload_statistics']['memory_consumption']应大于 0
最容易被忽略的是 preload 文件的编写方式——它不能包含任何运行时逻辑（如 new 实例、function_exists 判断），只能做纯粹的 require。一旦写错，OPcache 会静默跳过整个 preload，而你可能还在怀疑 Swoole 配置。
