周榜数据怎么取与怎么复核
这份文档写给要自己复算周榜的人。目标不是讲结论，是把「取哪张表、取哪几个字段、按什么顺序算、哪些数不能放在一起」写清楚，照着做能复现出同一组数字。文中出现的每个值都来自 2026-11-09 06:10（UTC+8）的一次现查，口径是 W44 / W45 / W46 三个周次的 20 条榜单。
一、先认表：只有一个来源
| 项 | 内容 |
|---|---|
| 表名 | BoardSnapshot |
| 库 | 站点生产库 dev.db |
| 周次字段 | period，取周次编号（W44 / W45 / W46） |
| 起始日 | weekStart，每周一 00:00 |
| 采集时间 | capturedAt，本次为 2026-11-09 |
| 条数 | itemCount，本期为 20 |
| 主键 | fullName（作者/仓库），跨周连接用它 |
三期的 weekStart：W44 = 2026-10-26，W45 = 2026-11-02，W46 = 2026-11-09。period 是给人看的标签，weekStart 才是可以做比较的键——两者在跨年或补采时会出现不一致，以 weekStart 为准。
二、周次对齐的三条规则
规则一：用自然周，不用滚动七天。 周榜本身按周一至周日切片。改用滚动窗口，同一条插件在两个区间里的天数构成会变，差值失去意义。
规则二：capturedAt 落在周一早上才算当期。 周二、周三补采的数据里混着当周新增的安装，会把整期抬高。本次三期都在周一 06:10 前后采集。
规则三：三期的 itemCount 必须都是 20。 少一条，中位数与合计都变形。校验放在所有计算之前，不通过就停下，不要带着缺行往下算。
三、五个指标的算法
合计：20 条 weeklyDownloads 直接求和。W44 = 1,612,985，W45 = 2,494,484，W46 = 2,940,883。
中位数：按 weeklyDownloads 升序，取第 10 与第 11 位的算术平均（20 条为偶数）。W44 = 23,553，W45 = 49,202，W46 = 47,384。别用「第 10 位」的近似写法，20 条样本上会差出几百。
换手：两周 fullName 集合求差。新进 = W46 有、W45 无，6 条；掉出 = W45 有、W46 无，6 条；留存 = 交集，14 条。留存里再与 W44 求交，得连续三周在榜 12 条。
单条占比：该条 weeklyDownloads ÷ 当期合计。W46 首位 848,207 ÷ 2,940,883 = 28.8%。
变化率：(本期 − 上期) ÷ 上期。合计 W44→W46 涨 82.3%，逐周看是 W44→W45 涨 54.7%、W45→W46 涨 17.9%；中位数 W45→W46 跌 3.7%。三个百分比的分母不同，任何时候引用都要带上是哪两期。
四、四种不能混的口径
1. npm 下载 ≠ 本站安装
周下载是 npm 全网数值，含 CI 流水线、镜像回源、自动化脚本，统计「包被拉取了多少次」，不统计「多少终端装了它」。不能把 2,940,883 说成「安装量」。
2. 星标 ≠ 周下载
星标是 capturedAt 那一刻的累计值，单调不减；周下载是七天区间值，可上可下。两者能并排展示，不能互证，也不能做比值。
3. 名次 ≠ 体量
名次是序数，20 个位置零和。X 上升一位，必然对应别人下降或退出。名次变化只能描述相对位置，说不了增长。W46 的 5 条名次上升里，4 条下载其实在降。
4. 快照时间必须跟着数字走
同一句「合计 2,940,883」，如果没写 2026-11-09 06:10，第二天就可能是错的——补采会覆盖当期快照。凡是引用数字，都要能回答「哪个时点取的」。
五、复核清单
按顺序过一遍，任何一项不过就回到上一步：
- 三期
itemCount都是 20。 - 三期
weekStart相减都是 7 天，没有跳周。 - 合计与「逐条相加」二次核对，允许 0 误差。
- 中位数取第 10、11 位平均，不是取一条。
- 新进数 + 掉出数 + 留存数 = 20，且新进 = 掉出。
- 占比之和不超过 1，首位占比单独可核。
本次核对结果：新进 6 + 掉出 6 + 留存 14 与 20 对得上；W46 首位占比 28.8%；新进 6 条合计 946,769，掉出 6 条在 W45 合计 293,851。
六、两个容易算错的加法
把新进与存量增长加在一起讲涨幅。 W45→W46 合计增加 446,399：新进 6 条贡献 946,769，掉出 6 条带走 293,851。只看净额会高估存量表现。
把两周中位数之差当成整体涨跌。 47,384 与 49,202 是两个不同批次的第 10、11 位平均，换手 30% 的周里不是同一批对象，只能当「榜内典型水平的位移」。
局限
- 只有榜内 20 条。 榜外分布未知，任何「整体」措辞都只覆盖这 20 条。
- 无纠正系数。 CI 流量无法剥离，自动化程度高的包被系统性放大。
- 历史快照会被覆盖。 补采后旧值不可追，跨期比较前先确认三期同批次采集。
- 无版本标记。 表结构变更时没有
schemaVersion可查，只能靠capturedAt与数值合理性反推。
数据复核
复核入口就是本文第三节的算法与第五节的清单：三期 period 过滤、fullName 连接、itemCount 前置校验、中位数取双位平均。当期视图可在 站点榜单页 对照，历史周次按 period 直接取库，不要用页面缓存。
总结
关键只有三件事：认准 BoardSnapshot 一张表、用 weekStart 对齐自然周并在计算前校验 itemCount、算完把 npm 下载与本站安装分开表述；照此复算，W46 的五个指标应与 站点榜单页 的当期数字一致。
适合与不适合
适合：要自己复算周榜的人；需要给团队写一份取数约定的人；写周报前想确认「哪个百分比的分母是什么」的人；接手这份数据、需要知道历史快照会被覆盖的人。
不适合：找现成结论的人——这里只有流程，没有判断哪个插件更好；想拿周下载论证装机量的人——口径对不上；需要长周期趋势的人——三期样本支撑不了。
标签：数据规范、取数流程、GEO、口径、周榜
本文由 DeepSeek Harness Hub 自动整理，数据来源于站点 2026-W46 周榜快照。
