最有效解法是 php -d memory_limit=-1 composer update；本地开发可用此命令，windows需写为 php -d"memory_limit=-1"；ci/docker中应改用2g或3g并检查容器内存配额、php配置及xdebug状态。
直接加内存参数，别碰 php.ini，也别信“清缓存就能好”这种模糊建议。
php -d memory_limit=-1 是最有效的单行解法
Composer update 比 install 更吃内存，因为它要重算整个依赖图、下载元数据、比对版本约束——不是代码写得差，是 PHP 进程默认只给 128M 或 256M，根本不够用。
- 本地开发：直接运行
php -d memory_limit=-1 composer update，-1表示不限制，绝大多数情况秒过 - Windows CMD 用户注意：等号两边不能有空格，写成
php -d"memory_limit=-1" composer update更稳妥 - 如果你用的是
composer.phar文件路径，必须把php -d放最前：php -d memory_limit=2G ./composer.phar update -
-1在 CI 或 Docker 容器里慎用——可能触发 OOM killer，此时改用2G或3G更稳
COMPOSER_MEMORY_LIMIT 环境变量更适合脚本和 CI
它比 -d 参数更轻量，且 Composer 原生支持，优先级高于 php.ini，只作用于自身逻辑，不影响其他 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 update - GitLab CI 示例：
COMPOSER_MEMORY_LIMIT=2G composer update --no-interaction - GitHub Actions 中若用
composer/setup-phpAction，直接配memory-limit: 2G即可，它会自动注入 - 别在
.env或phpunit.xml里设PHP_MEMORY_LIMIT——Composer 不读这些
为什么 dump-autoload 失败也报内存不足
这不是 autoload 本身的问题，而是 dump-autoload 阶段在扫描所有 PHP 文件构建类映射时，被不该处理的文件拖垮了。常见诱因：
- 项目根目录下误放了
logs/、storage/app/或巨型 JSON 配置文件 -
composer.json的autoload或autoload-dev把node_modules/、dist/甚至vendor/自身包含进去了 - 运行
composer dump-autoload --no-scripts单独测试，能快速排除脚本干扰 - 确认没开着
xdebug——它会让 Composer 内存占用翻倍以上，临时关掉再试：php -d zend_extension= -d xdebug.mode=off composer update
Docker 和 CI 环境里最容易忽略的三件事
本地跑得通，CI 报 Allowed memory size exhausted，往往不是命令写错了，而是环境没对齐：
- Docker 容器本身内存不足：比如 Docker Desktop 默认只分 2GB，即使你写了
php -d memory_limit=3G，也会被系统直接Killed（无堆栈、无错误信息）——得先调高容器--memory=4g - CI 默认用轻量 PHP 环境，
memory_limit常被硬设为 128M，且不加载用户 shell 配置；必须显式调用php，不能只写composer install - 某些共享主机或 CI 平台禁止
-1，这时必须用具体值，如2G，并确保单位是G（不是GB或g）
真正卡住的时候，不是参数没加对，而是忘了 Docker 内存配额、CI 的 PHP 独立配置、或者 xdebug 还开着——这些点不排查，光调 memory_limit 只是反复撞墙。
