直接运行php --ini查看loaded configuration file路径，确认cli模式下实际加载的php.ini位置，该路径即composer所用配置文件。
直接改 CLI 模式下的 php.ini 是最稳的长期解法，但必须确认路径、改对位置、重启终端——三者缺一不可；临时提内存优先用 php -d memory_limit=2G，别信 COMPOSER_MEMORY_LIMIT 能突破 PHP 底层限制。
怎么确认 Composer 正在用哪个 php.ini
Composer 运行时调用的是 CLI 模式的 PHP，和 Web 服务器（如 Nginx + PHP-FPM）完全隔离，共用同一份二进制但读取不同配置文件。不确认这点就改错地方，白忙活。
- 运行
php --ini，重点看Loaded Configuration File行输出的路径（比如/etc/php/8.2/cli/php.ini） - 如果输出是
none，说明 CLI 没加载任何php.ini，得手动创建或检查是否被PHP_INI_SCAN_DIR干扰 - 别只查
phpinfo()或 Web 环境下的php.ini路径——那跟 Composer 无关
memory_limit 改多少、怎么写才生效
单位大小写、数值格式、旧版兼容性都会导致改了也无效。尤其在 CI 或 Docker 中，一个字母错就卡死。
- 推荐写成
memory_limit = 2G：大写G兼容 PHP 7.2+ 所有版本；2048M在部分 PHP 7.0–7.1 上会解析失败 - 避免设为
-1：本地调试可接受，但 CI 或共享主机常会拦截该值，返回Allowed memory size exhausted依旧报错 - 别写
memory_limit = 2048（漏单位）：PHP 当成字节处理，等于 2KB，比默认还小 - 改完保存后，必须新开终端或运行
source ~/.zshrc（取决于你的 shell），否则php -r "echo ini_get('memory_limit');"仍显示旧值
为什么加了内存还是爆？这些操作本身更吃内存
单纯调高 memory_limit 只是兜底，有些命令或配置会让 Composer 主动“申请更多”，哪怕你给了 4G 也会撑爆。
-
composer update比composer install多消耗 3–5 倍内存：前者要重算整棵依赖树，后者只按composer.lock解压安装 -
"optimize-autoloader": true或composer dump-autoload -o会扫描全部 PHP 文件生成 classmap，vendor 超过 5000 个文件时极易触发 OOM -
autoload.files里引入了大工具库（比如整个functions.php）：每次 autoload 初始化都强制加载，内存一次性涨一大截 - CI 环境中未加
--no-dev：开发依赖（如phpunit、larastan）往往体积大、类多，且含大量插件扫描逻辑
Docker / GitHub Actions / 虚拟主机场景下不能改 php.ini 怎么办
容器镜像或托管平台通常锁死配置，此时必须绕过修改文件，靠运行时覆盖或流程精简。
- GitHub Actions：在
run步骤开头插入echo "memory_limit = 2G" >> $(php -r "echo php_ini_loaded_file();")，强制注入 - Docker：启动容器时加
-e PHP_INI_SCAN_DIR=/tmp，再挂载一个含memory_limit = 2G的.ini文件到/tmp - 虚拟主机（cPanel / Plesk）：在项目根目录放
.user.ini，写入memory_limit = 512M（部分支持，非全部） - 最保险的退路：本地跑通
composer install --no-dev -o，把vendor/和composer.lock整体上传，跳过远程执行
真正容易被忽略的是：即使 php -r "echo ini_get('memory_limit')" 返回了正确值，Composer 仍可能因插件（如 hirak/prestissimo）或自定义脚本提前耗尽内存——遇到这种情况，先试 composer install --no-plugins，再逐个排查。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
