不会自动残留错误配置，但手动执行的 composer config 命令会持久化写入项目或全局 config 文件；还原需用 --unset 删除 repo.packagist 配置项，并视情况清理缓存。
切换 Composer 镜像失败后，composer config 会残留错误配置吗？
不会自动残留，但手动执行的 composer config -g repo.packagist 或 composer config repo.packagist 命令一旦写入，就会生效——哪怕后续 composer update 报错，配置本身仍留在 composer.json（项目级）或 auth.json 同级的全局 config（~/.composer/config.json）。这是还原的第一前提：错误镜像不是“临时失效”，而是“已持久化”。
如何安全还原为官方源（Packagist.org）？
还原本质是删掉被手动覆盖的 repo.packagist 配置项。关键看配置写在哪：
- 如果用
composer config -g repo.packagist https://packagist.org设置过全局源，运行：composer config -g --unset repo.packagist
- 如果在项目目录下执行了
composer config repo.packagist https://mirrors.aliyun.com/composer/，则进项目根目录，运行：composer config --unset repo.packagist
（不加-g） - 如果手抖直接编辑过
composer.json，删掉里面的"repositories"字段（或其中 type=“composer” 且 url 指向镜像的条目）即可
composer diagnose 能否发现镜像配置异常？
能，但仅限连通性层面。它不会警告“你配了个不存在的镜像”，只会报类似：
[FAIL] The configured repository (https://mirrors.example.com/composer/) is not accessible.此时别急着换源，先确认是否真被墙、DNS 是否污染、或镜像站已下线。阿里云、腾讯云、华为云镜像都稳定，但某些小众镜像（如早期的 phpcomposer.com）已停服，切过去就卡死。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
更可靠的自查方式是：
composer config repo.packagist——有输出说明已被覆盖；无输出说明当前走默认源。
为什么有时还原后 composer update 还很慢？
因为 Composer 会缓存元数据（~/.composer/cache/repo/https---packagist.org/），如果之前用镜像拉过包，缓存里可能混着旧的 packages.json 签名或压缩包地址。这时要清缓存：
composer clear-cache。注意：这不是万能操作，频繁清缓存反而拖慢后续安装；只在确认源已还原且网络正常但速度仍异常时才用。
另外，某些公司内网会劫持 HTTPS 请求并替换证书，导致 Composer 校验失败——这种问题跟镜像无关，得找 IT 部门配信任证书，或者临时加 --no-secure-http（不推荐长期用）。
