最快解法是php -d memory_limit=-1 composer install，需确保参数位置正确：php在前、等号无空格、powershell中加引号；composer_memory_limit仅控制composer自身逻辑，不替代php限制；update比install更耗内存因需重建依赖图谱，生产环境应禁用在线update。
直接加内存参数就能过，别改 php.ini，也别信“清缓存能解决”这种半截子方案。
php -d memory_limit=-1 是最快解法，但得写对位置
Composer 内存爆掉，本质是 PHP CLI 进程被默认 memory_limit=128M 卡死。临时提限最稳，但必须确保 -d 参数生效：
-
php -d memory_limit=-1 composer install—— Linux/macOS/Windows CMD 都行，等号不能有空格 - PowerShell 里要加引号：
php -d "memory_limit=-1" composer update - 如果用的是
composer.phar，必须写成php -d memory_limit=2G ./composer.phar install，php得在最前 - 别写成
composer install -d memory_limit=-1——这是把-d当 Composer 参数传了，完全无效
COMPOSER_MEMORY_LIMIT 环境变量更轻量，但有局限
这个变量只控制 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：运行
export COMPOSER_MEMORY_LIMIT=2G后再执行composer install - Windows CMD：必须写成
set COMPOSER_MEMORY_LIMIT=2G && composer install（注意&&不能有空格） - Git Bash/WSL 容易被
.bashrc覆盖，建议显式传入，别依赖环境自动加载 - 它对
dump-autoload也生效，但该命令本身内存压力小，一般不需要调
为什么 composer update 更容易崩，而 install 常常能过
composer update 不是“升级几个包”，而是重建整个依赖图谱：
- 下载所有包的
composer.json元数据，递归解析版本约束 - 跑 SAT 求解器判断兼容性，全程内存建模，峰值常超 1.5GB
-
composer install只读composer.lock精确还原，跳过所有计算，内存通常不到 200MB - 生产环境禁止直接跑
composer update；所有更新必须在开发机完成并提交composer.lock
真内存不够时，光加参数还不够
有些场景下，即使设了 memory_limit=-1 仍会失败，问题不在 PHP 限制，而在系统层面：
- Docker 环境：光设 PHP 内存没用，还得同步调大容器限制，例如
docker run --memory=4g - CI/CD（如 GitHub Actions）：ubuntu-latest 默认总内存才 7GB，PHP 进程分到的更少，建议固定设
php -d memory_limit=2G而非-1 - OOM killer 杀进程：错误可能静默发生，表现为卡住无输出、或中途退出没报错——这时看
dmesg | grep "killed process"能确认 - 项目里混入了
logs/、storage/、node_modules/这类目录，dump-autoload阶段会扫描它们，直接拉爆内存
真正棘手的不是“怎么加内存”，而是当锁文件里有 300+ 包、嵌套深度 >20、又开着 xdebug 时，连 2G 都不一定够——这时候得先砍依赖、关插件、关调试器，再谈扩容。
