根本原因是PHP CLI模式内存限制过小，需修改CLI专用php.ini中的memory_limit并开启opcache.enable_cli=1，而非Web服务器的配置。
Composer 报错 Allowed memory size of X bytes exhausted 的根本原因不是内存真不够，而是 PHP 默认给 CLI 进程分配的内存太小——尤其在安装依赖多、autoload 生成复杂或使用 composer update 时极易触发。
为什么 php.ini 里改了 memory_limit 还没用？
CLI 模式和 Web 模式使用的是两套 php.ini 配置。你改的很可能是 Apache 或 Nginx 下的 php.ini（路径类似 /etc/php/8.1/apache2/php.ini），而 Composer 运行在终端，走的是 CLI 的配置（如 /etc/php/8.1/cli/php.ini）。
- 运行
php --ini查看 CLI 加载的配置文件路径 - 确认修改的是
Loaded Configuration File对应的那个php.ini - 重点改
memory_limit行，比如设为memory_limit = 2G（不要写-1，某些环境不认） - 改完不用重启任何服务，但需确保没被命令行参数覆盖（见下一条）
临时绕过限制：用 -d 参数强制指定内存
这是最快速生效的方法，适合 CI 环境或不想动系统配置的场景。它会覆盖 php.ini 中的设置：
php -d memory_limit=2G /usr/bin/composer install
注意几点：
-
-d memory_limit=2G必须写在php命令后、composer脚本前 - 如果用的是
composer全局命令（即 shell alias 或软链），要先查清它实际调用路径：which composer；常见情况是它本身是个 shell 脚本，此时得改脚本里调用php的那行，或者直接用上面这种显式调用方式 - 单位支持
M、G，不支持MB或GB
Composer 自身优化：跳过 autoload 重生成与禁用插件
真正耗内存的操作集中在 autoload 文件生成（尤其是 classmap 扫描）和插件执行。可在不影响功能的前提下临时规避：
- 加
--no-autoloader参数跳过 autoload 生成：composer install --no-autoloader，之后手动运行composer dump-autoload（可配合--optimize或--classmap-authoritative减少后续开销） - 加
--no-plugins禁用所有插件，有些插件（如hirak/prestissimo旧版、自定义脚本类插件）会在 install/update 时做额外扫描 - 如果只是更新单个包，避免用
composer update全量刷新，改用composer update vendor/package-name
别忽略 opcache.enable_cli=1 这个隐藏加速项
PHP 7.0+ CLI 模式默认关闭 opcache，但 Composer 是大量重复加载 PHP 文件的典型场景。开启后能显著降低内存峰值（实测可降 30%～50%）：
- 编辑 CLI 的
php.ini，加入或取消注释：opcache.enable_cli=1 - 同时建议配一组合理值（无需调优，直接用下面这组）：
opcache.enable_cli=1 opcache.memory_consumption=256 opcache.max_accelerated_files=20000 opcache.validate_timestamps=0
注意：validate_timestamps=0 在开发环境慎用（会导致改了代码不生效），但 CI 或部署脚本中完全安全——因为每次都是全新环境。
真正卡住人的，往往不是该设多大内存，而是没意识到 CLI 和 Web 的 php.ini 是分开的，或者忘了 opcache 这个对 Composer 友好的默认关闭项。
