禁用插件可绕过因proc_open或pcntl_signal被禁用导致的初始化卡死，从而解决伪装成超时的实际阻塞问题；需通过composer diagnose --verbose和php -r验证，并优先使用--no-plugins临时验证，而非盲目调高timeout。
禁用插件不能直接解决超时，但能绕过因插件引发的卡死或子进程阻塞——尤其是当插件内部调用 proc_open 或 git clone 却被环境限制时。
为什么禁用插件可能“治好”超时
Composer 报 The process timed out 时，常不是网络慢，而是某个插件在初始化或执行阶段卡住：比如 hirak/prestissimo 尝试并行下载却因 proc_open 被禁用而挂起；或某插件在 post-install-cmd 中调用 pcntl_signal 失败后静默阻塞。这类问题不触发 HTTP 超时，http.timeout 和 process-timeout 都无效。
- 运行
composer diagnose --verbose，看末尾是否出现Plugin xxx is not compatible或根本没列出插件 - 检查 PHP 是否禁用了关键函数：
php -r "var_dump(function_exists('proc_open'));"输出false就是根因 - 插件兼容性错误（如声明
"composer-plugin-api": "^1.0"却用 Composer 2.x）会导致加载跳过，但部分插件会退化为同步阻塞行为，而非报错
禁用插件的三种实操方式
别只依赖 --no-plugins 一招，得匹配场景：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 临时验证：加
--no-plugins参数重试，如composer install --no-plugins。若成功，说明插件是瓶颈 - 生产部署（CI/CD）：必须写死，例如
composer install --no-plugins --no-scripts --prefer-dist。注意顺序：--no-plugins必须紧跟composer命令后，composer --no-plugins install是错的 - 全局禁用（不推荐）：设
COMPOSER_ALLOW_PLUGINS=0环境变量，它比命令行参数优先级更高，连composer global都受影响
禁用插件后仍超时？这些坑要避开
禁用插件只是移除干扰项，不代表问题终结。以下情况会继续失败：
- 项目里硬编码了
repositories指向私有 Git 仓库（如git@xxx），禁用插件后 Composer 改走默认git clone，但 SSH 配置缺失或超时未调 —— 此时该换--prefer-dist或补COMPOSER_SSH_COMMAND -
allow-plugins白名单配置在composer.json里写了"*": true，但实际没装任何插件，Composer 仍会扫描所有依赖的composer-plugin-api声明，增加解析耗时 - 禁用插件后，原本由插件加速的环节（如并行下载）退回串行，下载总时间变长 —— 这时必须同步调高
http-basic-timeout和换国内镜像，否则还是卡在Downloading
比禁用更稳的长期方案
禁用是应急，不是常态。真正减少超时概率得从源头收敛：
- 删掉不用的插件：
composer global remove hirak/prestissimo（v2 已原生支持并行，该插件已过时） - 白名单精准授权：
"allow-plugins": {"symfony/flex": true, "laravel/pint": true}，避免通配符和模糊匹配 - CI 脚本里永远显式带
--no-plugins，哪怕你认为没装插件 —— 某些基础镜像预装了全局插件，本地测试不超时，CI 里就突然卡住
最易被忽略的是：禁用插件后，如果项目依赖某个插件提供的自动注册能力（比如自动加载 config/ 下文件），就得手动补逻辑，否则运行时才暴露问题。
