最可靠方法是运行php --ini或phpinfo()确认实际加载的php.ini路径；Loaded Configuration File行显示生效文件，若为none则用内置默认值，且CLI与Web可能使用不同配置文件。
直接改 php.ini 不一定生效，真正起作用的是 CLI 模式下 PHP 启动时读取的配置文件路径——必须确认 php --ini 输出的 Loaded Configuration File 才算对。
为什么 php -d memory_limit=-1 有时也不管用
常见错误现象：明明加了 -d 参数，还是报 Allowed memory size exhausted。根本原因不是参数没传进去，而是你调用的 php 命令和你以为的不是同一个。
- 运行
which php和php -v，确认当前 shell 使用的是哪个 PHP 二进制文件 - 某些系统（如 macOS Homebrew 或 phpbrew）会 alias
php，导致php -d实际作用在旧版本上 - Docker 容器里默认可能没有 CLI 配置文件，
php --ini显示Loaded Configuration File: (none)，此时-d是唯一可靠方式 - PowerShell 用户必须写成
php "-d" "memory_limit=-1"，否则会被当成 PowerShell 参数丢弃
COMPOSER_MEMORY_LIMIT 环境变量到底有没有用
它只控制 Composer 自身逻辑层的内存预分配行为，比如依赖解析前预留多少空间；但一旦底层 PHP 进程因 memory_limit=128M 中断，这个变量根本没机会执行。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
COMPOSER_MEMORY_LIMIT=-1对composer update有一定缓解作用，对install几乎无效 - CI 环境中建议优先用
php -d memory_limit=2G composer install，而不是依赖环境变量 - Windows CMD 下设环境变量要分两步：
set COMPOSER_MEMORY_LIMIT=-1 && composer install - 值设为
1536M比-1更稳妥，能暴露真实内存泄漏点，避免掩盖 autoload 或插件问题
哪些操作真正吃内存，光加内存也救不了
composer install 报错不等于“只是内存小”，有些场景是设计或配置问题，硬提内存只会延缓失败时间。
立即学习“PHP免费学习笔记（深入）”；
-
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');" 验证输出值，而不是只信编辑动作本身。
