vendor/autoload.php加载慢主因是未启用OPcache或配置错误、PSR-4映射不规范导致反复stat()，以及误用--optimize-autoloader生成低效classmap；应验证OPcache状态、检查命名空间末尾反斜杠、确保--no-dev隔离autoload-dev。
vendor/autoload.php 加载慢，90% 不是 Composer 本身的问题，而是 PHP 每次请求都重新解析 PSR-4 映射、反复 stat() 文件，且没开 OPcache 或配置不匹配。
怎么确认是 autoload.php 加载阶段真慢
别猜，用 php -d opcache.enable=0 -d memory_limit=-1 -d max_execution_time=0 -t 直接测加载开销：
- 运行
php -d opcache.enable=0 vendor/autoload.php，看是否卡顿或报错——若卡，说明 classmap 没生成或路径扫描失控 - 对比加
-d opcache.enable=1后的耗时：差值超过 50ms 就说明 OPcache 没生效或没预热 - 检查
opcache_get_status()['scripts']输出里有没有vendor/autoload.php和vendor/composer/autoload_static.php——没有就等于白配
autoload_classmap.php 为空或体积异常小
这是最常被忽略的“假优化”信号：你跑了 composer dump-autoload -o，但生成的 vendor/composer/autoload_classmap.php 只有几行或根本为空。
- 常见原因：
"App": "src/"缺少末尾反斜杠 → 应为"App\": "src/"（注意双反斜杠转义） - PSR-4 命名空间末尾没加
\，Composer 会跳过整个映射段，不报错也不提示 - 路径中混入了
tests/、examples/或docs/，导致扫描失败后静默降级为无映射 - 运行
composer dump-autoload --profile -v，看输出里有没有Scanning /path/to/tests这类行——有就说明 autoload 配置漏加了-dev隔离
为什么开了 --optimize-autoloader 还是慢
在 PHP 7.4+ 和 Composer 2.x 环境下，-o 不再等价于“更快”，它可能让冷启动更糟。
-
autoload_classmap.php是一个全量 PHP 数组，每次 require 都要反序列化数 MB 数据，而单次请求通常只用其中不到 5% 的类 - Composer 2 默认生成
autoload_static.php，它是编译后的静态结构，OPcache 下加载快得多；-o实际覆盖了这个更优路径 -
--classmap-authoritative只有在满足全部条件时才安全：无files加载、无非标 classmap 路径、autoload-dev完全隔离、命名空间与目录严格大小写一致 - 开发中误加
--classmap-authoritative，新增类不会被识别，错误信息却是Class not found，不提示 fallback 失败原因
OPcache 配置不全导致优化失效
即使生成了 classmap 或 static 文件，OPcache 关键参数没设对，PHP 仍会每秒重读、重解析。
-
opcache.enable=1和opcache.enable_cli=1必须同时开启：后者控制composer dump-autoload生成的文件能否进缓存 -
opcache.revalidate_freq=0是生产必需项；设为非零值（如 2）会导致每 2 秒检查一次文件时间戳，废掉所有优化 -
opcache.max_accelerated_files至少设为 20000（默认 2000），否则大量类文件会频繁踢出缓存 - 验证方式：改一行
vendor/composer/autoload_static.php，再执行php -d opcache.enable=1 vendor/autoload.php——若没报错，说明 OPcache 没禁用校验或没命中
真正卡点不在“有没有跑 -o”，而在“OPcache 是否信任并缓存了 autoload_static.php”、“命名空间声明是否带结尾反斜杠”、“autoload-dev 是否被 --no-dev 彻底隔离”。这三个地方任一出错，所有优化都会静默退化。
