php -d memory_limit=-1是解决Composer内存溢出的最直接方法，因其绕过PHP默认内存限制（常为128M/256M），专用于依赖解析、元数据下载等高内存阶段，且仅临时生效、无需修改php.ini。
php -d memory_limit=-1 是最直接的解法
Composer 报 Allowed memory size exhausted，根本不是它自己“吃内存”，而是 PHP 进程启动时默认限制太低（常为 128M 或 256M），而 Composer 在解析依赖图、下载元数据、执行 SAT 求解器时会阶段性冲高——大型项目峰值常超 1.5GB。
临时提限只对当前命令生效，安全且无需改配置：
-
php -d memory_limit=-1 composer install：开发机上最常用，-1 表示不限制 -
php -d memory_limit=2G composer update：CI/CD 或 Docker 环境更推荐，防 OOM killer 杀进程 - 若用
composer.phar，同样加在php后：php -d memory_limit=2G composer.phar install - Windows CMD 中注意加引号：
php -d "memory_limit=-1" composer install
别碰 php.ini——CLI 和 Web SAPI 的配置文件往往不同，你改了 Apache 的，对终端里的 Composer 没用；验证当前 CLI 加载路径：php -i | grep "Loaded Configuration File"。
COMPOSER_MEMORY_LIMIT 环境变量怎么设才生效
这个变量是 Composer 自己读的，只控制其内部逻辑（比如依赖解析阶段）的内存阈值，不覆盖 PHP 底层限制。优先级：php -d > COMPOSER_MEMORY_LIMIT > php.ini。
设法要匹配环境：
- Linux/macOS：
COMPOSER_MEMORY_LIMIT=2G composer install - Windows CMD：
set COMPOSER_MEMORY_LIMIT=2G && composer install（注意&&前后不能有空格） - Git Bash / WSL：
COMPOSER_MEMORY_LIMIT=2G composer install，但别依赖.bashrc，shell 配置可能覆盖它 - Docker：光设这个变量不够，还得同步调大容器内存，例如
docker run --memory=4g
它对 composer dump-autoload 也生效，但该命令本身内存占用低，一般不需要调。
为什么 composer update 比 install 更容易崩
composer update 要重新构建整个依赖图：下载所有包的 composer.json 元数据、递归解析版本约束、运行 SAT 求解器判断兼容性、校验 hash、生成新 composer.lock——全程内存建模，峰值常超 1.5GB。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
composer install 只读 composer.lock 精确还原，跳过所有计算，内存通常不到 200MB。
所以生产环境禁止直接跑 composer update；所有更新必须在开发机完成并提交 composer.lock。
必须在线更新时：
- 先加
--dry-run看会动哪些包，避免盲目执行后卡死 - 用
composer update vendor/package-name替代全量更新，缩小解析范围 - 加
--no-plugins禁用插件，某些旧版插件（如hirak/prestissimo）会在解析前预加载全部类，反而加剧压力 - 确认没开着
xdebug——它会让 Composer 内存占用翻倍以上
vendor/autoload.php 生成失败也报内存不足？那是扫描错了目录
这不是 dump-autoload 本身的问题，而是它被迫扫描了不该扫的文件：比如 logs/、storage/、node_modules/，或者 composer.json 里 autoload 配置误包含了 dist/ 目录。
检查点：
- 项目根目录下有没有未清理的大体积非代码文件（如日志、缓存、前端构建产物）
-
composer.json的autoload和autoload-dev是否把node_modules/、dist/、public/等非 PHP 目录写进去了 - 运行
composer dump-autoload --no-scripts单独测试，排除脚本干扰 - 如果用了
"optimize-autoloader": true，确保新增类不会在开发中动态生成，否则可能漏加载
真正危险的不是内存设多大，而是你没意识到 composer update 在复杂锁文件（比如 300+ 包、嵌套深度 >20）下，即使设了 2G，仍可能被系统 OOM killer 杀掉——这时候得靠拆包、清理废弃依赖、或换到 Composer 2.5+ 的增量解析能力。
