Composer报内存不足是PHP主内存耗尽，非显存问题；根本原因是依赖解析时元数据加载超默认128M限制，应优先用php -d memory_limit=2G或COMPOSER_MEMORY_LIMIT=-1临时扩容，并禁用dev依赖与插件。
Allowed memory size exhausted），和 GPU 显存完全无关。
为什么 Composer 会报“内存不足”，但不是显存问题
Composer 是纯 PHP CLI 工具，运行在 CPU + 主内存环境里，不调用 GPU、不分配显存。所谓“渲染失败”“显存溢出”是误读，真实错误永远是：PHP Fatal error: Allowed memory size of XXXXXX bytes exhausted。这个 XXXXXX 字节数（比如 134217728）对应的是 PHP 进程的 memory_limit 设置，通常是 128M 或 256M。
php -d memory_limit=-1 为什么有时不生效
- 你用的是系统包装器（wrapper）：运行
which composer，如果输出是/usr/bin/composer，说明它是个 shell 脚本或二进制 wrapper，-d参数被直接忽略 - 没写对命令顺序：必须是
php -d memory_limit=-1 composer install，不能写成composer -d memory_limit=-1 install - Windows PowerShell 忘了加引号：
php -d "memory_limit=-1"缺少双引号会导致-1被当成命令行选项丢弃 - 用了
composer.phar却漏掉php前缀：必须写php -d memory_limit=-1 composer.phar install，不能直接执行./composer.phar
composer install 和 update 的内存差异在哪
composer update 是真正的内存杀手，composer install 理论上轻量，但实际表现取决于 composer.lock 是否干净：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
update必须跑 SAT 求解器，尝试成百上千种版本组合，所有元数据全加载进内存，峰值常超 1.5GB -
install只按 lock 文件还原，但如果 lock 文件体积 >5MB（含大量 dev-master 哈希、废弃包残留），解析开销反而比 update 还高 -
require命令本质是update的简化入口，同样触发完整依赖求解，内存压力高 5–8 倍 - CI/CD 中应禁用
update，只允许install --no-dev --optimize-autoloader
autoload 配置不当也会导致内存爆掉
vendor/autoload.php 生成失败时提示内存不足，问题不在 autoload 本身，而在 dump-autoload 阶段扫描了不该扫的目录：
-
composer.json中autoload或autoload-dev错误包含了node_modules/、dist/、storage/、logs/等非 PHP 目录 -
autoload.files引入了超大 helpers 文件（如含数百函数的helpers.php），反复加载解析 - 运行
composer dump-autoload --no-scripts单独测试，可快速定位是否由脚本或 autoload 触发 - 删掉 composer.json 中所有指向大体积非代码目录的 autoload 配置项
php -d memory_limit=4G 写得再全，只要 composer.json 里还留着几十个 require-dev 包，Composer 解析阶段仍要下载并载入它们全部的 composer.json 元信息——这部分开销无法靠跳过安装规避。 
