镜像源不支持降级，仅支持切换；所谓“镜像降级”实为故障时临时切至备用源，并需清 repo 元数据缓存（rm -rf ~/.composer/cache/repo/...）、探活验证、优先用项目级配置覆盖全局，且 Composer 自身降级与镜像切换相互独立。
镜像源本身不支持“降级”，只支持切换
Composer 的 repositories 配置不是故障转移列表，更不是版本回退通道。它不会因为你装了旧版包就自动切到旧版镜像——镜像站只提供元数据快照（packages.json），不按 Composer 版本分发不同内容。所谓“镜像降级”，本质是：当主镜像（如阿里云）同步滞后或返回错误时，临时切换到另一个可用源（如腾讯云或官方源），并确保缓存不干扰新决策。
常见错误现象：composer install 卡在 Downloading https://mirrors.aliyun.com/... 且超时，但你改了 composer.json 中的 repositories 顺序后仍连旧地址——这是因为 Composer 已缓存了该镜像的 packages.json，根本没读新配置。
- 必须手动清理对应 provider 缓存目录：
rm -rf ~/.composer/cache/repo/https---mirrors.aliyun.com-composer -
composer clear-cache不管用：它只清dist包缓存，不删repo元数据缓存 - 切换前务必用
curl -I -s -o /dev/null -w "%{http_code}" https://mirrors.aliyun.com/composer/packages.json探活，只认200，502、timeout、403都算不可用
项目级镜像切换比全局配置更安全
全局配置（~/.composer/config.json）容易被项目级 composer.json 中的 repositories 字段覆盖，导致你以为切了源，实际还是走老路。真要容灾，优先写进项目配置，且避免硬编码 false 或空数组。
使用场景：CI 构建、多环境部署、团队协作项目中需保证镜像策略一致。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 写入项目级配置：
composer config repositories.packagist url https://packagist.org - 禁用 packagist（慎用）：
composer config repositories.packagist false—— 注意键名是repositories.packagist，不是repo.packagist - 删除项目级镜像配置：
composer config --unset repositories，而不是删整个composer.json - 验证是否生效：
composer config repositories应输出实际配置，composer diagnose的 “Repo:” 行应显示目标 URL
Composer 自身降级和镜像切换是两件事
很多人混淆“Composer 工具降级”和“镜像源切换”。前者影响依赖解析逻辑（比如从 v2.9.6 降到 v2.2.22），后者只影响元数据获取路径。两者独立，但共用同一套网络栈，所以网络问题常被误判为镜像问题。
性能与兼容性影响：v2.2.x 不支持 config.platform.php 的 ^8.1 写法，会报错；v2.9.6 默认启用并行下载，对镜像响应延迟更敏感。
- 降级 Composer 自身：
composer self-update 2.2.22（Linux/macOS）或composer self-update "2.2.22"（PowerShell） - self-update 不走 packagist 镜像，失败时需设代理或手动下载 PHAR（校验
SHA384！） - 镜像探测脚本里别混用
COMPOSER_HOME和~/.composer：Windows Git Bash 实际读取的是%APPDATA%\Composer\config.json - CI 环境中固定 Composer 版本，别依赖
self-update——网络波动或版本下线会导致构建失败
最易忽略的缓存残留点：autoload + OPCache
镜像切换或 Composer 降级后，vendor/ 和 composer.lock 更新了，但代码仍报 Class not found，大概率不是镜像或版本问题，而是 autoload 映射或 OPCache 没刷新。
这和镜像无关，但常在降级操作后集中爆发，因为旧类名可能被缓存残留。
- 强制重建 autoload：
composer dump-autoload（开发）或composer dump-autoload -o（生产） - OPCache 必须重启 PHP 进程：
sudo systemctl reload php8.2-fpm或php-fpm reload - 某些框架（如 Laravel）的
bootstrap/cache/config.php也缓存了包信息，降级后需php artisan config:clear - 别信“改完配置就生效”——PHP 进程不重启，autoload 和 OPCache 就不会重新加载
