内存溢出和镜像超时是两类独立问题，必须分开处理——前者靠php -d memory_limit=-1立刻解决，后者靠换阿里云/腾讯云镜像源并清缓存；混用--timeout或盲目加内存对对方完全无效。
直接上结论：内存溢出和镜像超时是两类独立问题，必须分开处理——前者靠 php -d memory_limit=-1 立刻解决，后者靠换阿里云/腾讯云镜像源并清缓存；混用 --timeout 或盲目加内存对对方完全无效。
为什么 composer update 一跑就报 Allowed memory size exhausted
这不是 Composer 慢，是 PHP 进程启动时就被 memory_limit 卡死了。Composer 2.x 在解析依赖图谱、下载元数据、生成 autoload_static.php 时真实内存峰值常超 1.5GB，而 CLI 默认值多为 128M 或 256M。
-
php -d memory_limit=-1必须放在命令最前面，且作用于整个进程（包括插件、脚本、dump-autoload），顺序错或漏写php前缀就无效 - 别信
COMPOSER_MEMORY_LIMIT=-1：它只影响 Composer 内部回溯步数，无法绕过 PHP 的malloc失败 -
composer install也可能爆内存：如果composer.lock文件含大量dev-master哈希或废弃包残留，体积超 5MB，解析开销反而比update还高 - CI 中推荐组合：
php -d memory_limit=2G composer install --no-dev --classmap-authoritative --optimize-autoloader
为什么换源后还是卡在 curl error 28 或 timeout
90% 的“超时”根本不是 Composer 自身逻辑卡住，而是网络连接层失败：DNS 解析慢、TLS 握手卡死、镜像源节点响应延迟。Laravel China 镜像自 2025 年底起已频繁返回 502/503，应立即弃用。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 先验证当前生效的镜像：
composer config -g repos.packagist，正确输出应为{"type":"composer","url":"https://mirrors.aliyun.com/composer/"} - 设完镜像必须立刻执行：
composer clear-cache，否则旧缓存仍会从旧源拉取 - 临时单次使用不改配置：
composer update --repository=https://mirrors.aliyun.com/composer/ - 若仍卡在 TLS，检查系统时间：
date，WSL/Docker 中时间不同步会导致证书验证失败
process-timeout 和 http-timeout 完全不通用
这两个参数控制完全不同的阶段，混设等于白调：
-
http-timeout控制所有 HTTP 请求（如拉packages.json、下 ZIP 包）最大等待秒数，默认 300；卡在Downloading https://...就调它 -
process-timeout只管子进程执行时长（如git clone、unzip、脚本命令），默认 300；卡在Installing dependencies或报The process timed out才调它 -
http-timeout全局设置：composer config --global http-timeout 600；process-timeout全局已废弃，必须用环境变量：export COMPOSER_PROCESS_TIMEOUT=1800 - PHP 底层 socket 超时也会影响：
php -d default_socket_timeout=600 $(which composer) install
真正要盯住的是两件事：一是 php -d memory_limit=-1 是否确实作用到了 Composer 启动的 PHP 进程（查 which php 和 php --ini），二是镜像源是否真的生效且被清过缓存——其余参数都是次要补救，不是根因解法。
