composer show 不能直接显示 GitHub 星数，因其仅解析本地 composer.lock 或 composer.json 中的静态信息，而星数需调用 GitHub API 获取动态数据。
为什么 composer show 不能直接显示 GitHub 星数
Composer 本身不抓取或缓存远程仓库的元数据（比如 star 数），composer show 只输出本地 composer.lock 或 composer.json 中解析出的包名、版本、描述等静态信息。星数属于 GitHub API 动态数据，必须额外调用 API 获取。
如何用 composer show --format=json 提取包名和仓库地址
先拿到所有依赖的准确包名和 source URL，这是后续查询 GitHub 的前提。注意：不是所有包都托管在 GitHub，有些是 GitLab、Bitbucket 或私有源，要过滤掉非 GitHub 链接。
- 运行
composer show --format=json | jq -r '.packages[] | select(.source.type == "git") | .name + " " + .source.url'（需安装jq） - 如果不用
jq，可用composer show --direct --no-dev手动提取，但会混入非 Git 包；更稳妥的是解析composer.lock：jq -r '.packages[] | select(.source.url | test("github.com")) | [.name, .source.url] | @tsv' composer.lock - 注意
.source.url可能是https://github.com/monolog/monolog.git或git@github.com:monolog/monolog.git，需统一转为https://github.com/{owner}/{repo}格式才能调 GitHub API
用 GitHub API 批量查星数时的坑
GitHub API 有速率限制（未认证 60 次/小时，认证后 5000 次/小时），且对请求头、分页、重试有硬性要求。直接循环 curl 容易被限流或返回 403。
Evez Github Manager
下载
在 OpenClaw 中管理 GitHub 仓库、Pull Request、Issue 与工作流。适用于审查 PR、管理 Issue、自动化 GitHub Actions、同步仓库等场景。
- 必须加
-H "Accept: application/vnd.github.v3+json"和-H "User-Agent: your-app-name"，否则部分响应会失败 - 推荐用个人 token 认证：
-H "Authorization: Bearer YOUR_TOKEN"，否则单 IP 很快触顶 - 不要并发请求 —— GitHub 不保证顺序，且并发超限会返回
403 rate limit exceeded；建议每秒最多 1 次，或用sleep 0.1控制节奏 - 示例单次查询：
curl -s -H "Accept: application/vnd.github.v3+json" -H "Authorization: Bearer xxx" https://api.github.com/repos/monolog/monolog | jq '.stargazers_count'
一个可跑通的最小脚本思路
不依赖 PHP 或复杂框架，用 shell + jq 就能完成。核心是：提取 → 清洗 URL → 调 API → 汇总。关键点在于别跳过错误处理。
- 清洗 GitHub URL：
sed 's/\.git$//; s/git@github\.com:/https:\/\/github.com\//; s/ssh:\/\/git@github\.com\///' - 对每个 repo URL，用
curl -f+|| echo "0"避免脚本中断（比如私有库、404、rate limit） - 输出格式建议用 TSV：
package_name\tstars\turl，方便后续sort -k2nr排序 - 实际执行时，若项目有 80+ 依赖，全程大概耗时 10–15 秒（含 sleep），比想象中慢——API 延迟和 GitHub 的响应抖动比本地命令高得多
真正卡住的地方往往不是命令写错，而是 token 权限没开（需要勾选 public_repo），或者某几个包用了自定义 VCS 类型却误判为 GitHub 地址。查不到星数时，先手动 curl -i 看 HTTP 状态码，比反复改脚本更快。
