直接改 php.ini 里的 memory_limit 多数时候无效，因为你改的很可能不是 Composer 实际用的那个配置文件——它走的是 CLI 模式，而你手抖改了 Apache 或 FPM 的 php.ini。真要调，得先确认路径、再动对地方，否则白改。
怎么确认 Composer 正在用哪个 php.ini？
运行 php --ini，重点看 Loaded Configuration File 这一行。如果显示 (none) 或空值，说明 CLI 根本没加载任何 php.ini，此时 memory_limit 是编译默认值（通常是 128M）。常见 CLI 配置路径有：
- Ubuntu/Debian：
/etc/php/8.2/cli/php.ini - macOS Homebrew：
/usr/local/etc/php/8.2/php.ini - Docker 官方镜像：
/usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini类路径下
改完保存后，当前终端会话不会自动重载，需新开终端或执行 source ~/.zshrc（或对应 shell 配置）才能让新设置生效。
php -d memory_limit=-1 为什么必须放最前面？
Composer 是一个 Phar 包，由 PHP CLI 进程加载执行。它的内存天花板在 PHP 进程启动那一瞬间就锁死了，memory_limit 值从此不可更改。-d 参数必须在初始化阶段注入，晚一毫秒都不行。
- ✅ 正确：
php -d memory_limit=-1 composer install - ❌ 错误：
composer install -d memory_limit=-1（参数位置错，PHP 根本不认） - ⚠️ PowerShell 用户必须加引号：
php -d "memory_limit=-1" composer install，否则-1被 shell 截断 - ? 如果用的是
composer.phar，写法不变：php -d memory_limit=-1 ./composer.phar update
COMPOSER_MEMORY_LIMIT 环境变量到底管不管用？
它有用，但作用非常窄：只影响 Composer 自身某些可中断逻辑（比如依赖回溯步数），**完全无法突破 PHP 底层的 memory_limit 限制**。
- 即使设了
COMPOSER_MEMORY_LIMIT=-1，只要 PHP 进程本身memory_limit=128M，照样报Allowed memory size of 134217728 bytes exhausted - 优先级低于
php -d，两者共存时以后者为准 - 适合做“二次防护”：CI 中可设
COMPOSER_MEMORY_LIMIT=1536M配合php -d memory_limit=2G，更可控
哪些参数能真正减内存，而不是硬扛？
光提内存是治标。很多项目爆内存，是因为在跑根本不需要的操作。
-
--no-dev：跳过require-dev解析和安装，内存常降 40%~60%，上线部署必加 -
--optimize-autoloader（或-o）：生成扁平 classmap，避免运行时动态扫描，压低 dump 阶段峰值 -
--classmap-authoritative：配合-o使用，禁止 fallback 到 PSR-4 扫描，进一步减内存 -
--no-plugins：禁用钩子型插件（如composer-unused），它们会在每个包安装后触发，放大串行延迟 -
--prefer-dist：强制走 zip 包而非 git clone，避免 git 进程吃内存（默认已开启，但显式写上更明确）
CI/CD 中推荐固定组合：php -d memory_limit=2G composer install --no-dev --optimize-autoloader --classmap-authoritative。别只加 --no-dev 却漏掉 -o，autoload 生成仍可能爆内存。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
