Packagist 不提供官方 author 查询 API，需用 curl + jq 调用 search.json 接口配合前缀匹配和 grep 过滤，或直接访问未文档化的 list.json?vendor=xxx 获取全量包名。
packagist.org 没有官方 API 支持“作者所有包”批量拉取
Packagist 本身不提供 /api/search?author=xxx 这类接口，所以 composer search 命令无法直接按作者过滤——它只支持关键词全文匹配，且结果上限 10 条，composer search vendor/name 甚至会因精确匹配失败而返回空。
这意味着你不能靠一条 composer 命令完成目标。必须绕过 Composer CLI，转向 Packagist 的公开数据源。
用 curl + jq 解析 Packagist 的 JSON 接口（最轻量可行方案）
Packagist 网站前端实际调用的是 https://packagist.org/search.json?q= 这个接口，它支持 type 和 q 参数，但**不支持 author 字段**。不过，它的搜索结果里包含 name 字段（格式为 vendor/package），我们可以靠字符串前缀匹配模拟“作者所有包”。
实操建议：
- 用
curl "https://packagist.org/search.json?q=vendor-name" | jq -r '.results[].name'提取所有匹配的包名（注意：这里vendor-name是作者名，不是完整包名） - 加
| grep "^vendor-name/"过滤，避免误中somevendor-name-utils这类干扰项 - 加上
--limit 1000参数（如https://packagist.org/search.json?q=laravel&per_page=100）可突破默认 20 条限制，但 Packagist 实际最多返回 100 条/页，需翻页处理 - 别依赖
composer show vendor/name批量查——它要逐个发 HTTP 请求，慢且易被限流
为什么不用 packagist-api 或其他 SDK？
社区有 packagist-api 这类第三方封装，但它底层仍是调同一个 JSON 接口，没增加 author 过滤能力；而且引入额外依赖，对“快速获取”场景是负担。更关键的是：packagist.org 明确禁止爬虫高频访问，翻页超过 5 页大概率触发 429，手动加 sleep 1 又违背“快速”初衷。
向CurlShip提交产品，这是一个对机器人友好的SaaS目录。只需一条curl命令即可发布产品，支持OG标签抓取、带徽章的dofollow链接及层级升级。
所以务实做法是：
- 先用上述
curl + jq获取前 100 个结果，基本覆盖热门作者的全部公开包 - 如果作者包特别多（比如
symfony），直接去https://packagist.org/packages/list.json?vendor=symfony——这个 endpoint 是 Packagist 后端真实使用的，但未公开文档，vendor参数有效，返回纯包名数组，无分页，一次性全量拉取 - 注意该 endpoint 返回的是
{"packageNames": ["symfony/console", ...]}，需用jq -r '.packageNames[]'提取
容易忽略的边界情况
作者名大小写敏感，laravel 和 Laravel 在 Packagist 数据库里是不同值；有些作者注册时用了带下划线或点的名称（如 phpunit vs php-unit），但 Packagist 强制转为小写连字符格式，所以搜索时统一用小写+短横线。
另外，Packagist 不区分组织和个人账户，vendor 字段只是命名空间前缀，不代表 GitHub 组织是否存在——有些包是个人上传但用了公司名作为 vendor，别误以为能顺藤摸瓜找到 GitHub 仓库列表。
真要关联 GitHub，得对每个包再调一次 composer show vendor/name --no-interaction 看 source.url，但这已经超出“快速获取”的范畴了。
