SearchRepositories 不返回 StargazersCount，需用 Repositories.Get 单独获取；未认证请求限速60次/小时且结果不全，建议用带 Token 的 NewRateLimitWaitClient 并控制并发。
Go-Github 库的 SearchRepositories 默认不返回 star 数
你用 go-github 调 SearchRepositories，发现返回结果里 StargazersCount 总是 0，不是接口没数据，是 GitHub 搜索 API 本身就不返回完整仓库字段。搜索接口只返回精简字段（如 Name、URL、Stars 是别名，但实际结构里不带），而 StargazersCount 属于「仓库详情」字段，得单独查。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 先用
SearchRepositories拿到仓库ID或FullName（如"gorilla/mux"） - 再对每个结果调
Repositories.Get获取完整信息——这才是StargazersCount的正确来源 - 注意速率限制：一次搜索最多 30 条，每页再查 30 次详情 = 30 × 2 次请求，容易触发
403 rate limit exceeded - 别省事把
SearchRepositories的result.Items直接当完整Repository用，字段缺失会静默失败
认证方式决定你能拿到多少星标数据
未认证请求走匿名限流（60 次/小时），且搜索结果默认按“相关性”排序，stars:>1000 这类过滤可能被降权或截断；OAuth Token 或 PAT 认证后升到 5000 次/小时，还能用 sort=stars + order=desc 真正按星标倒序拉取。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
github.NewTokenClient包一层http.Client，别直接传空 client 给github.NewClient - PAT 至少开
public_reposcope，私有库不用就别开多余权限 - 环境变量传 token：
os.Getenv("GITHUB_TOKEN")，硬编码在代码里等于公开泄露 - 没认证时搜
"language:go stars:>5000"可能只返回前 10 个，认证后才稳定出全量
github.Repository 结构体字段命名和实际 API 字段不完全对应
比如 GitHub API 返回的是 "stargazers_count"，但 go-github 映射成 StargazersCount（驼峰），看着合理，但有些字段它故意加了 XXX 后缀，比如 Owner 是 *github.User，而 User 结构里 Login 对应 API 的 "login"，但 SiteAdmin 却对应 "site_admin" —— 表面一致，底层 JSON tag 才是真相。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 查字段映射，直接翻
go-github的repository.go源码，别猜 - 打印原始响应调试：
fmt.Printf("%s", body)（从http.Response.Body读一次，记得body.Close()） - 如果要用
Archived、Disabled这类较新字段，确认你用的go-github版本 ≥ v48.0.0，老版本压根没定义 - 别依赖
Repository.String()日志输出，它只打部分字段，StargazersCount这种数字字段经常被省略
并发拉取仓库详情时，Repositories.Get 容易 panic
常见错误是多个 goroutine 共享一个 *github.Client 实例，又没配 rate.Limit 和 rate.Wait，瞬间发几十个请求，GitHub 直接返回 403，而 go-github 默认把非 2xx 当 error 处理，但如果你没检查 err != nil 就直接取 repo.StargazersCount，就会 panic：nil pointer dereference。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
github.NewRateLimitWaitClient替代裸NewClient，自动 sleep 等待重置 - 并发数严格控制在 5–10，别上 30，GitHub 对单 IP 的突发请求很敏感
- 每次
Repositories.Get后必须判断：if err != nil { log.Printf("get %s failed: %v", fullName, err); continue } - 别用
sync.WaitGroup+ 匿名函数闭包捕获repo变量，循环里会覆盖，导致所有 goroutine 写同一个地址
最麻烦的不是写不对，是 GitHub 搜索和详情两个 API 的语义差异藏得太深——搜出来的“stars”是估算值，详情里的 StargazersCount 才是准数，但你要为这一个数字多发 30 倍请求，还随时可能被限流。真要批量抓，不如先存 FullName，再分批错峰查。
