Composer 运行时无调度能力，“调度峰值”实为本地 PHP 进程在依赖解析、下载、autoload 生成时资源耗尽；需调高 PHP 内存限制、降并发、禁用非必要功能、优化 autoload 并避免滥用 update。
Composer 本身不提供运行时调度能力，所谓“调度峰值”实际是并发安装、高频 CI 触发、或依赖解析阶段的 CPU/内存/I/O 爆发——它不是服务端被压垮，而是本地 PHP 进程在解析约束、下载包、生成 autoload 时吃光资源。
composer install/update 在 CI 中频繁触发导致 OOM
GitHub Actions 或 GitLab CI 默认 memory_limit=128M，但 Composer 解析一个含 300+ 包、composer.lock 超 8MB 的项目，仅 json_decode() + 构建依赖图就可能突破 512M。设 COMPOSER_MEMORY_LIMIT=2G 没用，PHP 底层限制不解除，进程照样被 kill。
- 必须前置指定 PHP 内存：用
php -d memory_limit=1.5G composer install（别用-1） - 搭配
--no-dev --no-plugins --no-scripts -o，跳过所有非必要逻辑和 autoload 动态查找 - 确保
composer.lock已提交且未被 CI 缓存污染——否则install会悄悄退化为update - Docker 场景下额外检查容器内存配额：
docker run --memory=4g，否则 OOM killer 直接干掉进程
并发下载引发网络与磁盘 I/O 饱和
Composer 默认启用 12 并发下载（HttpDownloader::$maxJobs = 12），在带宽受限或磁盘慢的 CI 环境中，这反而造成请求排队、TCP 重传、写入延迟飙升，整体耗时翻倍。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 用
COMPOSER_PROCESS_TIMEOUT=600延长单任务超时，避免因慢速包中断整个流程 - 降并发：通过环境变量
COMPOSER_HTTP_MAX_PARALLEL=4限制并行数（Composer 2.2+ 支持） - 禁用进度条：
--no-progress减少日志刷屏带来的 I/O 压力，CI 中实测省几百毫秒 - 避免使用已废弃插件（如
hirak/prestissimo），它们会干扰原生并发逻辑，引发连接复用失败
autoload 生成阶段卡在 classmap 扫描
composer dump-autoload --optimize 在大型 vendor 目录里遍历 PSR-4 路径，可能触发数万次 file_exists() 和 is_dir()，CPU 占满且无响应，看起来像“卡死”。
- 生产环境直接用
--classmap-authoritative，跳过所有 fallback 查找，只认 classmap 表 - 把稳定第三方库（如
monolog/monolog）的源码路径显式加入"classmap"，缩小扫描范围 - CI 中不要跑
dump-autoload，而是在构建镜像时用RUN composer install --optimize-autoloader一步到位 - 若项目含动态类名拼接（如
new $className），禁用--classmap-authoritative，否则运行时报Class not found
真正危险的不是“峰值”，而是把 composer update 当日常操作——它强制重算 SAT、下载全部元数据、校验所有哈希，是内存和网络的三重暴击。稳定项目应只改 composer.json 后跑 composer update vendor/package，而非全量更新。
