默认PSR-4映射使首次类加载触发目录遍历和file_exists()调用，I/O开销在无OPcache或启用Xdebug时被放大；真正拖慢启动的是未启用optimize-autoloader、classmap-authoritative误用于动态类、post-install-cmd脚本提前require、composer.lock过大导致autoload_static.php解析耗时上升，以及镜像源配置错误引发HTTP阻塞。
composer install 生成的 autoload.php 怎么拖慢 PHP 启动
它不直接变慢，但生成方式决定运行时开销。默认 PSR-4 映射在 require 'vendor/autoload.php' 时不做任何文件操作，但第一次加载类时会遍历目录、file_exists()、is_file()——这些 I/O 在启用了 xdebug 或未启用 opcache 的 CLI 环境下会被放大。
真正卡住启动的，往往是以下几种情况：
-
"optimize-autoloader": true没开：autoload 文件小，但每次类加载都触发磁盘扫描 -
"classmap-authoritative": true开了但项目含动态类（如 Doctrine 实体通过字符串拼接加载）：找不到就直接报错，不是慢，是崩 - 引入了带大量
src/子目录的包（比如某些旧版 Symfony Bundle），即使开了优化，composer dump-autoload -o仍要递归扫描几百个路径
post-install-cmd 脚本在 vendor/autoload.php 加载前就执行
很多包的 post-install-cmd 会提前 require 自己的 autoloader 或调用 ClassLoader::addPsr4()，这类脚本不在 autoload 阶段，但会在 composer install 最后一步执行——而此时 vendor/autoload.php 还没生成。
典型表现是：php artisan serve 启动变慢，但 --profile 显示 [1.7s] Executing script post-install-cmd 占大头。常见原因包括：
立即学习“PHP免费学习笔记（深入）”；
- Laravel 的
php artisan config:clear被写进脚本，清缓存时读取全部配置文件 - Doctrine 扩展在安装时扫描
config/下所有 YAML 并解析成数组 - 某些 SDK（如阿里云 OSS）在
post-install中预加载证书或生成临时密钥文件
composer.lock 体积大会让 autoload.php 初始化变慢
composer.lock 本身不参与运行时，但它决定了 vendor/autoload.php 的结构。当 lock 文件超过 5MB（常见于含 200+ 包 + 大量 require-dev 的项目），composer install 生成的 autoload_static.php 会包含冗余 classmap 条目，导致 PHP 解析该文件耗时上升。
这不是 autoload 逻辑慢，而是 PHP 解析一个巨大 PHP 数组字面量本身就吃 CPU。实测对比：
- lock 文件 1.2MB →
autoload_static.php89KB →require耗时 12ms - lock 文件 8.6MB →
autoload_static.php1.4MB →require耗时 187ms（未启用 opcache）
解决方法不是删包，而是定期运行 composer update --lock 压缩元数据，并确认私有包声明了 "archive": {"exclude": ["/tests", "/docs"]}。
镜像源配置错误会让 composer install 间接影响 PHP 内存使用
表面看是网络慢，实际是 PHP 进程卡在 DNS 轮询或 TCP 握手超时。典型错误配置："packagist.org": false 但没配 repositories，或镜像 URL 少了个末尾 /（如 https://mirrors.aliyun.com/composer → 404 → fallback 到官方源 → 国内 DNS 解析 packagist.org 超时）。
后果是：composer install 进程长时间占用高内存（>512MB），且 php -m | grep xdebug 显示已禁用，却仍卡在 Resolving dependencies ——其实 Solver 已算完，只是卡在 HTTP 请求重试上。
验证是否真走镜像：
- 加
-vvv参数，看日志里请求的是mirrors.aliyun.com还是packagist.org - 用
curl -I https://mirrors.aliyun.com/composer/packages.json测通断 - 检查
composer config -g repo.packagist输出是否为完整 JSON，不是空或字符串
最隐蔽的一点：Composer 2.2+ 不再支持 parallel-downloads，设了等于白设；必须用 http-max-concurrent-downloads，否则并发数始终为 1，下载阶段拉长，PHP 进程驻留时间变久，间接推高内存峰值。
