composer本身不提供内存限制配置命令，其内存限制完全依赖php cli的memory_limit值，需用php -r "echo ini_get('memory_limit');"查看，而非composer命令；报错时应优先确认php实际生效的memory_limit及系统级限制。
Composer 命令本身不暴露内存限制配置
Composer 没有内置命令（比如 composer --memory-limit 或 composer config 直接查内存）来显示当前生效的内存限制。它的内存限制完全依赖 PHP 的 memory_limit 配置，不是 Composer 自己维护的独立设置。
这意味着你查的其实是 PHP CLI 的运行时内存限制，而非 Composer 特有参数。
查看当前 PHP CLI 的 memory_limit 值
在命令行中执行以下命令，确认 Composer 实际能用多少内存：
php -r "echo ini_get('memory_limit').PHP_EOL;"
常见输出如：128M、-1（表示无限制）、512M。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
php -i | grep memory_limit也可用，但可能混入其他扩展信息，不如上一条精准 - 注意：必须用
php命令本身查，不是composer—— 因为 Composer 是 PHP 脚本，它继承的是 PHP CLI SAPI 的配置 - 如果系统有多个 PHP 版本，确保
which php指向你实际运行 Composer 时用的那个
为什么 composer install/update 仍报内存不足？
即使 memory_limit 设得很高，Composer 还可能因以下原因失败：
- Composer 自身在解析大型
composer.lock或递归依赖图时会大量使用内存，某些版本（如 2.2+）默认启用更激进的内存优化，但旧版本或特定插件可能绕过优化 - PHP 的
memory_limit是硬上限，一旦进程内 PHP 内存分配超限，直接报Allowed memory size of XXX bytes exhausted - Linux 系统级限制（如
ulimit -v）或容器内存 cgroup 限制可能比 PHP 设置更早触发 OOM - 某些共享主机或 CI 环境会强制重写
memory_limit，即使你本地改了php.ini，CI 中的php -i输出可能不同
临时提高内存限制的可靠写法
不要改全局 php.ini，用环境变量或命令前缀更安全：
php -d memory_limit=-1 /usr/bin/composer install
或简写（前提是 composer 是 Phar 可执行文件）：
php -d memory_limit=-1 composer install
-
-d memory_limit=-1表示禁用内存限制，仅用于调试或可信环境 - 避免写成
COMPOSER_MEMORY_LIMIT=-1 composer install—— 这个环境变量只对 Composer v1 有效，v2 已弃用，无效且易误导 - 若用 Docker，记得在
php:cli容器里也传-d memory_limit，光设环境变量没用
真正关键的永远是 PHP CLI 的 memory_limit，不是 Composer 的“设置”。很多人卡在这一步，反复查 composer config 却忽略 php -r 输出——那才是真实瓶颈所在。
