必须将php -d memory_limit置于命令最前面，因Composer内存上限由PHP启动时决定且不可更改；正确写法为php -d memory_limit=-1 composer install，单位G须大写，配合--no-dev、--optimize-autoloader和--classmap-authoritative可显著降低内存峰值。
php -d memory_limit必须写在命令最前面
Composer 是 PHP 进程，它的内存上限由 PHP 启动时的 memory_limit 决定，进程一旦启动，该值就锁死。任何把 -d memory_limit 放在 composer install 后面的写法都无效。
常见错误写法：
-
composer install -d memory_limit=-1（被当成子命令，忽略） -
COMPOSER_MEMORY_LIMIT=-1 composer install（PHP 进程早被 128M 卡死，根本没机会读这个变量）
正确写法：
- Linux/macOS：
php -d memory_limit=-1 composer install - PowerShell：
php -d "memory_limit=-1" composer install（双引号不能省，否则-1被当参数丢弃） - 用
composer.phar：php -d memory_limit=2G ./composer.phar install
单位必须大写 G，小写 g 会被 PHP 忽略
PHP 对内存单位大小写敏感：2G 有效，2g 等同于未设置，仍走默认 128M。这是 Windows PowerShell 和 Linux 下都复现过的坑。
立即学习“PHP免费学习笔记（深入）”；
推荐值：
- 本地开发紧急修复：
-1（无限制） - CI/CD 或 Docker 环境：
2G（足够跑完 Laravel/ThinkPHP 全量依赖，又避开 cgroup 误杀） - 共享主机受限环境：
1536M（比 1G 更稳妥，避免某些旧版 PHP 对 1G 解析异常）
--no-dev 和 --optimize-autoloader 不是“锦上添花”，是降内存峰值的关键开关
光提 PHP 内存只是拖延时间。真正让 Composer 在 512MB VPS 上活下来的，是跳过不必要的解析和 autoload 构建。
这三个参数必须一起用：
-
--no-dev：不解析require-dev包（如phpunit、phpstan），省掉 40%～60% 内存峰值 -
--optimize-autoloader（或-o）：生成 classmap，跳过 PSR-4 目录扫描，dump-autoload 阶段内存直降 70% -
--classmap-authoritative（或-a）：上线部署必加，告诉 autoloader “类不在 map 里 = 不存在”，不再 fallback 查找
漏一个，Resolving dependencies 阶段就可能多扛 300MB+。
别碰 php.ini，也别信 COMPOSER_MEMORY_LIMIT 能绕过 PHP 限制
COMPOSER_MEMORY_LIMIT 只控制 Composer 自身逻辑（比如回溯步数），它不改 PHP 底层 malloc 行为。设成 -1 不能让你在 1GB 物理内存机器上跑通 TP6 全量安装。
验证当前 CLI 使用的配置：
- 运行
php --ini看Loaded Configuration File路径 - 确认不是 Apache 或 FPM 的 php.ini —— 它们和 CLI 完全无关
真正要改的是命令行参数，不是配置文件。临时、精准、可审计，这才是线上操作该有的样子。
