php -d memory_limit=-1 composer install必须前置执行，因composer是php进程，其内存上限由php启动时memory_limit锁定；错误写法如composer install -d memory_limit=-1会被忽略，正确写法需将php -d参数置于最前且不可换行或加管道。
直接加内存限制，别改 php.ini，也别信“清缓存就能好”这种模糊建议——Allowed memory size exhausted 是 PHP CLI 进程被卡死的明确信号，不是 Composer 有 bug。
php -d memory_limit=-1 composer install 为什么必须放最前面
因为 composer 命令本质是 PHP 脚本（phar 包），它启动时就受当前 PHP 进程的 memory_limit 约束。如果只写 composer install，系统会用默认配置（通常是 128M），根本撑不住 Laravel/Symfony 类项目。
-
php -d memory_limit=-1必须写在composer前面，且中间不能换行或加管道——否则参数不生效 - Windows CMD 下等号两边不能有空格：
php -d"memory_limit=-1" composer install - PowerShell 中
-1需加引号：php -d "memory_limit=-1" composer install - 如果你用的是
composer.phar文件路径，命令得是：php -d memory_limit=2G ./composer.phar install
CI/CD 里 composer install 失败但本地正常怎么办
GitHub Actions、GitLab CI 默认 PHP 配置极保守（常为 128M），且不加载你本地的 php.ini。光靠 COMPOSER_MEMORY_LIMIT 不够，它只影响 Composer 自身逻辑，不覆盖底层 PHP 限制。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 必须显式调用
php：CI 的run:步骤里不能只写composer install，要写成php -d memory_limit=2G composer install - GitHub Actions 若用
composer/setup-phpAction，务必填memory-limit: 2G输入项，它会自动注入 - GitLab CI 示例：
php -d memory_limit=2G /usr/bin/composer install --no-interaction - Docker 环境下，还要确认容器本身内存充足：
docker run --memory=4g，否则 PHP 层面再放开也会被 OOM killer 杀掉
为什么 composer update 比 install 更容易崩
update 要重算整个依赖图、下载所有包元数据、执行 SAT 求解器回溯版本兼容性；而 install 只按 composer.lock 精确还原——前者是内存+CPU 双密集型，后者基本只刷磁盘 IO。
- 生产环境禁止跑
composer update，所有更新必须在开发机完成并提交composer.lock - 真要在线更新，先加
--dry-run看会动哪些包：composer update --dry-run - 缩小范围：用
composer update vendor/package-name替代全量更新 - 禁用插件减负：
composer update --no-plugins，尤其旧版hirak/prestissimo在高并发下载时反而吃更多内存
最容易被忽略的一点：有些报错看似内存不足，其实是系统级 fork 失败，比如 proc_open(): fork failed - Cannot allocate memory。这时加 PHP 内存没用，得在 Linux 上配 swap 分区（dd if=/dev/zero of=/var/swap.1 bs=1M count=1024），否则连进程都起不来。
