composer.lock解析慢的核心原因是JSON解析与依赖图重建开销大，而非网络问题；当文件超5MB、vendor包超200个时，PHP解析JSON、构建依赖图、校验哈希会显著消耗CPU和内存。
composer.lock 解析慢不是网络问题，是 JSON 解析与依赖图重建开销大
composer.lock 文件本质是一个巨型 JSON，包含所有包的完整元数据（dist checksum、source commit、require-dev 列表等）。当它超过 5MB，尤其在 vendor 包超 200 个时，PHP 解析 JSON + 构建依赖图 + 校验哈希会显著吃 CPU 和内存。此时 composer install 或 composer update --lock 卡在 “Loading composer repositories” 或 “Reading ./composer.lock” 阶段，-vvv 日志里看不到 HTTP 请求，说明根本没发网络请求。
- 运行
composer install --no-scripts --no-plugins --no-dev -vvv，观察卡点是否仍在读 lock 阶段——若仍慢，基本锁定是 lock 文件本身问题 - 用
du -sh composer.lock查大小：>8MB 就算高风险；再用head -n 20 composer.lock | jq .packages | wc -l粗略统计包数量 - 检查是否混入大量
require-dev工具：比如phpunit/phpunit、phpstan/phpstan的旧版本虽不安装，但仍在 lock 中占解析权重
锁文件膨胀的三个典型诱因
大型项目中，composer.lock 膨胀往往不是因为包多，而是结构冗余或配置失当：
- 私有包未声明
"packagist.org": false，导致 Composer 在官方源重复查一遍再 fallback，lock 里留下两套元数据 -
"archive": {"exclude": [...]}缺失，/tests、/docs目录被纳入 dist hash 计算，徒增字段体积 - 长期未运行
composer update --lock，JSON 格式未压缩、重复字段未合并（如多个包共用同一 provider URL 却各自存一份）
快速减重与验证方法
不删 lock、不重装，也能让解析快起来：
- 先执行
composer update --lock：它只重写 lock 文件，不下载任何包，能自动清理冗余字段、压缩 JSON、去重 provider 引用 - 删掉
composer.json中长期不用的require-dev条目，再跑一次composer update --lock - 对私有包，确认其
composer.json含"repositories": [{"type": "composer", "url": "...", "packagist.org": false}] - 验证是否生效：改完后跑
composer install --dry-run -v，看 “Resolving dependencies” 阶段耗时是否从 >10s 降到
别忽略 autoload_classmap 对 lock 解析的间接影响
如果项目启用了 classmap-authoritative 或手动加了大量 classmap 路径（如 "tests/"），Composer 在解析 lock 时会尝试校验这些路径是否存在、是否可读——哪怕你只是 install，它也会逐个 file_exists()。这在 NFS 或 WSL2 挂载路径上尤为明显。
- 临时禁用：
composer config -g classmap-authoritative false - 删掉
composer.json中无意义的"classmap"条目（尤其是examples/、docs/） - WSL2 用户务必避免把
cache-dir设在/mnt/c/下，否则每次解析 lock 都触发跨系统 stat
真正卡住的从来不是“下载”，而是 PHP 把几万行 JSON 反序列化成数组、再一层层构建依赖图的过程。一旦 lock 文件变大，这个过程就不可忽视——它不像网络超时能靠换镜像解决，得从结构和配置上下手。
