答案是php -d memory_limit必须写在命令最前面，因为Composer作为PHP进程，其内存上限由PHP启动时memory_limit决定，进程启动后该值即锁定；错误写法如composer install -d memory_limit=-1或COMPOSER_MEMORY_LIMIT=-1 composer install均无效，正确写法为php -d memory_limit=-1 composer install（Linux/macOS）或php -d "memory_limit=-1" composer install（PowerShell），且composer.phar调用时顺序不可变。
php -d memory_limit 必须写在最前面
Composer 是一个 PHP 进程，它的内存上限完全由 PHP 启动时的 memory_limit 决定。一旦进程启动，这个值就锁死了。php -d memory_limit=-1 必须放在命令最左侧，否则无效。
常见错误写法：composer install -d memory_limit=-1（参数被当成 Composer 子命令）、COMPOSER_MEMORY_LIMIT=-1 composer install（PHP 进程早被 128M 卡死，根本没机会执行到 Composer 的环境变量读取逻辑）。
- Linux/macOS 正确写法：
php -d memory_limit=-1 composer install - PowerShell 必须加引号：
php -d "memory_limit=-1" composer install - 用了
composer.phar？顺序不变：php -d memory_limit=2G ./composer.phar update - 单位必须大写：
2G有效，2g被 PHP 忽略
--no-dev 和 --optimize-autoloader 能真·降内存峰值
composer install 卡在 Resolving dependencies，往往不是因为要装的包多，而是 require-dev 里的包（比如 phpunit、phpstan、laravel/pint）被全量解析——这部分常占内存 40%~60%。
--optimize-autoloader（或简写 -o）会生成扁平 classmap，跳过 PSR-4/PSR-0 动态扫描，显著降低 dump-autoload 阶段内存压力。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 上线部署必加：
php -d memory_limit=1.5G composer install --no-dev -o - CI 流水线推荐组合：
--no-dev --classmap-authoritative --optimize-autoloader - 如果项目 autoload.files 里引入了大体积 helper 文件，删掉或拆分，否则
-o也救不了
COMPOSER_MEMORY_LIMIT 不是“加大内存”，而是软限开关
COMPOSER_MEMORY_LIMIT 是 Composer 自己识别的变量，它不改变 PHP 底层 malloc 行为，只控制内部可中断逻辑（如依赖回溯步数、插件循环次数）。设成 -1 并不能绕过 memory_limit，但设成具体值（比如 1536M）能防止某个坏包触发缓慢内存爬升后失控。
- CI 中建议用具体值而非
-1：php -d memory_limit=2G COMPOSER_MEMORY_LIMIT=1536M composer install - PowerShell 设置语法：
$env:COMPOSER_MEMORY_LIMIT="1536M"（等号前后不能有空格） - 它优先级低于
php -d，高于php.ini，适合做“二次防护”
composer.lock 大小超过 5MB 就该警惕
composer install 理论上比 update 轻，但现实常相反——因为 composer.lock 文件本身过大（含大量 dev-master 提交哈希、嵌套 package-versions、废弃包残留），解析它比重算依赖图还吃内存。
检查方法：ls -lh composer.lock（Linux/macOS）或 dir composer.lock（Windows），超过 5MB 就得处理。
- 临时缓解：
composer install --no-dev常能立刻见效 - 长期清理：删掉
require-dev中不用的包，避免"minimum-stability": "dev"泄漏进 lock 文件 - 慎用操作：删
vendor/+ 删composer.lock后直接composer update—— 这是最烧内存的组合
Allowed memory size of ... bytes exhausted）出现时，问题往往不在代码层，而在 Composer 解析元数据的瞬间——此时连 autoloader 都还没加载，更别说业务逻辑了。调参只是表象，看清 Resolving dependencies 阶段到底在加载什么，才决定要不要砍 dev、换 lock、还是换 PHP 版本。 
