composer search 不推荐作主力搜索工具，因仅返回前10项且无版本、PHP要求、下载量等关键信息，结果可能滞后或混入废弃包；应结合 Packagist API 与 composer show 验证。
composer search 命令能查到包，但不推荐当主力搜索工具
它只返回前 10 个匹配项，不带版本、PHP 要求、下载量或更新时间，搜 cache 可能拉出一堆废弃包，比如 doctrine/cache（已标记 abandoned），你根本看不出来。
更实际的问题是：它默认走本地镜像源缓存，有时结果滞后；而 Packagist 官网或 API 是实时的。所以别靠它做最终判断。
-
composer search log适合快速扫一眼有没有知名日志库（如monolog/monolog） -
composer search --only-name redis避免把描述里带 “redis” 的包（如某个 MySQL 驱动的文档）也混进来 - 多词组合是“与”关系：
composer search http client比单搜http更聚焦，但别堆超过 3 个词，否则漏包 - 输出太长？立刻加管道：
composer search queue | grep -i "amqp"
curl 直调 Packagist JSON 接口才是真·最快
比 composer search 快、准、无缓存，且能立刻看到包是否被弃用（abandoned 字段）、最新版发布时间、GitHub stars 数——这些全在返回 JSON 里。
- 基础搜索：
curl -s "https://packagist.org/search.json?q=pdf" - 带格式化（装了 jq）：
curl -s "https://packagist.org/search.json?q=pdf" | jq '.results[] | {name: .name, desc: .description, abandoned: .abandoned}' - 没装 jq？至少加
| head -n 20防刷屏；国内用户建议加--retry 2防超时 - 注意：
search.json固定只返回前 10 条，想多看几个候选，得换词重试，比如从queue改成redis queue或amqp client
搜到包名后，必须立刻本地验证能不能装
名字对 ≠ 能用。很多包声明了 PHP 8.2+ 或 require ext-gmp，但你的环境是 PHP 8.1 —— composer search 和 curl 都不会告诉你这个。
- 确认包是否存在且未废弃：
composer show monolog/monolog，成功返回才说明它当前可用；失败提示Package not found，大概率是拼错 vendor 名或大小写 - 查所有可用版本（含未安装）：
composer show --all monolog/monolog，但它不显示每个版本的 PHP 约束，得点进 Packagist 页面看require.php字段 - 模拟安装暴露硬冲突：
composer require --dry-run phpunit/phpunit:^9，会立刻报 PHP 版本不兼容、缺失扩展、循环依赖等 - 如果你配了阿里云镜像源，
composer show走的是镜像，比curl更贴近你本地真实可用性
为什么你总找不到“真正依赖某个包”的源头
常见误区：以为 composer depends psr/log 会列出所有路径，结果空输出，就以为没人用。其实它只读 composer.lock 和 vendor/，如果包是被某个子依赖“悄悄带进来”的（比如 laravel/framework → symfony/console → psr/log），而你项目没显式 require psr/log，depends 默认就不显示 root 层。
- 先确保 Composer ≥ 2.5：
composer --version，低于就composer self-update - 加
--all才能看到是不是你自己写的：composer depends --all psr/log - 仍为空？说明它来自未声明路径（如 path repo 或手动复制），改用
composer show --tree | grep psr/log定位层级，再对上层包执行composer show --tree upper/package逐级上溯 - 包名大小写和斜杠必须完全一致：
monolog/monolog≠Monolog/monolog≠monolog
composer show 的组合，才是真正可控、可验证的搜索闭环。别跳过本地模拟安装这步，很多兼容性问题就卡在这儿。 
