私有化 Composer 镜像仓库不能解决依赖解析（Resolving dependencies）的 CPU 穷举瓶颈，仅加速下载；其配置不当会加剧 I/O、缓存、并发等次级问题，正确配置需确保 repos.packagist 拼写准确、清除缓存、验证 URL 生效，并在 Monorepo 中禁用 path 扫描、改用 artifact、收敛 autoload 与 lock 文件。
私有化 Composer 镜像仓库本身不解决 Composer 的核心性能瓶颈——Resolving dependencies 卡顿本质是本地 SAT 求解，不是网络或镜像源问题；但私有仓库配置不当会放大 I/O、缓存、并发等次级瓶颈。
为什么切到私有镜像源后 install 仍慢？
常见错误现象：composer install -vvv 日志里仍有 https://packagist.org/packages.json 请求路径，说明镜像源没生效。
-
repos.packagist拼写必须是repos（不是repo），错一个字母就 fallback 到官方源 - 必须执行
composer clear-cache，否则旧缓存继续走 packagist.org - 验证是否生效：
composer config -g repos.packagist输出应为完整 URL；再跑一次composer install -vvv，最后几行应含aliyun或你配置的私有域名 - 私有镜像源若不支持 HTTP/2 多路复用，
--concurrency和parallel-downloads参数基本无效——并发请求被排队堵死
私有仓库在 Monorepo 场景下的 I/O 杀手行为
Composer 2.9.6 在 Monorepo 中默认扫描所有 repositories.path 目录下的 composer.json，并尝试建立 symlink。几十个 packages 目录叠加，I/O 和逻辑开销能把安装从几秒拖到数分钟。
- 禁用自动扫描：
"repositories": [{"type": "path", "url": "./packages/*", "options": {"symlinks": false}} - 改用
artifact类型仓库替代path：提前打包.zip或.tar.gz，避免实时扫描和 symlink 创建 - 每个微服务只声明自己真正依赖的私有包，不要把整个 Monorepo 的
repositories全局塞进每个composer.json
私有包版本别名与解析失败的隐性陷阱
引用 dev 分支时漏写别名，composer require acme/shared-utils:dev-main 会报 Could not find package，但错误信息不提示“缺别名”，容易误判为镜像源或网络问题。
- 必须显式加
as别名：composer require acme/shared-utils:dev-main as 1.0.x-dev - 别名不能随意写：
1.0.x-dev是合法开发版标识，1.0.0-dev会被 Composer 当作正式版处理，导致冲突 - 私有仓库的
packages.json若未正确生成dist字段（如缺少reference或shasum），Composer 会退回到 slow path（即 clone + checkout），大幅拖慢安装
微服务间共享包引发的 autoload 越界加载
每个微服务的 composer.json 中 autoload 映射若写成 "Acme\": "vendor/acme/*/src"，会导致自动加载器跨服务加载代码，破坏隔离性，同时显著增加 Generating autoload files 阶段耗时。
- 只映射自身命名空间：
"App\": "src/"，绝不跨 vendor 目录 - 共享库必须发布为独立包，通过
require引入，而非 autoload 拖入 - 生产环境务必加
--classmap-authoritative，否则 Composer 运行时仍会扫描未声明的路径，I/O 开销翻倍
最易被忽略的是：私有镜像仓库能加速下载，但解决不了依赖树爆炸带来的 CPU 穷举；而微服务架构下，每个服务独立 composer.lock + 收敛 autoload + 删掉 minimum-stability: dev，比换镜像源更能立竿见影地缩短 Resolving dependencies 时间。
