答案：composer报“package not found”90%因未正确配置源或包名错误；需严格核对vendor/name大小写、确认packagist存在性、私有包必配repositories且type为vcs/path、检查minimum-stability约束并清缓存验证。
不是网络问题，也不是 Composer 坏了——90% 的 “package not found” 是因为 Composer 根本没去你认为它该去的地方找。
包名拼错或大小写不一致
Composer 对 vendor/name 完全敏感：少一个字母、多一个连字符、大小写错位（比如 monolog/monolog 写成 Monolog/monolog），都会直接报 “Could not find package”。它不会模糊匹配，也不会自动纠正。
- 用
composer search xxx验证是否存在（注意：search查的是 Packagist 全量索引，和实际安装行为不等价） - 打开
https://packagist.org/packages/vendor/name确认 URL 路径是否完全一致 - 私有包或未提交到 Packagist 的仓库，
search一定搜不到，别被它误导
私有源或本地包没配 repositories
Composer 默认只查 packagist.org。你写了 "myorg/private-lib": "dev-main"，但它既不在 Packagist，又没告诉 Composer “去 git@gitlab.myorg.com/myorg/private-lib.git 或 ../private-lib 里翻”，那它就真不会去找——静默跳过，报 “not found”。
- Git 仓库必须在
repositories里声明"type": "vcs"，且url含.git后缀（GitLab 自建实例必需，GitHub 可省但建议统一加） - path 类型本地包必须用
"type": "path"，url是相对路径（如../my-package），不能是绝对路径 - 目标目录下必须有有效的
composer.json，且其中name字段严格等于你在require中写的值 - 配置写错一个字段（比如把
type写成repo），Composer 会静默忽略整条repositories条目
稳定性约束拦住了 dev 分支或 beta 版本
默认 minimum-stability 是 stable，意味着 dev-main、v2.0.0-beta.1 这类非 stable 版本直接被过滤掉，连解析都不解析，就报 “not found”。
- 先跑
composer show -a vendor/name，如果返回空，说明 Composer 根本没识别出这个包——不是版本不存在，是连入口都没进去 - 临时放宽：加
--stability=dev（如composer require vendor/name:dev-main --stability=dev） - 或者在
require行末尾显式加@dev（如"vendor/name": "dev-main@dev"） - 全局改
minimum-stability到dev风险高，容易让其他依赖也升级到不稳定版本，生产环境别留着
镜像源不同步或已失效
国内镜像（阿里云、腾讯云等）不是实时全量同步，新发布的包、dev 分支、刚删掉的包，极易出现 404 Not Found。更麻烦的是 Laravel China 镜像早在 2023 年底就停用了，还在用必 404。
- 运行
composer config --list | grep repo.packagist看当前源是不是指向已失效地址 - 临时切回官方源验证：
composer config -g repo.packagist composer https://packagist.org - 换源后必须执行
composer clear-cache，否则旧缓存仍会请求失效 URL - 私有包永远不可能出现在公共镜像里，配了镜像也白搭，repositories 才是唯一出路
最容易被忽略的一点：repositories 配置错误时，Composer 不报错也不警告，只是默默跳过——你以为它“找不到”，其实是它“根本没看”。每次改完配置，务必用 composer show -a vendor/name 验证是否真能列出版本，而不是只看 install 是否成功。
