根本原因是调用的php命令与预期版本不一致，如Homebrew、phpbrew或alias导致配置修改失效；PowerShell需加引号，Docker中若php --ini显示无配置文件则-d是唯一可靠方式。
php -d memory_limit 参数为什么加了还是报错
根本原因不是参数没传进去，而是你调用的 php 命令和你以为的不是同一个。运行 which php 和 php -v，确认当前 shell 用的是哪个二进制文件——Homebrew、phpbrew 或 alias 都可能导致你改了 A 版本的配置，却在 B 版本下执行命令。
PowerShell 用户必须写成 php "-d" "memory_limit=-1"，否则 -d 被当成 PowerShell 参数丢弃；Docker 容器里若 php --ini 显示 Loaded Configuration File: (none)，那 -d 就是唯一可靠方式。
常见错误现象：php -d memory_limit=-1 composer install 仍报 Allowed memory size exhausted，说明这个 php 进程压根没加载到你预期的配置上下文。
怎么确认 Composer 真正在用哪个 php.ini
Composer 运行时走的是 CLI 模式 PHP，和 Web 服务器（Nginx + PHP-FPM）完全隔离。别查 phpinfo() 页面里的路径——那跟 Composer 无关。
执行 php --ini，重点看 Loaded Configuration File 行输出的路径，比如 /etc/php/8.2/cli/php.ini。如果显示 (none)，说明 CLI 没加载任何配置文件，得手动创建或检查 PHP_INI_SCAN_DIR 是否干扰。
改完配置后必须新开终端，或运行 source ~/.zshrc（取决于你的 shell），否则 php -r "echo ini_get('memory_limit');" 仍返回旧值。
COMPOSER_MEMORY_LIMIT 环境变量到底管不管用
它只控制 Composer 自身逻辑层的内存预分配行为，比如依赖解析前预留多少空间；但一旦底层 PHP 进程因 memory_limit=128M 中断，这个变量根本没机会执行。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
COMPOSER_MEMORY_LIMIT=-1 对 composer update 有一定缓解作用，对 composer install 几乎无效。
Windows CMD 下设环境变量要分两步：set COMPOSER_MEMORY_LIMIT=-1 && composer install；CI 环境中建议优先用 php -d memory_limit=2G composer install，而不是依赖环境变量。
哪些操作真正吃内存，光加内存也救不了
composer update 比 install 多出整棵依赖树重计算，是内存杀手；生产环境应禁用 update，只跑 install。
composer create-project 卡在 Loading composer repositories 阶段，说明元数据缓存损坏，先 composer clear-cache；vendor/autoload.php 生成失败，可能是 PSR-4 映射范围太宽（例如 "" : "src/" 包含了测试资源或大文件），手动缩小扫描路径。
composer.lock 文件超过 5MB，大概率含大量 dev-master 提交哈希或冗余 package-versions，需清理 require-dev 或降级稳定性。
最常被忽略的一点：php.ini 里改了 memory_limit，但没确认是否真被 CLI 模式加载——每次修改后必须运行 php -r "echo ini_get('memory_limit');" 验证。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
