最准方法是运行composer config -g repo.packagist，若输出含https://packagist.phpcomposer.com或https://packagist.laravel-china.org则已失效；再用curl -I测p/provider-*.json接口是否返回HTTP/2 200，最后必须删vendor和composer.lock并重装。
怎么确认当前镜像源是不是已失效
直接查配置比猜快得多：composer config -g repo.packagist，输出里如果含 https://packagist.phpcomposer.com 或 https://packagist.laravel-china.org，就等于在用已停服的地址——这两个域名自 2022 年起就返回 404，不是“暂时不稳定”，是彻底下线。
别信 curl 测首页就完事。真正要测的是 provider 文件路径：curl -I https://mirrors.aliyun.com/composer/p/provider-2025-10%24.json。这个 URL 必须返回 HTTP/2 200；返回 404 或超时，说明镜像没同步、被拦截，或你本地 DNS 解析错位。
临时切回官方源验证最可靠：composer config -g repo.packagist composer https://repo.packagist.org，再跑一次 composer install。如果 404 消失了，问题 100% 出在镜像上，不用再往下排查包名或网络。
为什么换了镜像还是 404？锁文件在捣鬼
composer.lock 不只是记录版本，它硬编码了每个包的 provider 下载地址（比如 https://packagist.org/p2/monolog/monolog.json）。一旦你之前用过失效镜像或官方源，lock 文件里就存了这些已死链接。换源后 Composer 仍会优先尝试 lock 里的旧地址，而不是新镜像的路径。
所以光改配置、清缓存没用。必须做三件事：
- 删掉
vendor/目录 - 删掉
composer.lock（尤其不能只删 vendor） - 再执行
composer install（不是update，后者会复用 lock 里坏掉的元数据）
CI 环境更要注意：每次构建都是干净容器，composer.lock 如果被提交进 Git，就等于把旧 provider 地址固化进了流水线。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
私有包 404 的真实原因常被误判
报 404 时先别急着换源。私有包（如 "myorg/mylib": "dev-main"）出问题，90% 是因为 repositories 配置不完整或认证缺失。
检查点很具体：
-
type字段必须明确写成"vcs"（Git）、"package"（本地路径）或"composer"（私有仓库），不能省略 - Git URL 必须带
.git后缀，且不能含用户名密码（如https://user:pass@gitlab.example.com/...），否则auth.json会被忽略 - 分支名（
dev-main）或 tag（1.2.3）必须真实存在于远程仓库，大小写敏感 - GitHub/GitLab 的 Personal Access Token 必须有
read:packages权限，且通过composer config --global github-oauth.github.com <token>注入
一个常见陷阱：公司内网 Git 服务启用了反向代理，但没透传 User-Agent 头，导致 Composer 请求被拦截返回 404（实际是 403 伪装）。
缓存清理不是可选项，而是强制前置动作
composer clear-cache 必须在删 vendor 和 lock 之前执行。缓存里存的是 provider 列表的 URL 映射（比如 p/provider-2025-10%24.json），一旦镜像切换，旧缓存会持续指向已失效路径，哪怕你已经改了全局配置。
注意两点：
-
clear-cache不会清除auth.json或composer.json，但它会清掉所有 provider 元数据，强迫 Composer 重新从新源拉取 - CI 环境中，如果没配缓存策略（如 GitHub Actions 的
cache: $HOME/.composer/cache），每次构建都得重下全部 provider，失败概率陡增
最后提醒一句：国内主流镜像（阿里云、腾讯云、清华）目前都正常，但它们不保证实时同步 dev 分支或刚发布的 tag。遇到新包 404，先切回官方源验证，再决定是否等同步——别把时间耗在反复清缓存上。
