Composer 2.2+ 在镜像返回 404/503 时自动 fallback 至 packagist.org 是明确设计的容错行为，旨在应对同步延迟；若包已被源站下架或 dist 失效，则 fallback 不触发，需清缓存或强制切源验证。
镜像源返回 404 时 Composer 自动 fallback 是设计行为，不是故障
Composer 2.2+ 版本在镜像源对某个包返回 404 或 503 时，会自动降级到 https://packagist.org 拉取元数据——这不是配置失效，而是明确实现的容错逻辑。它只为应对同步延迟，不解决源站永久下架包的问题。
常见表现：运行 composer require foo/bar 时，日志先出现 Downloading https://mirrors.aliyun.com/composer/p/foo/bar.json（404），紧接着跳转到 Downloading https://api.packagist.org/p/foo/bar.json（成功）。只要最终能装上，说明 fallback 正常工作。
- 别关
"packagist.org": false——关掉后，404 就直接报错，不再兜底 - 镜像页底部的“最后更新时间”滞后超 1 小时，基本可判定是同步延迟而非源站下架
- 若官方源也返回
404（即包真被删了），fallback 无意义，需立刻查 Packagist 页面确认该包是否 still exists
源站已下架包，但镜像缓存仍存在旧版本，导致 install 错误
镜像服务常保留已同步包的 dist 文件（zip/tar）数周甚至数月，但不会主动清理元数据。当源站下架一个包（如 abandoned 或手动 delist），镜像的 packages.json 可能未及时更新，导致 Composer 仍尝试从镜像拉取已失效的 dist URL，报错 Failed to download vendor/package: The "https://mirrors.xxx.com/dists/xxx.zip" file could not be downloaded。
此时 fallback 不触发，因为元数据层面“包还存在”，只是 dist 下载失败。
- 验证方式：手动访问镜像中该包的 dist URL（如
https://mirrors.ustc.edu.cn/composer/dists/vendor-package-1.2.3-zip），返回404即确认 dist 失效 - 临时解法：加
--repository-url=https://packagist.org强制绕过所有镜像，走官方源重试 - 根本解法：执行
composer clear-cache清掉本地缓存的旧packages.json和 dist 索引，再重新composer update
项目级 repositories 配置会彻底屏蔽 fallback 机制
只要项目根目录 composer.json 中定义了 "repositories" 字段（哪怕只写了一行 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}），Composer 就完全忽略全局 repo.packagist 设置，也不启用自动 fallback —— 它把整个 repositories 当作静态源列表，只从第一个提供完整版本信息的源拉取。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
这意味着：镜像挂了 + 项目写了 repositories = 直接报错，不兜底。
- 检查当前生效源：
composer config repo.packagist（不带-g），有输出就说明被项目级覆盖 - 安全做法：删掉
composer.json中整个"repositories"块；或改写为显式启用镜像 + 允许 fallback：{"type": "composer", "url": "https://mirrors.aliyun.com/composer/", "canonical": true}（canonical是 Composer 2.5+ 支持的字段，表示该源可参与 fallback） - CI/CD 中务必避免写死
repositories，改用环境变量COMPOSER_REPO_PACKAGIST或命令行--repository-url
真正可靠的降级必须靠外部探测 + 动态切换 + 清缓存
Composer 本身不支持运行时多源 fallback，所谓“优雅降级”只能靠外部脚本闭环完成：探测可用性 → 切换配置 → 清缓存 → 验证结果。缺一不可。
一个最小可行脚本逻辑：
- 用
curl -I -s -o /dev/null -w "%{http_code}" https://mirrors.aliyun.com/composer/packages.json检查镜像根路径 HTTP 状态码 - 若非
200，执行composer config repo.packagist composer https://packagist.org（项目级，不污染全局） - 强制清缓存：
composer clear-cache（否则仍读旧索引） - 最后跑一次
composer update --dry-run -vvv，确认日志中Downloading地址已变为api.packagist.org
注意：任何不清理缓存的切换都是假切换；任何不验证真实请求 URL 的操作都可能让你误以为“已经切过去了”。
