Composer install启动慢的根本原因是autoload.php加载时反复扫描目录，应移除dev依赖的autoload规则、启用--optimize-autoloader和--classmap-authoritative、强制--no-dev，并禁用Xdebug；APCu仅作补充，不能替代classmap优化。
Composer 本身没有“负载调度”概念，所谓“负载调度配置”是误用术语；实际要解决的，是自动加载性能瓶颈、依赖安装卡顿、内存溢出这三类问题。
为什么 composer install 启动慢到怀疑人生
根本原因不是网络或磁盘 IO，而是 vendor/autoload.php 加载时反复扫描目录、构建映射表。特别是当 autoload 和 autoload-dev 混用，或大量开发依赖（如 phpunit/phpunit）被纳入主 autoload map 时，ClassLoader::findFile() 会触发数十甚至上百次 file_exists() 调用。
典型现象：
- CLI 命令（如
php artisan tinker）冷启动耗时 >100ms -
strace -e trace=openat,stat php -r "require 'vendor/autoload.php';"显示大量对vendor/xxx/src/下非核心路径的访问 - 部署日志里反复出现
Loading composer repositories with package information卡住数秒
这不是配置“调度策略”，而是必须切断冗余扫描路径：
- 把测试、分析、生成类等工具依赖全部移入
autoload-dev，而非写在顶层autoload - 生产部署务必加
--no-dev，否则require-dev的 autoload 规则仍会被解析 - 确认
composer.json中没有把vendor/子目录错误地写进autoload.classmap
dump-autoload --optimize 和 --classmap-authoritative 怎么选
两者都生成 vendor/composer/autoload_classmap.php，但行为差异极大：
-
--optimize（即-o）：仅将 PSR-4 映射预编译为静态数组，仍保留 fallback 到 PSR-4 查找的能力 —— 安全，适合所有环境 -
--classmap-authoritative（即-a）：一旦类不在 classmap 中，直接抛Class not found，跳过所有后续查找逻辑 —— 快，但要求你 100% 确保所有用到的类都在 classmap 覆盖范围内
容易踩的坑：
- 启用
-a后，动态注册的类（如 Laravel 的匿名事件监听器、运行时反射生成的代理类）会直接失败 - 某些包（如
symfony/polyfill）依赖条件加载，未被 classmap 扫描到的 polyfill 文件不会被引入 -
composer dump-autoload -a不会自动包含autoload-dev的路径，dev 类永远不进 classmap
建议做法：CI/CD 流水线中用 composer install --optimize-autoloader --classmap-authoritative --no-dev；本地开发禁用 -a。
生产部署必须加的 4 个 flag
任何漏掉都会让部署变慢、变不可靠：
-
--no-dev：跳过require-dev包安装，也跳过其 autoload 解析 —— 这是提速最有效的一步 -
--optimize-autoloader（或-o）：生成 classmap，避免 runtime 目录遍历 -
--no-progress：禁用进度条，防止 ANSI 控制符污染日志和 CI 输出 -
--no-interaction：防止因缺少交互输入（如 auth token 提示）导致部署挂起
别信“只加 --no-dev 就够了”。实测显示，漏掉 --optimize-autoloader 会让 Laravel 应用冷启动时间多出 30–50ms；漏掉 --no-progress 在 Jenkins 日志里会留下一堆乱码字符，干扰故障排查。
APCu 缓存能替代 classmap 吗
不能，它是补充，不是替代。APCu 缓存的是“类名 → 文件路径”的查询结果，包括没命中 classmap 的 fallback 查找结果；而 classmap 是提前算好的确定性映射。
启用方式很简单：
- 确保 PHP 已启用
apcu扩展且apc.enabled=1 - 运行
composer dump-autoload --apcu-autoloader - 它会在
vendor/autoload.php中插入 APCu 注册逻辑
关键限制：
- APCu 缓存需进程间共享，PHP-FPM 模式下有效，CLI 每次启动都是新进程，缓存几乎无效
- 它不解决首次加载慢的问题，只加速后续请求 —— 所以仍需
--optimize-autoloader降低首查开销 - 与
--classmap-authoritative互斥，二者不能共存
真正影响上线速度的，从来不是“要不要缓存”，而是“有没有砍掉不该加载的东西”。classmap 是刀，APCu 是油，刀没磨快，光上油没用。
