数据与方法
本页写清三件事:数据从哪来、什么条件会被拦在榜单外、徽章到底说明了什么。不写清这些,排行榜就是噪音。
来源与规模
- 数据更新
- 2026-11-05 01:05 UTC(本次构建 2026-11-05 05:05 UTC)
- 抓取查询
- language:zig stars:>=10 / language:zig stars:>=200
- 唯一仓库
- 2451(跨查询按仓库 id 去重)
- 归并后项目
- 2451,其中 0 组存在跨宿主同源
- 进榜
- 1516
- build.zig.zon
- 1556 个解析成功,覆盖 63.5%;其中声明版本下限的占全站 45.5%
- 依赖图
- 704 条边,450 个被指向目标
- 增速数据
- 暂不计算——现有 1 份快照,窗口需要两份相隔 ≥2 天
为什么镜像必须先归并
同一个项目在不同托管平台的星标数不能直接混排。实测例子:ziglang/zig 在 GitHub 是 43,258 星,在 Codeberg 是 6,997 星,而 Codeberg 才是现在的原件。 不归并的话榜首会被镜像占住,排序结论直接失真。归并键优先取仓库描述里声明的上游地址 (形如「mirror of …」「moved to …」),取不到时退回去掉镜像前后缀的 owner/repo。
被门槛拦下的分布:
| 镜像 | 18 |
| 停更(超 18 个月无推送) | 876 |
| 星标过低 | 0 |
| 已归档 | 168 |
| fork | 0 |
综合分公式
score = 0.35 × 归一化(log(stars))
+ 0.20 × 归一化(快照窗口内的 star 新增)
+ 0.20 × 活跃度(距最近推送的指数衰减,半衰期 180 天)
+ 0.15 × 归一化(log(被依赖数))
+ 0.10 × 维护健康度增速窗口固定在 7 天左右:基线取「与最新快照相距最接近一周」的那一份,而不是最早的那份。 这一点必须写死,否则「增速」的含义会跟着跑批频率漂——按周更跑满三个月后, 最早 vs 最新的差值已经是季度增量,却还挂着「本期新增」的名字。 在拿到两份相隔 ≥2 天的快照之前,增速项会被剔除并把权重摊给其余项,而不是按 0 计算—— 否则新入库项目会被系统性压到榜尾。这是本页唯一一处「数据不足时的降级」处理。
维护健康度是代理指标:许可证是否存在、描述是否完整、topics 数量、fork/star 比是否合理、是否有主页、issue 相对星标的比例。逐个取 contributors 需要额外 API 配额,目前没做。
兼容性徽章的确切含义
| 徽章 | 说明 | 不该怎么用 |
|---|---|---|
| CI 实测通过 | CI 在该 Zig 版本下 zig build 成功 | 尚未上线,当前全站不会出现 |
| 声明支持(下限 X) | minimum_zig_version ≤ 你的版本 | 不能当成「兼容」;它是下限 |
| 需 Zig ≥ X | 声明的下限高于你的版本 | 可当作「暂时用不了」的较强信号 |
| 未声明版本 | 没有 build.zig.zon,或其中没有该字段 | 中性,不代表质量差 |
| 长期停更 | 无版本声明且超 18 个月无推送 | 需要结合项目性质判断 |
全站覆盖率只有 63.5%,意味着 36.5% 的项目 我们无法给出任何版本结论。这是这份索引当前的真实上限。
已知局限
language:zig由文件体积主导,一个仓库只要 .zig 文件字节数最多就会被算作 Zig 项目;反之 Zig 写核心、C 写绑定的项目可能不被算进来。目前用「language 为 Zig」加「topic 含 zig」两路查询取并集来缓解,没有逐仓库统计文件占比。- 分类是关键词加权,头部之外的项目可能出现同类误判。每个项目页都公开了命中的证据与置信度,方便指出错误。
- 星标不是质量。榜单默认按综合分而非星标排序,且门槛会先把镜像与停更项排除。
- Gitee 当前未纳入:实测搜索「zig」返回的 1090 条里前 20 条有 18 条是 0 星镜像,信噪比过低,接入只会污染结果。
- 没有做「编译验证」之前,本页所有版本结论都是声明层面的。
多久更新一次
全量重采(仓库元数据 + 逐个取 build.zig.zon)大约 10 分钟机器时间、零成本, 所以节奏按「什么在变」定,而不是按预算定。仓库元数据每周重采一次; manifest 缓存按 28 天过期重取——一个项目后来补上minimum_zig_version,是唯一会悄悄把人从「需 Zig ≥ X」挪开的变化。 Zig 发稳定版不是日历事件:它会让所有声明下限同时换结论,所以版本表与版本判定页在 发布当天单独重建,不等排期。
「只重新构建、不重新采集」按缺陷处理,不算捷径:页面公布的是采集时间而不是构建时间, 两者相差超过 10 天时产物检查直接判失败。
路线图
- P1:保持每周 star 快照不断档,让 7 天增速窗口始终有基线;Codeberg 全量并入并按 canonical 去重。
- P2:CI 对头部项目跑
zig build矩阵,产出「CI 实测通过」徽章;补齐依赖图下游影响面。 - P3:缺口报告——哪些分类还没有可用库,反哺给 awesome-zig 与项目作者。
不做什么
Zig 官方已表示不会创建中央包索引,本站不声称官方、不代表 Zig 团队,也不做星标刷量与付费排名。数据来源为公开 API,抓取遵循各平台速率限制。
本页有英文版本。