composer install 变快的关键是优化自动加载和缓存：加 --no-dev、--prefer-dist、--optimize-autoloader 和 --classmap-authoritative；精简 autoload 配置，避免测试/示例目录；启用 apcu（仅 web 环境）；ci 中只缓存 ~/.composer/cache 并利用 docker 层缓存。
Composer 运行缓慢，90% 不是网络问题，而是配置没对 —— 尤其是自动加载和缓存策略。
怎么让 composer install 快起来？
生产部署时最常卡在 composer install，根源往往不是下载慢，而是自动加载器生成耗时 + 重复解析依赖树。
- 必须加
--no-dev：跳过require-dev中所有包（如 phpunit、larastan），省掉 30–60% 时间 - 强制用压缩包而非 Git 克隆：
--prefer-dist（默认已启用，但显式写上更稳妥） - 启用类映射优化：
--optimize-autoloader（注意：不是--optimize，后者在 Composer 2.0+ 已废弃） - 搭配权威模式更稳：
--classmap-authoritative，告诉自动加载器“找不到就真没有”，跳过 PSR-4 文件扫描 - 命令组合示例：
composer install --no-dev --prefer-dist --optimize-autoloader --classmap-authoritative
⚠️ 容易踩的坑：开发环境误加 --classmap-authoritative，会导致新增类不被识别（因为不再 fallback 到文件扫描）；只应在生产构建或 CI 中使用。
autoload 配置怎么写才不拖慢启动？
项目一多，vendor/autoload.php 加载慢，往往是因为 composer.json 里 autoload 写得太“宽”。
- 避免把
tests/或examples/目录塞进"psr-4"或"classmap"，否则它们的类路径全被扫进autoload_classmap.php，文件体积暴涨、I/O 增加 - 小工具函数（如
helpers.php）改用"files"显式加载："files": ["src/helpers.php"]，比 PSR-4 动态匹配快一个数量级 -
"classmap"只列真正需要预扫描的目录，比如接口契约、异常类等静态结构明确的路径，别一股脑写["src/"]
检查方法：打开 vendor/composer/autoload_classmap.php，看里面有没有大量测试类、Mock 类、文档示例路径 —— 有就是配置污染了。
APCu 缓存要不要开？怎么开才生效？
APCu 是目前对自动加载加速效果最直接的方案，但必须配对使用，否则等于没开。
- PHP 必须已安装并启用
apcu扩展（php -m | grep apcu确认） -
"apcu-autoloader": true必须写在composer.json的"config"下，不是 autoload 段 - 执行
composer dump-autoload后才会生成支持 APCu 的加载逻辑 - 首次请求稍慢（填充缓存），后续类加载基本趋近于 0μs
- ⚠️ CI/CD 或 CLI 环境慎用：如果
opcache.enable_cli=1或 APCu 在 CLI 模式下开启，可能掩盖类未加载的 bug，建议仅在 FPM/Web 环境启用
CI/CD 流程中哪些缓存能真正提速？
很多团队缓存整个 vendor/ 目录，反而埋下隐患 —— 二进制扩展（如 xdebug、pdo_pgsql）可能残留、composer.lock 更新后失效、权限错乱。
- 只缓存
~/.composer/cache：这是 Composer 自身的包下载与元数据缓存，复用率高、安全稳定 - Docker 构建时，把
composer.json和composer.lock单独 COPY 并运行composer install，利用层缓存：只要 lock 文件不变，这步就直接命中 - 确保
composer.lock提交进 Git，CI 中永远只跑composer install，绝不用composer update - 私有包多的团队，搭个 Satis 或 Private Packagist，比走 GitHub API + OAuth 令牌更可控、更快
真正的瓶颈往往不在“怎么装”，而在“为什么每次都要重装”——把缓存粒度控制在包级别，而不是目录级别，才是可持续的提速逻辑。
