直接改php.ini通常无效，因composer走php cli模式，需用php --ini确认loaded configuration file路径；若显示(none)，说明cli未加载ini文件，改其他配置无效。
直接改 php.ini 中的 memory_limit 通常无效——因为你大概率改错了文件。Composer 走的是 PHP CLI 模式，而你手抖点开的可能是 Apache 或 php-fpm 的配置。
怎么确认 Composer 真正读的是哪个 php.ini
运行这条命令：
php --ini
重点看 Loaded Configuration File 这一行。如果显示 (none) 或路径为空，说明 CLI 根本没加载任何 php.ini，此时用的是编译默认值（常为 128M），改其他地方全白搭。
- 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/下的某个.ini文件 - Windows XAMPP：
C:\xampp\php\php.ini（但需确认php --ini输出是否指向它）
改完 php.ini 为什么还是报错 Allowed memory size exhausted
常见原因不是没改，而是改得不彻底或被覆盖：
-
memory_limit值写成了2048M或2G—— PHP 只认大写单位，2g会被忽略，2048M在某些旧版本里解析失败，统一用2G最稳 - 同一台机器装了多个 PHP 版本，
which php和php -v显示的版本，和composer实际调用的不一致（比如composer是 symlink 到 /usr/bin/php7.4） - 系统级限制生效：
ulimit -v（虚拟内存）过低，尤其在 CI 容器中，默认可能只有 512MB，PHP 再怎么设-1也突破不了这个墙 - Xdebug 已启用：它会让 Composer 内存占用翻倍，临时禁用更有效：
php -d extension= -d memory_limit=-1 composer install
为什么加了 -d memory_limit=-1 还爆内存
现象：执行 php -d memory_limit=-1 composer install 仍失败。核心问题往往不在 PHP 层：
-
which composer返回/usr/bin/composer？那是 shell wrapper 脚本，-d参数根本传不进 PHP，必须用php -d memory_limit=-1 /path/to/composer.phar install - Composer 自身求解器主动中止：当依赖组合数超 5000，新版 Composer 会直接退出，加内存无用，必须换策略（如先删
vendor/和composer.lock，再用--with-dependencies分批装） -
composer.lock文件过大（>5MB）：含大量 dev 包哈希、完整 autoload 映射，解析时全载入内存；可先用composer install --no-dev --prefer-dist绕开 - 插件干扰：旧版
hirak/prestissimo或自定义插件反复扫描vendor/目录，加--no-plugins立竿见影
CI/CD 里怎么安全设内存限制
不能改宿主机 php.ini，也不能依赖环境变量（COMPOSER_MEMORY_LIMIT 不控制底层 PHP 限额），唯一可靠方式是显式调用：
php -d memory_limit=2G $(which composer) install --no-interaction --no-progress --no-dev --prefer-dist
这组参数不是“锦上添花”，而是防止隐式触发 update 的安全底线：
-
--no-interaction避免卡在交互提示 -
--no-progress关掉进度条，减少终端 I/O 压力 -
--no-dev跳过所有开发依赖，省下几百 MB 内存 -
--prefer-dist强制下载压缩包而非源码，解压阶段更轻量
真正容易被忽略的点是：哪怕你把 memory_limit 设成 -1，只要 composer.lock 里混着一堆 dev-master 或未收敛的约束，Composer 仍会在解析阶段反复回溯、爆炸式生成组合——这时候调内存只是延缓崩溃，不是解决问题。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
