优先用 php -d memory_limit=2G 临时扩容，因 Composer 依赖解析时 I/O 拖累远超内存不足，2G 是 CI 验证的稳妥值且不污染环境；禁用 Swap，因其会加剧 I/O 卡顿。
Composer install 时提示 Allowed memory size exhausted 怎么办
直接调大 PHP 内存限制是最常见也最有效的解法，但不是所有场景都该加 —— 比如在 CI 环境里硬设 memory_limit=-1 可能掩盖依赖膨胀问题。
实操建议：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 临时生效（推荐先试）：
php -d memory_limit=2G /usr/bin/composer install - 永久修改需改 PHP 配置文件（CLI 模式独立于 Web）：找到
php.ini路径（运行php --ini查看），修改memory_limit值，注意区分php.ini和php-cli.ini - 某些共享主机或容器环境无法改全局配置，可用
COMPOSER_MEMORY_LIMIT=-1环境变量绕过 Composer 自带的内存保护（它默认限制 1.5G）
为什么 --no-dev 不能解决所有内存问题
--no-dev 确实跳过 require-dev 的解析和安装，但 Composer 的依赖求解（solver）阶段早在是否安装 dev 包之前就发生了——这个阶段要遍历所有可能的版本组合，内存峰值往往出现在这里。
所以即使你只装生产依赖，只要 composer.json 里存在冲突或过于宽松的约束（比如 "monolog/monolog": "^1.0 || ^2.0"），solver 仍会爆内存。
实操建议：
- 收紧版本约束：把
^1.0改成^1.25或锁定小版本（如1.25.5），减少 solver 探索空间 - 删掉不用的
require-dev条目，哪怕不装，它们仍参与依赖图构建 - 用
composer why-not vendor/package:version定位拖慢 solver 的包
vendor 目录重建慢？试试 --prefer-dist 和 --no-scripts
--prefer-dist 强制走 zip 包安装而非 git clone，对多数包能快 2–5 倍；--no-scripts 跳过 post-install-cmd 等钩子，避免执行耗时脚本（比如生成 autoload、清缓存）。
但要注意：
-
--prefer-dist失败时 Composer 会自动 fallback 到--prefer-source，无需手动干预 -
--no-scripts后得自己补一句composer dump-autoload，否则类加载可能出错 - CI 场景下建议组合使用：
composer install --no-dev --prefer-dist --no-scripts
PHP 8.1+ 用户别忽略 opcache.preload
Composer 2.2+ 在 PHP 8.1+ 上启用 opcache.preload 后，autoload 生成和加载速度有明显提升，尤其在大型项目中。但这不是默认开启的，且 preload 文件必须提前编译好。
关键点：
- preload 文件由 Composer 自动生成在
vendor/composer/preload.php - 需在
php.ini中显式配置：opcache.preload=/path/to/vendor/composer/preload.php - 每次
composer install或update后，preload.php 会更新，但 PHP 不会自动重载 —— 必须重启 PHP-FPM 或 CLI 进程才生效
preload 对内存占用影响不大，但能显著降低后续请求的 autoload 开销；如果项目已上 PHP 8.1+，漏掉这步等于白跑新版本。
