用 composer search 查包需配合 --max-results 和 --only-name 避免遗漏，搜索依赖功能词而非框架名，结果须用 show 验证兼容性，并辅以 packagist 网页端筛选下载量、维护状态等关键指标。
直接用 composer search 就能查，但默认只返回 10 条，容易漏掉好包
命令本身不需额外配置，运行即连 Packagist 官方仓库。但很多人搜完就停在第一页，其实结果常被截断。composer search log 看似返回了 monolog/monolog、psr/log，却可能错过更轻量的 yalumi/logger 或专为 CLI 设计的 symfony/console-logger。
- 加
--max-results=30才算真正“扫一眼”：例如composer search cache --max-results=30
- 别信“前几条就是最好的”——
monolog排第一是因为热度高，不是最适配你项目（比如你只要一个单文件日志写入器） - 如果搜不到预期包，先确认网络是否能通
packagist.org（国内用户常见问题：镜像源未生效或过期）
关键词组合不是“越多越好”，而是要贴近 Packagist 的实际索引逻辑
Packagist 的搜索本质是“包名 + 描述 + keywords 字段”的全文模糊匹配，并非搜索引擎式的语义理解。所以 composer search laravel auth jwt 并不等于“Laravel 的 JWT 认证方案”，而更可能是名字含 laravel、描述里带 auth、keywords 里有 jwt 的三个独立条件叠加。
- 优先用功能词而非框架名：搜
auth jwt比laravel jwt更容易发现通用库（如firebase/php-jwt） - 短语搜索加双引号没用：
composer search "cache redis"和composer search cache redis行为一致，Packagist 不支持精确短语匹配 - 想锁定包名？加
--only-name：例如composer search monolog --only-name
可排除掉描述里带monolog但实际无关的包（如某个文档工具）
光看 search 结果不够，必须用 show 验证兼容性与维护状态
搜索结果只显示包名和一句话描述，根本看不出它是否支持 PHP 8.3、有没有弃用警告、是否还在积极维护。很多团队踩坑都是因为跳过这步，直接 require 后才发现依赖冲突或文档缺失。
- 查清最低 PHP 版本：
composer show monolog/monolog | grep -i "requires php"
- 看最近更新时间：
composer show monolog/monolog输出里找time字段（注意：这是 Packagist 记录的发布时间，不是 GitHub commit 时间） - 检查依赖树是否引入冗余组件：比如搜到
guzzlehttp/guzzle，show后发现它 requirepsr/http-client而你项目已用symfony/http-client，就得权衡是否换轻量替代品
命令行搜不到时，别硬扛，立刻切到 Packagist 网页版补位
composer search 不支持按 type、abandoned、downloads 排序，也没法看 star 数或用户评论。当你要评估“哪个缓存库最稳定”或“有没有 Laravel 11 兼容的替代品”，网页端才是真主力。
- 用高级筛选语法：在 https://www.php.cn/link/ec811d0d775adc62776ba80fadd4ed19 搜索框输入
cache type:library requires:php-8.2 - 对比下载量：同功能包之间，月下载量差 10 倍以上，通常意味着生态支持度差异巨大
- 点进包页看
Abandoned?标签——有些包搜得到，但页面顶部明写 “This package is abandoned”，命令行完全不提示
search 快速捞出候选名单，再用 show + Packagist 页面交叉验证关键指标。漏掉任一环，都可能把调试时间浪费在不该选的包上。 
