Composer autoload慢的本质是文件扫描和类映射低效：PSR-4未优化、dev依赖混入生产、classmap未预生成，导致每次类加载都需遍历松散映射表。
composer autoload 为什么慢？本质是文件扫描和类映射问题
Composer 加载慢，90% 情况不是网络或磁盘本身慢，而是 autoload.php 初始化时做了太多动态查找：比如 PSR-4 映射未优化、dev 依赖混入生产环境、classmap 没预生成。PHP 每次 require 类前都要查映射表，表越大、结构越松散，class_exists() 或自动加载触发就越卡。
实操建议：
- 确认是否在生产环境运行了
composer install --no-dev——vendor/composer/autoload_psr4.php里如果还残留着"phpunit/": ["vendor/phpunit/phpunit/src/"]这类路径，就会白扫一堆无关目录 - 检查
composer.json的autoload和autoload-dev是否严格分离；测试工具类（如Tests\）绝不能进 PSR-4 主映射 - 用
composer show --platform看是否意外装了大量平台扩展（如ext-xdebug），它们可能拖慢 autoloader 初始化（尤其 Xdebug 2.x）
什么时候该用 classmap？哪些目录适合加进去
classmap 是唯一能绕过目录遍历、直接查哈希表的 autoload 方式，但代价是构建时要全量扫描——所以它只适合「类少、变动少、无命名空间规范」的场景，比如旧项目里的 lib/utils.php、includes/ 这种散装函数库。
实操建议：
- 别把
src/或app/加进classmap—— 它们本就走 PSR-4，加进去反而让 composer 每次 dump 都重新扫描几千个文件 - 只对真正「无法用 PSR-4 描述」的路径启用：
"classmap": ["legacy/", "scripts/"]，且确保这些目录下没有同名 .php 文件重复定义类 - 执行
composer dump-autoload --optimize --classmap-authoritative后，vendor/composer/autoload_classmap.php会变成唯一权威来源，跳过所有 PSR 查找逻辑 —— 但前提是你的代码里没用class_exists('SomeClass', false)这种不触发加载的写法，否则会找不到
optimize-autoloader 和 --classmap-authoritative 的真实效果差异
--optimize-autoloader（或配置 "optimize-autoloader": true）只是把 PSR-4 映射转成更紧凑的数组结构，仍保留 fallback 行为；而 --classmap-authoritative 是彻底关掉 fallback，强制所有类必须出现在 classmap 里，快是真快，崩也是真崩。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
实操建议：
- 线上环境务必同时用两个参数：
composer install --no-dev --optimize-autoloader --classmap-authoritative - 本地开发禁用
--classmap-authoritative—— 因为 IDE 自动补全、热重载、甚至phpunit --filter都可能依赖动态类发现，一开就报Class "TestsFooTest" not found - CI 流程中，可以在 install 后加一步验证：
php -r "require 'vendor/autoload.php'; echo 'OK';"，防止 classmap 漏掉某些自动生成的类（比如 Doctrine Proxy）
vendor 目录位置和 opcache 对 autoload 性能的影响
autoload 速度不只是 Composer 的事。PHP 的 opcache 如果没缓存 vendor/composer/*.php 这些映射文件，每次请求都得重编译；而 vendor 放在 NFS 或容器卷上，stat() 系统调用延迟会直接放大 autoload 开销。
实操建议：
- 确认 opcache 启用了
opcache.enable_file_override=1且opcache.file_cache指向本地磁盘（非 /tmp），否则autoload_static.php这类高频读取文件不会被缓存 - 避免把
vendor/挂载到 Docker 的bind mount—— 即使只读，Linux 的 dentry cache 在跨文件系统时表现极差，autoload 查找耗时可能翻 3–5 倍 - 用
strace -e trace=stat,openat php -r "require 'vendor/autoload.php';"可直观看到实际打开了哪些 autoload 文件，有没有反复 stat 同一路径
最易被忽略的一点：autoload 性能瓶颈往往不在第一层 require，而在你代码里写了几十个 class_exists($name, true) 却没意识到它会真实触发 autoload —— 这种隐式加载在循环里出现三次，就比整个 composer autoloader 初始化还慢。
