答案：Composer报“Package not found”通常因包名拼错、私有包未配repositories、PHP/扩展不兼容、版本约束冲突或缓存问题。先用composer search验证存在性，再查minimum-stability、platform配置及conflict字段，运行composer why-not或prohibits定位具体拦截项。
Composer 找不到包，大概率不是网络或源的问题，而是版本约束冲突——尤其是你本地已装的依赖和新包要求的 PHP 版本、扩展或依赖版本不兼容。
为什么 composer require 报 “Package not found” 却能搜到？
Composer 的包发现机制分两步：先查 packagist.org 元数据缓存，再校验本地环境是否满足 require 中所有约束。哪怕包存在，只要你的 composer.json 里写了 "php": "^7.4"，而目标包只支持 ^8.1，它就会被直接过滤掉，报错看起来像“找不到”。
- 运行
composer show -p | grep 包名确认包是否真在 Packagist 上（排除拼写错误） - 用
composer why-not vendor/package:version查具体哪条约束被卡住（比如ext-gd缺失、monolog/monolog版本太低） - 临时删掉
composer.lock和vendor/再试 —— 有时旧 lock 文件会固化过时的解析路径
composer require 加了版本号还是失败？检查三类隐性约束
显式写的版本号只是冰山一角，真正拦路的常是这三类：
-
PHP 主版本：包的
composer.json里"php": ">=8.2"，而你php -v是 8.1.26 → 必须升级 PHP 或换包 -
扩展依赖：包声明了
"ext-xml": "*"，但你的 CLI PHP 没开extension=xml.so→ 运行php -m | grep xml验证 -
已有依赖锁死：项目已装
guzzlehttp/guzzle:^7.0，新包要求^8.0→ 不是“找不到”，是“不能共存”，得用composer update guzzlehttp/guzzle先升再装
用 composer prohibits 定位真实冲突源
比 why-not 更直接：它列出所有阻止某个包安装的现有依赖。例如想装 laravel/sanctum 却失败，执行：
composer prohibits laravel/sanctum:^3.2
输出类似：
illuminate/support 9.52.15 requires php ^8.0 -> your php version (7.4.33) does not satisfy that requirement.
这时你就知道问题不在 Sanctum 本身，而在 illuminate/support 的版本链上。常见解法：
- 加
--with-all-dependencies让 Composer 尝试连带升级上游依赖 - 手动降级目标包版本（如改用
laravel/sanctum:^2.15）适配当前生态 - 确认是否真需要该包——有些包在 Laravel 10+ 已内置，重复 require 反而触发冲突
最麻烦的情况是多个包对同一依赖提出互斥要求，比如一个要 symfony/console:^5.4，另一个要 ^6.2。这时候没有银弹，只能逐个查 composer show vendor/pkg 看它们各自兼容的最低/最高版本，再找交集。别跳过 composer.json 里的 conflict 字段——有些包明写了“不兼容 XX 版本”，但错误信息里根本不会提。
