Composer内存不足主因是PHP默认memory_limit过低，应使用php -d memory_limit=-1或2G临时提升；update比install更耗内存因需SAT求解，推荐优先install并配合--no-dev、--no-plugins等优化。
composer 没有“动画导出”功能，也不会在渲染或导出时报内存不足——你看到的错误一定是 composer install 或 composer update 过程中触发了 PHP 的内存限制。所谓“动画导出”是误读，真实场景只有依赖解析、包下载、自动加载映射生成这三类高内存操作。
为什么 composer update 容易卡在“内存耗尽”而不是 install
因为 update 要跑 SAT 求解器，在本地尝试成百上千种版本组合来满足约束条件，所有计算都在单个 PHP 进程里完成，内存占用呈指数增长；而 install 只是按 composer.lock 精确还原，开销小得多。
- 别在 CI/CD 或部署脚本里无脑写
composer update，优先用composer install - 真要升级，缩小范围：
composer update monolog/monolog guzzlehttp/guzzle - 加
--no-plugins关掉旧插件（比如已废弃的hirak/prestissimo），某些插件会在解析前预加载全部类 - 确认关掉 Xdebug：
php -d zend_extension= -d xdebug.mode=off composer update，它会让内存翻倍
php -d memory_limit=-1 为什么有时不生效
根本不是参数写错了，而是你调用的 composer 命令压根没走 PHP 解释器——比如通过 sudo apt install composer 安装的，实际是 shell wrapper（路径通常是 /usr/bin/composer），它内部直接调用二进制，-d 参数被完全忽略。
- 先查真实路径：
which composer，输出/usr/bin/composer就是 wrapper - 安全做法：绕过 wrapper，直接用
php -d memory_limit=2G /path/to/composer.phar install - Windows PowerShell 中
-1必须加引号：php -d "memory_limit=-1" composer install，否则被当命令行选项解析 - Docker 或 GitHub Actions 里，
COMPOSER_MEMORY_LIMIT=2G composer install不够——它只影响 Composer 自身逻辑，不绕过 PHP 底层限制；必须显式调用php -d memory_limit=2G composer install
vendor/autoload.php 生成失败也报内存不足？
这不是 autoload 本身的问题，而是 dump-autoload 阶段被迫扫描了不该扫的文件：比如项目根目录下混进了 logs/、storage/app/，或 composer.json 的 autoload 配置错误地包含了 node_modules/、dist/ 等非 PHP 目录。
- 运行
composer dump-autoload --no-scripts单独测试，排除脚本干扰 - 检查
composer.json里autoload和autoload-dev字段，删掉任何指向大体积非代码目录的配置 - 清理缓存：
composer clear-cache，尤其在部署机上残留的旧包可能带巨型 JSON 元数据 - 升级到 Composer 2.5+，它的 autoloader 构建算法更保守，对冗余文件容忍度更高
真正卡住的地方，往往不在“设多大内存”，而在于你是否意识到：CLI PHP 和 Web PHP 的 php.ini 是两套配置，COMPOSER_MEMORY_LIMIT 只是 Composer 内部开关，不能突破 PHP 进程本身的 memory_limit 底线。
