项目级config会完全覆盖全局同名配置，不是合并而是替换；例如全局设bin-dir为~/.local/bin，项目中设bin-dir为bin，则全局值失效，vendor/bin脚本不生成。
项目级 config 会完全覆盖全局同名配置，不是合并，是替换——想靠“局部加一点、全局兜底”来简化多环境配置，这条路走不通。
为什么 composer.json 里的 config 一写就失效全局设置
Composer 的配置模型非常明确：项目根目录的 composer.json 中的 "config" 字段，对任何同名键（如 bin-dir、cache-dir、process-timeout）都是整块覆盖。比如全局设了 "bin-dir": "~/.local/bin"，但项目里写了 "bin-dir": "bin"，那 vendor/bin 就不会生成脚本——它压根不读全局值。
常见错误现象：
- 执行
composer dump-autoload后vendor/bin下没脚本，但确认composer.json有"bin"声明 → 很可能是bin-dir被项目config错误覆盖 - CI 环境中
process-timeout不生效 → 全局设了600，但项目composer.json没删掉默认的"process-timeout": 300 - 改了全局
cache-dir，某些项目仍往~/.composer/cache写 → 因为那些项目composer.json显式写了"cache-dir"，直接屏蔽了全局
repositories 顺序才是真正的“优先级开关”
和 config 不同，repositories 数组的顺序直接影响行为：Composer 从上到下逐个尝试匹配包名，第一个返回有效元数据的仓库就中止搜索。这个机制才是多环境“分流”的可靠基础。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
实操建议：
- 私有包必须放在
repositories数组最前面，否则会被 packagist 镜像“截胡” - 禁用官方源要显式设
"packagist": false，否则即使你把镜像放第一，Composer 还是会 fallback 到 packagist.org - 全局只配镜像源：
composer config --global repos.packagist https://mirrors.aliyun.com/composer/；项目级加私仓：composer config repositories.my-private '{"type":"composer","url":"https://pkg.internal"}'，再确保数组里私仓在前、镜像在后 - 不要在全局
config.json里写repositories数组——它会被项目composer.json完全替换，起不到“兜底”作用
如何让 CI 或临时环境绕过项目 config 又不破坏逻辑
某些 CI 场景需要强制使用全局 bin-dir 或统一 cache-dir，但又不能改项目 composer.json。这时候不能靠删配置或手改 JSON，得用环境变量控制加载路径。
安全做法：
- 用
COMPOSER=/dev/null composer install可跳过所有项目配置，但也会丢掉autoload和scripts——仅适合调试config本身 - 更稳妥的是建一个最小化配置文件
ci-composer.json，内容只保留：{"config": {"bin-dir": "~/.local/bin", "cache-dir": "/tmp/composer-cache"}}，然后运行COMPOSER=ci-composer.json composer install - 绝对不要用
composer config --unset删除项目config段：Git 提交历史和协作成员都会受影响，且下次composer update可能自动重写回来
真正容易被忽略的点是：Composer 对 JSON 格式零容忍，手改全局 config.json 时多一个逗号，所有后续命令都会报 file_get_contents(): Failed to open stream；而 repositories 的顺序影响是静默的——包装上了但版本不对，问题要等运行时才暴露。
