包名拼错或大小写不一致是最常见原因，Composer严格匹配Packagist注册的完整包名，如monolog/monolog正确而Monolog/Monolog报错；需核对官网URL、清除缓存、验证镜像同步及repositories配置。

包名拼错或大小写不一致是最常见原因

Composer 严格匹配 Packagist 上注册的完整包名，monolog/monolog 和 Monolog/Monolog 是两个完全不同的包，后者直接报 Package not found。很多“网络问题”其实根本没发请求，只是本地输错了。

• 打开 https://packagist.org/packages/，把你要装的包名完整粘进去（比如 https://packagist.org/packages/spatie/laravel-backup），看是否返回 404 页面
• 别从网页、聊天记录里直接复制包名——可能藏有不可见空格或全角字符，建议在纯文本编辑器里重打一遍再粘贴
• 检查是否漏掉 vendor 前缀，比如把 phpunit/phpunit 写成 phpunit
• 确认 GitHub 仓库名和 Packagist 注册名一致：有些作者会改 repo 名但没同步更新 Packagist，导致 vendor/name 实际已失效

镜像源没同步或配置未生效

国内镜像（如阿里云、腾讯云）不是实时全量同步，新发布的包、dev 分支、刚打的 tag 通常有 5–30 分钟延迟；更关键的是，composer config -g repo.packagist 显示的地址 ≠ 实际生效地址——项目级 repositories 会覆盖全局配置。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

• 运行 composer diagnose，找到 Repo packagist.org: 这一行，后面跟的 URL 必须是你设的镜像地址且结尾带斜杠（如 https://mirrors.aliyun.com/composer/）
• 临时切回官方源验证：composer config -g repo.packagist composer https://packagist.org
• 清除缓存后删元数据目录：composer clear-cache，再手动删掉 ~/.composer/cache/repo/https---mirrors-aliyun-com-composer（路径按你实际镜像 URL 转义）
• 用 curl -I https://mirrors.aliyun.com/composer/p/vendor/name.json 直接测镜像是否已同步（HTTP 200 + Last-Modified 接近当前时间才算）

私有包或 VCS 仓库没配 repositories

Composer 默认只查 Packagist，你写了 "myorg/mylib": "dev-main"，但它既没上 Packagist，又没告诉 Composer “去我公司 GitLab 或本地文件夹里翻”，那它当然报 not found——不是找不到，是根本没去找。

• 确保 composer.json 的 repositories 区块包含完整类型和 URL，例如 GitLab 私有库要写成：

  "repositories": [
    {
      "type": "vcs",
      "url": "https://gitlab.example.com/mygroup/mylib.git"
    }
  ]

• Git 标签或分支名必须真实存在："dev-my-feature" 要求远程有对应 branch；"1.2.3" 要求有对应 tag（不能是 release-1.2.3 或 v1.2.3-final）
• GitHub 私有仓库需 token 认证：确保 auth.json 里写了 {"github.com": "xxx"}，且 token 有 read:packages 权限；URL 里不能带 @username，否则 Composer 会忽略认证
• 项目级 repositories 配置错一个字段（比如漏了 type 或 URL 少了 .git 后缀），Composer 会静默忽略整条配置，继续查默认源

PHP 或 Composer 版本不满足平台要求

某些包明确声明了 php >=8.0 或 composer-plugin-api >=2.2，如果你本地 PHP 是 7.4 或 Composer 是 1.x，Composer 解析依赖时会直接过滤掉所有可用版本，最终报 not found——它不是没找到，是“算出来根本不能装”。

• 运行 php -v 和 composer --version
• 打开该包的 Packagist 页面，点开 Requires 标签页，核对 php 和 composer-plugin-api 约束
• 若确实不兼容，可临时用 --ignore-platform-reqs 绕过（仅调试用），或降级到兼容旧版的 tag，比如把 "spatie/laravel-ray": "^1.30" 改成 "spatie/laravel-ray": "1.29.*"
• Laravel China 镜像已于 2023 年底停用，还在用必 404；旧镜像如 https://packagist.phpcomposer.com 也已失效，换源后务必执行 composer clear-cache

真正卡住的地方往往不在网络或权限，而在「Composer 没按你想的那样去查」——它要么查了错的源，要么压根没查你认为它该查的地方。验证时优先用 composer diagnose 和浏览器直连 Packagist，比反复删 vendor 有效得多。