答案是镜像元数据同步延迟所致，新包需5–30分钟才同步到阿里云等镜像，期间composer show或require会报“package not found”，须用curl -I验证镜像源状态并手动清理对应repo缓存目录。
Composer 中文镜像下载失败，大概率不是镜像本身问题，而是插件未在镜像源同步、或本地缓存/配置干扰导致的假性“无法下载”。
为什么某些插件在阿里云/腾讯云镜像里搜不到
中文镜像（如 https://mirrors.aliyun.com/composer/）是定期从 packagist.org 同步元数据，但不实时同步所有包的完整 ZIP 文件或 Git 仓库。当某个插件：
• 是新发布的（• 仅存在于 GitHub/GitLab 的私有仓库或非 Packagist 注册源
• 使用了 package 类型自定义仓库（而非 vcs 或 composer）
——那么镜像站的 packages.json 就不会包含它，composer require 自然查无此包。
如何快速判断是镜像问题还是本地配置问题
执行以下三步排查，顺序不能错：
- 运行
composer config -g repo.packagist，确认输出是{"type": "composer", "url": "https://packagist.org"}—— 如果显示的是中文镜像 URL，说明全局配置已生效；否则先执行composer config -g repo.packagist https://mirrors.aliyun.com/composer/ - 临时绕过镜像：运行
composer require vendor/name --repository=https://packagist.org，如果成功，说明该插件确实未被镜像收录 - 检查缓存：运行
composer clear-cache，再试一次；旧缓存可能残留过期的packages.json索引
遇到未同步插件时的可行替代方案
不必切回官方源全量下载，可按需局部覆盖：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 对单个包强制走原厂源：在
composer.json中添加"repositories"块，优先级高于全局镜像 - 示例写法：
{
"repositories": [
{
"type": "composer",
"url": "https://packagist.org"
},
{
"type": "package",
"package": {
"name": "vendor/special-plugin",
"version": "dev-main",
"dist": {
"url": "https://github.com/vendor/special-plugin/archive/refs/heads/main.zip",
"type": "zip"
}
}
}
]
}
注意："type": "package" 方式需手动维护版本和 ZIP 地址，适合临时救急；长期依赖建议让作者提交到 Packagist。
镜像配置后仍报 404 或 “Could not find package” 错误
常见真实原因：
-
composer.json里写了错误的包名（比如大小写不符、拼错 vendor 名），镜像不会修正语法错误 - 插件设置了
"minimum-stability": "dev"，但你本地没配"minimum-stability": "dev"或没加--stability=dev - 你用的是企业内网，镜像域名被 DNS 污染或被代理截断（可尝试
curl -I https://mirrors.aliyun.com/composer/p2/vendor/name.json直接测响应）
最常被忽略的一点：Composer 2.2+ 默认启用 packagist.org 的 fallback 机制，但一旦你显式配置了 repo.packagist，这个 fallback 就被禁用了——出问题时不会自动降级，必须手动干预。
