Composer 的 config 字段仅在默认行为与本地环境/部署流程冲突时才需手动配置，如更换私有仓库源、禁用交互提示、调整超时参数（process-timeout 管单命令、timeout 管全程），且 fxp-asset 插件已废弃；修改前应先运行 composer config --list 查看实际生效值。
Composer 的 config 字段不是“教程型配置”，它只在特定场景下才需要手动干预，绝大多数项目根本不用写。
什么时候必须改 config？
只有当默认行为和你的本地环境/部署流程冲突时才动它。比如：
- 公司内网没有 packagist.org，得换私有仓库源（
repositories配合config的secure-http或http-basic） - CI 环境里
composer install卡在交互式提示（比如问你是否信任某个证书），要关掉interactive - 用 Docker 构建时想跳过
vendor/bin软链接（避免挂载问题），设bin-dir为绝对路径或禁用
process-timeout 和 timeout 到底该设哪个？
两个都控制超时，但作用对象不同：
-
process-timeout：只管单个外部命令（比如git clone、unzip）执行时间，单位秒，默认 300 -
timeout：管整个 Composer 进程生命周期（含网络请求+解压+脚本执行），单位秒，默认 300
常见错误是只调大 process-timeout，结果 composer update 在下载完后卡死——其实是 timeout 先到了。CI 中建议一起设：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
"config": {
"process-timeout": 1800,
"timeout": 1800
}
fxp-asset 类插件已废弃，别再配 asset-pattern
2019 年后 Composer 官方原生支持 Bower/NPM 包（通过 composer/installers + 自定义 type），fxp/composer-asset-plugin 早就停止维护。如果你还在 config 里写 asset-pattern 或 fxp-asset 相关字段：
- Composer 2.x 会直接报错：
Plugin installation failed, invalid plugin - 即使降级到 1.x，也会因 GitHub API 限流崩在
install阶段 - 正确替代方案：用
npm install或yarn管理前端依赖，PHP 后端只走 Packagist
真正难的是判断哪些 config 是历史残留、哪些是当前环境刚需。一个项目里混着旧 CI 脚本、新 Dockerfile、本地开发者的自定义设置，config 往往成了没人敢删的“黑盒”。动手前先 composer config --list 看实际生效值，比盲改 composer.json 安全得多。
