hyperf 中不推荐使用 --optimize-autoloader，因其生成的 autoload_classmap.php 与 hyperf 的 psr-4 + autoload_static.php 机制冲突，反而拖慢冷启动；应关闭 classmap、启用 autoload_static.php 并配合 opcache 预热。
Hyperf 项目里加 --optimize-autoloader 基本没用，甚至拖慢冷启动——它生成的全量 autoload_classmap.php 和 Hyperf 的运行机制冲突，真正该做的是关掉 classmap、启用 autoload_static.php + opcache 预热。
为什么 composer install --optimize-autoloader 在 Hyperf 里不推荐
Hyperf 默认使用 PSR-4 + autoload_static.php（Composer 2+ 自动产出），这个文件是编译态静态数组，体积小、加载快、opcache 友好；而 --optimize-autoloader 强制生成巨量 autoload_classmap.php，每次请求都要完整 require 进内存，但 Hyperf 实际只用到其中不到 3% 的类（比如仅 Controller/Service 层），其余全是框架内部测试类、注解解析器、废弃组件路径——白占内存还触发 opcache 淘汰。
- Hyperf 的
composer.json中"autoload"块基本全是标准 PSR-4，没配"classmap"，-o实际不会新增任何有效映射 - Hyperf 启动时会动态扫描注解（如
@Controller）、AOP 切面、配置驱动类，这些依赖实时文件发现，--classmap-authoritative会直接禁用扫描，导致服务注册失败 - Hyperf 的
bin/hyperf.php启动入口绕过部分 Composer autoloader 路径，-o生成的 classmap 不会被完全加载
Hyperf 生产部署必须做的三件事
不是加参数，而是删配置、启缓存、预热。
- 删掉
composer.json里所有无用 autoload 条目：比如"docs/": ["docs/"]、"tests/": ["tests/"]、"example/": ["example/"]—— 这些会让 Composer 扫描数百个非运行时文件，膨胀autoload_static.php - 确认 PHP 配置启用 opcache 并关闭校验：
opcache.enable=1、opcache.validate_timestamps=0、opcache.memory_consumption=256M（Hyperf 类多，128M 容易挤出） - 容器构建阶段执行预热：
php -d opcache.enable=1 vendor/hyperf/engine/bin/hyperf.php start --daemon && sleep 3 && pkill -f "hyperf.php start"，让 opcache 缓存autoload_static.php和核心框架类
composer dump-autoload --apcu 对 Hyperf 是负优化
APCu 缓存的是类名 → 文件路径的映射结果，但 Hyperf 大量使用反射读取注解、动态代理、协程上下文绑定，这些行为本身不触发传统类加载，APCu 缓存命中率极低；更关键的是，Hyperf 默认不启用 APCu 扩展（Swoole 环境下 APCu 和 opcache 共存有已知冲突），强行加 --apcu-autoloader 会导致 Class not found 错误且无明确提示。
- Hyperf 官方 Dockerfile 中从不启用 APCu，推荐用 opcache +
preload替代 - 若真要用 APCu，必须在
php.ini显式开启apc.enabled=1且apc.stat=0，否则每次require都会 stat 文件，废掉所有优化 -
composer dump-autoload --apcu不影响已安装包，只重写本地 autoload 文件；Hyperf 的核心类在vendor/hyperf/*下，这些包的 autoload 是由它们自己的composer.json控制的，你本地跑 dump 不会改它们
唯一需要加 --optimize-autoloader 的场景
只有当你在 Hyperf 项目里手动引入了大量非 PSR-4 结构的遗留代码（比如散落在 app/Legacy/ 下的无命名空间类、.inc 文件、或 files 类型加载的全局函数），并且这些代码被高频调用时，才值得在 composer.json 的 "autoload" 里显式声明 "classmap": ["app/Legacy/"]，再执行 composer dump-autoload -a（-a 比 -o 更彻底，强制重扫）。
- 检查是否生效：打开
vendor/composer/autoload_classmap.php，搜索你的遗留类名，确认路径正确 - 注意别把
app/整体塞进 classmap——Hyperf 的app/下是标准 PSR-4 结构，这么干会让 classmap 膨胀 10 倍，得不偿失 - Hyperf 的
config/autoload/dependencies.php中若用了make绑定字符串类名（而非 FQCN），classmap 必须覆盖这些类，否则 DI 容器无法解析
Hyperf 类加载性能瓶颈从来不在 Composer 参数上，而在 opcache 是否真正热起来、autoload_static.php 是否被污染、以及你有没有把测试/文档路径当生产代码一起加载。别碰 -o，先看 opcache_get_status() 输出里 preload 和 memory_usage 是否健康。
