换镜像源不能缓解内存溢出，因内存爆点在Resolving dependencies等纯本地计算阶段，镜像仅加速后续Downloading packages；真正有效的是增大PHP内存限制并加--no-dev、--classmap-authoritative等参数。
为什么换镜像源能缓解内存溢出？
不是镜像源本身吃内存，而是默认 packagist.org 响应慢 + TLS握手开销大 + 元数据分片多，导致 Composer 在解析阶段反复重试、缓存失效、并发连接堆积——这些都会推高 PHP 进程的内存驻留峰值。尤其在弱网或 DNS 不稳环境下，composer update 可能卡在 Resolving dependencies 阶段数分钟，期间内存持续增长却无实际进展，最终触发 Allowed memory size exhausted。
哪些镜像源真正降低内存压力？
选源核心看两点：元数据完整性（避免反复回退重试）、响应延迟（packages.json 压缩传输。实测有效的国内源有：
-
https://mirrors.cloud.tencent.com/composer/（腾讯云）：返回包列表快，支持 gzip，CI 中最稳 -
https://packagist.phpcomposer.com（已停更，不推荐） -
https://packagist.laravel-china.org（Laravel 中国镜像）：对 Laravel 生态优化好，但部分非 Laravel 包元数据偶尔滞后 - Docker 内建议用
https://mirrors.ustc.edu.cn/composer/（中科大），DNS 解析快且无地域限速
注意：composer config -g repo.packagist 设置的是全局源，但若项目目录下有 composer.json 显式写了 "repositories"，它会优先覆盖全局配置。
镜像源 + 内存参数必须组合使用
只换源不提内存，对 composer update 几乎无效——因为依赖求解（SAT solver）阶段仍需加载全部版本约束树，这部分开销与网络无关。必须搭配：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- Linux/macOS：
php -d memory_limit=2G composer update --no-dev --no-plugins - PowerShell：
php -d "memory_limit=2G" composer update --no-dev --no-plugins - CI 环境（如 GitHub Actions）：
php -d memory_limit=1.5G COMPOSER_MEMORY_LIMIT=1536M composer install --no-dev -o
其中 --no-dev 和 -o 能砍掉 40%~60% 的 autoload 解析内存，比单靠镜像源有效得多。
容易被忽略的陷阱：镜像源配置残留与缓存污染
换源后仍报内存溢出，大概率是旧缓存没清干净：
-
composer clear-cache必须执行，否则 Composer 会复用损坏或过期的packages.json缓存，导致解析逻辑异常膨胀 - 检查
~/.composer/auth.json是否含私有源凭据——某些私有源响应超时会拖垮整个解析流程 - 若用 Docker，确保
composer cache卷没跨镜像复用；不同 PHP 版本的缓存不兼容，混用会导致静默解析失败 -
composer install前确认composer.lock是由同源、同 PHP 版本生成的；否则 Composer 会退化为update行为，重新计算全量依赖
镜像源只是“减少无效内存消耗”，真正的内存大户永远是依赖解析和 autoload 生成——这两步绕不开参数控制和锁文件治理。
