Composer包搜索：别只靠命令行，高效组合拳才是正解

先说一个核心结论：如果你还在单纯依赖 composer search 来寻找新包，那效率可就大打折扣了。这个命令查得窄，关键信息如版本、兼容性、下载量一概欠奉。真正高效的做法，是命令行与Packagist网站双线并行，让每个工具都干自己最擅长的事。

用 composer search 快速筛出候选包名

这个命令的本质，是Packagist的一个轻量级命令行接口。它的定位很明确：当你脑子里有个功能关键词时，帮你快速拉出一串候选包名。但也就到此为止了——版本号、PHP兼容性、稳定性，乃至下载量和维护状态，它一概不告诉你。

• 单关键词最常用：composer search cache、composer search pdf，大小写不敏感。不过要注意，它不支持通配符，敲log*会直接报错。
• 多词组合是“与”关系：composer search http client 会比 composer search http 的结果更聚焦。但词也别堆太多，否则容易漏掉那些命名不那么规范的优质包。
• 加 --only-name 避免误匹配：用composer search lara vel --only-name，就能确保结果只包含包名里有“lara vel”的，而不会混入描述里带这个词的其他包。
• 输出过长时立刻管道处理：结果太多看花眼？马上接上 | less 或 | grep -i。比如 composer search queue | grep -i "redis"，就能快速过滤出与Redis相关的队列包。

用 composer show 查已知包的完整信息，不是用来“搜索”

这里有个常见的误区：composer show 默认只列出当前项目已安装的包，它可不是搜索引擎。你输入 composer show log，基本等于白敲。它的正确用法，是确认某个具体包的细节。

• 查已安装包详情：composer show monolog/monolog 会显示当前安装的版本、依赖关系、autoload配置等。
• 查所有可用版本：加上 --all 参数，如 composer show --all monolog/monolog，能列出该包的所有版本号。但请注意，它不显示每个版本对应的PHP要求。
• 想筛“带 cache 的包”？ 这活儿不该它干。如果你非要用，得 composer show --all | grep -i cache，但返回的也只是包名和简短描述，缺乏关键的版本上下文。
• 私有包查询有门道：查私有包必须提前在 repositories 里配置好，否则 composer show --all 根本看不见。临时查的话，要用 --repository 指定JSON地址，直接填Git URL会报 Could not parse version constraint 错误。

在 Packagist.org 上做最终决策，而不是命令行

命令行负责“初筛”，Packagist网站则肩负“定案”的重任。搜索结果页上那些不起眼的小字段，恰恰是决定你后续会不会踩坑的关键。

• 优先看“Downloads / month”和“Last updated”：下载量低迷加上半年没更新，基本等于高风险信号。
• 点进详情页，紧盯 require 段：重点扫里面的 php 版本约束。比如 "php": "^8.0" 意味着它可能不兼容PHP 8.2+的某些新特性（比如只读类），别光被最新的稳定版本号迷惑。
• 顺藤摸瓜到GitHub：点击“Source”链接跳过去，快速浏览Issues里是否有大量未解决的bug或兼容性问题，再看看Recent Commits是否活跃。
• 善用网站高级搜索：像 type:library requires:psr-7、tag:lara vel 这类高级过滤语法，是命令行不支持的王牌功能。

定位某个类属于哪个包：别猜，去 autoload_classmap.php 查

当你遇到一个类（比如 League\Flysystem\Local\LocalFilesystemAdapter）却不知道它来自哪个包时，用 composer search 或 composer show 都是绕远路。

• 最准的路径：直接 grep -n "LocalFilesystemAdapter" vendor/composer/autoload_classmap.php。结果行里的路径前缀（例如 'league/flysystem'）就是你要的包名。
• 如果没搜到：说明这个类是PSR-4动态加载的。这时就得去 vendor/ 目录下按命名空间逐层翻找，或者查看对应包的 composer.json 里的 autoload.psr4 配置。
• 别搞混命令：composer why 只能告诉你“谁依赖了这个包”，回答不了“这个类是谁提供的”这个问题，顺序千万别反了。

最后提个醒，也是最容易被忽略的一点：Packagist搜索结果的默认排序是相关性，而非质量。一个刚上传、零下载、三天没更新的包，只要在描述里塞满关键词，就有可能排在像Monolog这样的老牌包前面。所以，千万别迷信默认排序，手动按下载量或更新时间重排一下，再点进去仔细研判，这才是稳妥的做法。