用time命令包裹完整安装流程（如time rm -rf vendor composer.lock && composer clear-cache && composer install --no-dev --prefer-dist -o -a），并显式设置php -d memory_limit=2G，才能测出真实耗时；需清缓存、禁dev、切内网镜像排除干扰。
怎么测出 Composer 真实安装耗时
别信“大概两分钟”，要拿 time 命令压测真实耗时。关键是排除干扰：清空缓存、禁用 dev 包、固定网络环境（比如关掉代理或切到内网镜像），否则测出来的是网络抖动，不是 Composer 本身性能。
推荐命令组合：
rm -rf vendor composer.lock && composer clear-cachetime php -d memory_limit=2G /usr/local/bin/composer install --no-dev --prefer-dist --optimize-autoloader --classmap-authoritative
注意：time 要包住整个命令，不能只包 composer install；PHP 内存限制必须显式加，否则大项目可能因 OOM 中断，导致时间不准甚至中断重试。
为什么 composer dump-autoload -o 多数时候没用
它不重建 vendor/composer/autoload_classmap.php，只是刷新 PSR-4 映射和 autoload_static.php。而真正影响加载速度的 classmap 文件，只在 install 或 update 阶段生成。
常见错误现象：
- 执行完
dump-autoload -o，autoload_classmap.php文件大小仍是 0 或没变化 - 内存占用反而上升（因为 PHP 强制加载了未被 OPcache 有效缓存的大数组）
- 冷启动变慢，尤其在 PHP 7.4+ 和 Composer 2.x 环境下
真正该用的是：composer install -o —— 它会重新扫描所有 autoload 配置项（包括 psr-4、classmap、files），生成完整且一致的 classmap。
生产环境必须加的三个参数
这三个不是“可选优化”，而是生产部署的硬性要求，漏一个就可能多花 30% 时间或埋下运行时隐患：
-
--no-dev：跳过require-dev里所有包（如phpunit、larastan），省掉 30–60% 的解析与下载时间 -
--optimize-autoloader（或-o）：触发 classmap 全量重建，让自动加载走静态路径查表，而非动态拼路径 +file_exists() -
--classmap-authoritative（或-a）：关闭 fallback 查找，类不在 map 里就直接报错——这反而能暴露命名空间拼写错误、PSR-4 配置遗漏等真实问题，而不是让它默默慢下去
⚠️ 注意：--classmap-authoritative 在开发环境禁用，否则新增类不生效（因为不再扫描文件系统）；它只适合 CI 构建、Docker 构建镜像、上线部署等一次性确定代码状态的场景。
autoload 配置污染是隐形性能杀手
很多项目 composer.json 里写了 "psr-4": {"App\": "src/"}，但 src/ 下混着 tests/、examples/、docs/ 目录，结果这些目录下的类全被扫进 autoload_classmap.php，文件体积暴涨、I/O 增加、OPcache 命中率下降。
检查方法很简单：
- 打开
vendor/composer/autoload_classmap.php - 搜
tests/、example、Mock、Fixture等关键词 - 有就说明配置污染了
修复方式：
- 把测试目录从
psr-4移出，改用"autoload-dev"单独声明 - 全局 helper 函数用
"files"显式加载，比 PSR-4 快一个数量级 -
"classmap"只列契约接口、异常类等结构稳定、极少增删的目录，别写["src/"]
最易被忽略的一点：APCu 缓存只在 PHP-FPM 模式下对 autoload 有效，CLI 下跑 composer install 时加 --apcu-autoloader 是无效的——别白配。
