直接用 php -d memory_limit 临时提限最稳，如 php -d memory_limit=2g composer install；ci/cd 中须显式写全命令；composer_memory_limit 环境变量更轻量，适合脚本集成。
直接加内存限制，别改 php.ini，也别指望 composer.json 配置能起作用——它根本不管内存分配。
用 php -d memory_limit 临时提限最稳
这是唯一能立刻生效、不污染环境、且兼容所有 PHP 版本和系统的方式。关键不是“能不能”，而是“怎么写对”：
-
php -d memory_limit=2G composer install（Linux/macOS/Windows CMD 均可用，等号不能有空格） -
php -d "memory_limit=-1" composer update（PowerShell 或含空格路径时必须加引号） - 如果你调用的是
composer.phar文件，命令必须是php -d memory_limit=2G ./composer.phar install，php必须在最前 - CI/CD 中（如 GitHub Actions）务必显式写全：不要只写
composer install，否则走的是系统默认的 128M 限制
COMPOSER_MEMORY_LIMIT 环境变量更适合脚本场景
它比 -d 更轻量，只影响 Composer 自身逻辑（比如依赖解析），不干预底层 PHP 行为，适合集成进部署流程：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- Linux/macOS 临时生效：
COMPOSER_MEMORY_LIMIT=2G composer install - Windows CMD：
set COMPOSER_MEMORY_LIMIT=2G && composer install（注意&&不能有空格） - GitLab CI 或 GitHub Actions 的
env:块里直接设：COMPOSER_MEMORY_LIMIT: "2G" - 注意：它优先级低于
-d，高于php.ini；设成-1有效，但无法绕过php.ini里硬写的memory_limit = 128M
为什么 composer update 容易崩，而 install 很少出事
这不是偶然——update 要重新跑 SAT 求解器、下载全部元数据、构建完整依赖图，内存峰值常超 1.5GB；install 只读 composer.lock 精确还原，通常不到 200MB。
- 生产服务器上禁止直接跑
composer update，所有更新必须在开发机完成并提交composer.lock - 真要在线更新，先加
--dry-run看会动哪些包，再用composer update vendor/package-name精准操作 - 如果卡住没报错，大概率是被 OOM Killer 静默杀掉了——查
dmesg | grep "killed process"就能确认 - Docker 用户额外注意：
php -d memory_limit=3G不会突破容器--memory=2g限制，得先调高容器配额
最容易被忽略的一点：vendor/autoload.php 生成失败，往往不是 autoload 本身的问题，而是它被迫扫描了 logs/、storage/ 或 node_modules/ 这类目录。检查 composer.json 的 autoload 和 autoload-dev 字段，确保没把非 PHP 文件夹包含进去。
