镜像源对allowed memory size exhausted错误完全无效，因该错误发生在resolving dependencies阶段（纯内存计算），与下载无关；根本解法是php -d memory_limit=-1配合--no-dev -o --no-plugins --no-scripts等参数组合降内存峰值。
完全没用。换镜像源对 Allowed memory size exhausted 错误毫无缓解作用，因为崩溃发生在 PHP 进程内存耗尽时，而镜像只影响下载阶段。
为什么镜像源和内存溢出无关
Composer 安装分多个阶段：Resolving dependencies → Downloading packages → Generating autoload files。绝大多数 Out of memory 错误都卡在第一个阶段——此时 Composer 正在用 SAT 算法解析整个依赖图，把所有包的版本约束、autoload 映射、提交哈希全加载进内存做逻辑求解。这个过程不发任何网络请求，镜像再快也插不上手。
你看到的错误末尾通常是类似 Allowed memory size of 134217728 bytes exhausted，这明确指向 PHP 的 malloc 失败，不是 cURL 超时或 DNS 解析失败。
- 镜像只加速
Downloading packages阶段（即 zip 包拉取） -
Resolving dependencies是纯 CPU+内存计算，和网络零关系 - 即使
composer.lock没变，只要memory_limit不足，每次都会在同一行崩溃
真正有效的内存控制组合参数
单加一个 --no-dev 或只提 memory_limit 效果有限，必须成组使用：
-
--no-dev：跳过require-dev解析，内存常降 40%~60% -
-o（即--optimize-autoloader）：生成 classmap，避免运行时扫描 -
--classmap-authoritative：配合-o，禁止 autoloader fallback 查找 -
--no-plugins和--no-scripts：禁用插件与钩子，防止额外串行开销
推荐命令： php -d memory_limit=2G composer install --no-dev -o --classmap-authoritative --no-plugins --no-scripts
换镜像反而可能掩盖真实问题
有人换完镜像发现“好像不报错了”，其实是缓存或偶然因素导致，下次 composer update 一跑照样崩。更危险的是，误以为镜像能治内存问题，结果在线上环境因未加 --no-dev 导致部署失败。
如果项目含大量 dev-master 提交哈希或嵌套 package-versions，composer.lock 文件本身就会撑爆内存——这时连 composer install 都可能卡死，和镜像源彻底无关。
最易被忽略的一点：PHP 的 memory_limit 是 per-process 限制，composer install 是单进程执行，所有优化都得在这个前提下做减法，而不是指望网络层帮忙。
