Composer找不到包主因是元数据同步延迟、本地元数据缓存残留或项目级repositories配置覆盖全局镜像；需用curl -I验证镜像同步状态，删除~/.composer/cache/repo/下对应元数据缓存，并通过composer diagnose确认实际生效源。
Composer 找不到特定包，绝大多数情况不是包不存在，而是你当前看到的“包列表”根本没刷新到最新状态——元数据同步延迟、本地缓存残留、项目级配置覆盖全局镜像，三者占了 90% 的原因。
为什么 composer show 查不到刚发布的包？
Packagist 上刚发布的 monolog/monolog v3.5.0，在阿里云镜像站通常要等 5–30 分钟才同步完成。这期间执行 composer show monolog/monolog 或 composer require monolog/monolog:^3.5 都会报 “package not found”，不是网络问题，也不是命令写错。
- 用
curl -I https://mirrors.aliyun.com/composer/p/monolog/monolog.json直接查镜像源响应头，HTTP 200 且Last-Modified接近当前时间，才算同步到位 -
composer clear-cache不管用：它只删 zip/dist 缓存，不碰元数据（packages.json、provider-*.json） - 真正有效的刷新是删元数据缓存目录：
rm -rf ~/.composer/cache/repo/https---mirrors.aliyun.com-composer（路径按你实际镜像 URL 转义）
项目里写了 repositories 就自动屏蔽全局镜像
你在终端执行了 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，但进项目一跑 composer install，日志里还是出现 Downloading https://packagist.org/——八成是项目根目录的 composer.json 里写了 "repositories" 字段。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- Composer 规则很硬：只要含
"repositories"，全局镜像立即失效，连 fallback 都不触发 - 检查方式：
composer config --list | grep repositories，有输出就说明项目自己管源 - 常见坑：
"url": "https://packagist.phpcomposer.com"这个源早在 2024 年已停服，但没人删，结果所有请求都 404 - 临时绕过项目配置验证镜像：
composer show -d repo.packagist=composer monolog/monolog
怎么确认当前生效的镜像地址到底是不是你配的那个？
别只看 composer config -g --list 输出，它只告诉你“写了什么”，不告诉你“用的是什么”。真正起作用的，得靠请求日志和诊断输出。
- 运行
composer diagnose，找Repo packagist.org:这一行，后面跟的域名必须是你设的镜像地址（注意结尾斜杠） - 如果显示的是
https://packagist.org/，说明全局配置没生效，或被项目repositories覆盖了 - 某些旧模板还残留
repos.packagist配置（非repo.packagist），这种字段已被弃用，需手动清除：composer config -g --unset repos.packagist
最常被忽略的一点：镜像“不全”不是功能缺陷，而是同步机制的自然延迟；你删缓存、换源、改配置，最终都要落到“是否真从那个镜像地址拿到了最新元数据”上——不验证 curl -I 响应，所有操作都只是在猜。
