php -d memory_limit=2G 是最稳的临时解法，直接在 composer 命令前加该参数可绕过配置干扰、立即生效，且 2G 经大量 CI 验证，兼容 PHP 7.4+ 和 Composer 2.9.6。
php -d memory_limit=2G 是最稳的临时解法
直接在 composer 命令前加 php -d memory_limit=2G，是当前最可靠、兼容性最好、CI 验证最多的方案。它绕过所有配置干扰，在进程启动第一刻就生效，且 2G 是经过大量流水线验证的平衡值：够用、不触发 OOM Killer、兼容 PHP 7.4+ 和 Composer 2.9.6。
常见错误现象：php -d memory_limit=2G composer install 没效果，大概率是因为：
-
which composer返回的是 shell wrapper（如/usr/bin/composer），-d参数被忽略——应改用php -d memory_limit=2G /usr/bin/composer install - Windows PowerShell 中没加引号：
php -d "memory_limit=2G" composer install才正确，否则会被当命令参数解析 - 写反顺序，比如
composer install -d memory_limit=2G完全无效
COMPOSER_MEMORY_LIMIT 环境变量只管 Composer 自己的事
COMPOSER_MEMORY_LIMIT 不是 PHP 内存开关，它只控制 Composer 内部依赖求解缓存、包元数据加载等逻辑的软性上限。设了 COMPOSER_MEMORY_LIMIT=2G 却没调高 php -d memory_limit，等于给司机配了导航仪但油箱只有 10L——进程照样在 128MB 就被 PHP 内核 kill 掉。
使用场景和注意事项：
- Linux/macOS：写成
COMPOSER_MEMORY_LIMIT=2G composer install，等号前后不能有空格 - Windows CMD：
set COMPOSER_MEMORY_LIMIT=2G && composer install - 它对
composer update效果明显，对composer install作用有限——因为 install 主要开销在解压和符号链接，由 PHP 直接承担 - 验证是否读到：加
-v参数运行，开头几行会打印Memory limit: 2G
别一看到 Resolving dependencies 就加内存
composer update 卡在 Resolving dependencies 阶段，90% 不是内存不够，而是依赖冲突引发 SAT 求解器陷入指数级回溯。现象是 CPU 拉满、无日志输出、几分钟后静默退出或被 OOM Killer 杀掉。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
此时调高内存可能掩盖真实问题，甚至让失败更慢。你应该先确认：
- 是否真需要全量更新？优先用
composer install，不是update - 缩小范围：
composer update monolog/monolog guzzlehttp/guzzle - 关掉插件：
--no-plugins，尤其已废弃的hirak/prestissimo - 关掉 xdebug：
php -d zend_extension= -d xdebug.mode=off composer update，它会让内存翻倍 - 检查
composer.json是否写了过于宽松的约束，比如"^1.0 || ^2.0"，收紧为"^1.25"或锁定小版本
Docker 和 CI 环境里最容易漏掉的三件事
本地能过、CI 报错，基本是环境没对齐。GitHub Actions 默认不透传环境变量，Docker 容器可能没同步 cgroup 限制。
实操要点：
- CI 中别依赖继承：
run: COMPOSER_MEMORY_LIMIT=2G php -d memory_limit=2G composer install显式写两行才稳 - 容器里即使设了
COMPOSER_MEMORY_LIMIT=-1，宿主机 cgroup 仍可能 kill 进程——得检查docker run --memory或 Kubernetes 的resources.limits.memory - 运行前先验证 CLI 实际限制：
php -r "echo ini_get('memory_limit');"，再查加载路径：php --ini，确保你改的是Loaded Configuration File而不是 Apache 或 FPM 的那个
真正卡住的地方，往往不是内存数字本身，而是 PHP 层限制、Composer 自身逻辑、系统资源限制这三层没对齐。调一个参数解决不了，得一起看。
