内存溢出与镜像源无关，根本原因是php进程在resolving dependencies阶段加载全部依赖元数据导致内存耗尽；应使用php -d memory_limit=2g composer install --no-dev -o --classmap-authoritative组合方案。
内存溢出和镜像源无关，换镜像不会缓解 Allowed memory size exhausted 错误。Composer 卡在 Resolving dependencies 阶段时，问题根本不在下载速度或网络延迟，而在于 PHP 进程内存被撑爆——它正在把所有包的版本约束、autoload 映射、锁文件元数据全加载进内存做 SAT 求解，此时换再快的镜像也无济于事。
为什么换镜像对内存溢出完全无效
Composer 解析依赖图（SAT 算法）是纯内存计算行为，不涉及网络 I/O。即使使用官方源、阿里云镜像或腾讯云镜像，只要 composer.lock 未变、PHP memory_limit 不足，就会在同一个位置报错。镜像只影响 Downloading packages 阶段，而崩溃通常发生在它之前的 Resolving dependencies 或之后的 Generating autoload files。
- 错误末尾带
bytes exhausted，说明是 PHP malloc 失败，不是 cURL 超时或 DNS 解析失败 -
composer install用锁文件还原时，90% 的内存消耗来自解析 lock 文件本身（尤其含大量dev-master提交哈希或嵌套 package-versions） - 镜像加速的是 zip 包下载，但内存峰值早已在依赖解析完成时就达到了
真正有效的内存控制参数组合
硬提内存只是表象，关键要砍掉不必要的解析和生成环节。以下参数必须成组使用，单加一个效果有限：
-
--no-dev：跳过require-dev解析，内存常降 40%~60%，上线部署必加 -
--optimize-autoloader（或-o）：生成 classmap，避免运行时动态扫描，降低 dump 阶段峰值 -
--classmap-authoritative：配合-o使用，告诉 autoloader “只信 classmap，别 fallback 查找”，进一步减内存 -
--no-plugins和--no-scripts：禁用插件钩子与 post-install-cmd，防止额外串行开销
CI/CD 中推荐固定写法：php -d memory_limit=2G composer install --no-dev -o --classmap-authoritative
php -d memory_limit 必须放在最前面且写对格式
这个参数不是可选修饰，而是 PHP 进程启动时的强制覆盖。顺序错、引号漏、单位小写，都会让它失效：
- Linux/macOS 正确：
php -d memory_limit=-1 composer install - PowerShell 必须加引号：
php -d "memory_limit=-1" composer install - Windows CMD 可写为：
php -d memory_limit=-1 composer install（部分旧版需双引号） - 单位必须大写：
2G有效，2g被忽略；-1表示不限制，比硬编码数值更可靠 - 如果用
composer.phar，必须带php前缀：php -d memory_limit=2G composer.phar update
COMPOSER_MEMORY_LIMIT 环境变量的真实作用范围
它只影响 Composer 自身某些可中断逻辑（比如依赖回溯步数上限），**不能绕过 PHP 底层的 memory_limit**。常见误区：
- 单独设
COMPOSER_MEMORY_LIMIT=-1而不改php -d，依然会卡在 128M 报错 - 它的优先级低于
php -d，高于php.ini，所以两者共存时以后者为准 - CI 中建议用具体值而非
-1，例如COMPOSER_MEMORY_LIMIT=1536M，防止单次异常拖垮构建节点 - 它对
composer dump-autoload也生效，但该命令本身内存占用低，一般不需要调
最易被忽略的一点：Docker 容器若没配 --memory=4g，即使 PHP 内存设为 -1，也会被 OOM killer 直接杀掉进程——这时看日志是 Killed 而非 Allowed memory size exhausted。
