针对百万级依赖的Composer库锁定文件解析性能优化

先说几个核心判断：Composer卡在依赖解析阶段，十次里有八九次不是网络问题，而是SAT求解器在暴力穷举时撞上了组合爆炸。这种现象在300+包、多私有源、以及宽松版本约束的场景下尤其常见——回溯深度轻轻松松突破万级。CPU满负荷运转、内存持续增长、终端超过一分半钟没动静，基本可以判定已卡死。

别傻等着它自己解出来。Ctrl+C中断后，立刻做三步操作：先跑composer update --dry-run -v，最后几行会明确告诉你哪两个包无法共存；再用composer why-not package/name:version直击阻断链——比如composer why-not symfony/console:6.4，冲突原因一目了然；最后临时删掉require-dev里的phpunit/phpunit、phpstan/phpstan这类重型工具，用composer update --no-dev再试一次。

lock-file-version: 2不是可选项，是性能底线

旧版composer.lock（v1）会为每个包冗余存储完整的require-dev列表、source commit、dist checksum等元数据。百万级依赖场景下，文件体积经常超过15MB。v2压缩了字段结构、去掉了重复键、改用更紧凑的JSON序列化方式，实测解析耗时能下降35%到50%。

确认并强制升级的方法很直接：检查composer.json是否包含"lock-file-version": 2——注意必须是数字，不是字符串。如果没生效，直接删掉现有composer.lock再执行composer install（前提是composer.json无敌），或者运行composer update --lock，不改依赖，仅重写lock文件。

--no-dev和--prefer-dist必须一起用，否则等于没关

--no-dev只跳过dev包的安装阶段，但默认仍要解析它们的约束；--prefer-dist强制走ZIP包而非Git clone，可一旦镜像配置失效或缓存未清，它会fallback到source模式，反而更慢。要让它们真正生效，需要满足几个前提条件：

• 先执行composer clear-cache，否则旧缓存仍会打原站
• 确认镜像已全局生效：composer config -g repo.packagist输出应为扁平URL，不能是{"packagist.org": {...}}
• CI/CD中必须加--no-interaction --no-progress——前者防止挂起，后者避免ANSI控制符刷屏拖慢日志写入

autoload扫描路径太宽会拖垮整个解析流程

很多人以为autoload只影响运行时，其实Composer在生成autoload_classmap.php前会递归扫描所有声明的目录。如果vendor/里混入了测试用例、文档示例、Mock类，或者项目自身的autoload配置写了"psr-4": {"App": "app/"}却没排除app/Tests，I/O开销会指数级上升。

快速自查与收敛方式：运行ls -lh vendor/ | head -20，看是否有异常大的包（比如包含完整docs或tests目录）。在对应包的composer.json中确认是否设了"archive": {"exclude": ["/tests", "/docs"]}。项目级autoload改用精确路径，例如把"App": "app/"拆成"App": "app/Http/Controllers/", "AppModels": "app/Models/"。

真正难处理的是那些早已废弃但仍在composer.lock里占位的dev工具——它们不安装，却参与每一轮解析。删掉它们，比优化autoload更立竿见影。