镜像配置本身不改变Composer内存阈值，Allowed memory size exhausted错误不会自动消失；真正影响内存的只有php -d memory_limit、COMPOSER_MEMORY_LIMIT和--no-dev等三类硬性控制，且需协同使用。
镜像配置本身不改变 Composer 内存阈值
配阿里云或腾讯云镜像，Allowed memory size exhausted 错误不会自动消失——镜像只加速 Downloading packages 阶段，而内存爆掉通常发生在更早的 Loading composer repositories 或 Resolving dependencies 阶段。这两个阶段完全不走网络下载，纯靠 PHP 解析 JSON 和跑 SAT 算法，镜像 URL 再快也救不了。
常见误解是“换镜像 = 降低内存压力”，实际恰恰相反：某些镜像（如未启用分片的旧版华为云）仍返回全量 packages.json，反而比官方源更耗内存；只有阿里云/腾讯云 + Composer 2.9.6+ 才支持索引分片，真正减少元数据加载量。
真正影响内存阈值的三个硬性控制点
Composer 没有 memory-limit 配置项，composer config memory-limit 命令根本不存在，写进 composer.json 的 "memory-limit" 字段会被直接忽略。生效的只有以下三者，且必须协同使用：
-
php -d memory_limit=2G：PHP 解释器进程级硬限制，必须放在命令最前，否则无效 -
COMPOSER_MEMORY_LIMIT=2G：Composer 自身逻辑层限制（如依赖回溯步数），仅在 PHP 内存充足时起作用 -
--no-dev --optimize-autoloader --classmap-authoritative：砍掉 dev 包解析、禁用运行时路径扫描、强制 classmap 查找，三者缺一不可
为什么 composer install -v 看不到内存峰值？
--profile 只输出耗时，不显示内存。真实内存占用要靠 Composer 2.9.6+ 自带的日志：Peak memory usage: 1.25GB。若没看到这行，说明你用的是旧版 Composer（如 2.2.x），它既不支持分片镜像，也不打印内存峰值，升级才是前提。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
验证是否真走分片：执行 composer clear-cache 后跑 composer install -v，观察日志中是否出现多条 Loading https://mirrors.aliyun.com/composer/p/packages-a.json 类请求。如果只有一条 Loading https://mirrors.aliyun.com/composer/packages.json，说明分片未生效——大概率是镜像 URL 写错，或项目级 repositories 覆盖了全局配置。
CI/CD 和 Docker 中最容易被忽略的坑
Docker 容器里常因 cgroup 限制导致 php -d memory_limit=2G 失效：即使 PHP 报告 memory_limit=2G，宿主机 cgroup 可能只给容器分配了 512MB，PHP 进程 malloc 直接失败。此时 Allowed memory size exhausted 的报错位置会飘忽不定，有时卡在 autoload dump，有时卡在 JSON 解码。
必须同步检查：
-
cat /sys/fs/cgroup/memory/memory.limit_in_bytes（容器内） -
php -r "echo ini_get('memory_limit');"（确认 CLI 实际生效值） -
php -d zend_extension= -d xdebug.mode=off（Xdebug 在 CI 中默认开着，内存翻倍）
别信 COMPOSER_MEMORY_LIMIT=-1 能兜底——它连子进程（如 unzip）都不管，而 vendor 解压正是内存峰值第二高的环节。
