我们如何构建每项统计

我们展示的所有内容来自三个保持可审计的来源: Supercell 公开 API（developer.brawlstars.com）、Brawlify CDN（cdn.brawlify.com），以及我们自己的 Supabase 数据库，它持久保存官方 API 在每个玩家最近 25 场比赛之外不公开的战斗和聚合。

Supercell API 是结构数据的标准来源——英雄、小工具、星能、超级充能、装备和事件轮换——但它遗漏了关键字段，如英雄图像、稀有度和长描述。我们将这些字段与独立运行、有时落后 Supercell 一到三天的 Brawlify CDN 进行交叉引用。当我们在官方 API 中检测到 Brawlify 上还不存在的新英雄时，我们保留本地稀有度映射（BRAWLER_RARITY_MAP），以便英雄页面在发布日正确渲染。

我们的数据库在 meta_stats 表中存储两类行: source=user（启用同步的高级用户的真实战斗）和 source=global（来自顶级 PRO 排行榜的自动采样）。网站上的每项公开统计都使用 source=global 过滤器计算，以确保任何单一用户的个人数据永远不会泄漏到公开页面。

BrawlVision 的"PRO"层是基于世界顶级玩家的最近战斗计算的聚合。每六小时一次 cron 任务（meta-poll）查询竞争活动集中的十一个国家的 Supercell 官方排名，并构建一个去重的池，约有 2,100 名独特玩家来自每个国家的前 200 名。

我们对这个池应用概率采样器，以防止流行的（地图、模式）组合主导数据集并掩盖罕见组合。接受单个战斗的概率为 p = min(1, (minLive + 1) / (current + 1))，其中 minLive 是最少代表组合的计数，current 是候选战斗组合的计数。采样不足的组合获得更多权重，饱和的组合停止增长。

cron 每次运行迭代最多 META_POLL_MAX_DEPTH = 1,000 名玩家，软预算 270 秒，以保持在无服务器函数的 300 秒 maxDuration 内。每个响应包含一个"adaptive"诊断块，包含迭代计数、查询的玩家和按模式的计数，以便任何异常的采样器行为在生产中可观察。

朴素胜率（胜利 / 比赛）在小样本上具有误导性: 在新地图上 3-0 的英雄显示"100% 胜率"，但这没有任何意义。BrawlVision 使用贝叶斯平滑来纠正此问题，并返回一个在样本量差异很大的英雄之间可比较的数字。

公式为 WR_bayesian = (wins + α) / (battles + α + β)，其中 α 和 β 是对以 50% 胜率为中心的先验信念进行编码的超参数。实际上 α = β = 25，相当于"在看到真实数据之前假设 50 场之前的 50/50 战斗"。3 胜 0 负的英雄从朴素的 100% 转为 (3 + 25) / (3 + 50) = 52.8%，更能代表实际采样状态。

随着样本增长，先验的权重减小: 1,000 场战斗和 530 胜时，贝叶斯胜率为 (530 + 25) / (1,000 + 50) = 52.9%，几乎与朴素的 53.0% 相同。平滑只在样本真的很小的时候"伤害"。这正是所需的属性: 惩罚噪声而非信号。

Comfort Score 是 BrawlVision 自有的指标，回答"你用哪个英雄真的比平均水平打得更好？"这不是原始胜率: 它以 60/30/10 的权重组合三个组件，覆盖个人表现的不同维度。

主要组件（60%）是玩家用该英雄的胜率，与全球元数据一样进行贝叶斯平滑，以防一个很少使用的英雄扭曲排名。中间组件（30%）是这个个人胜率与英雄整体元数据胜率之间的差异: 当全球元数据为 48% 时，SHELLY 上 55% 的玩家比元数据为 53% 的英雄上 55% 的玩家获得更多 comfort，因为相对提升更大。

最后一个组件（10%）是归一化使用频率: 在其他条件相等的情况下，玩一个英雄 100 次比 10 次更有价值，因为一致性会得到奖励。确切的公式和权重位于 src/lib/analytics/compute.ts，并在每次端点调用时相同地应用，使排名可重现。

每个公开英雄都有一个"+X.Y%"或"−X.Y%"的趋势指示器，显示其元数据胜率在过去 7 天与前 7 天（共 14 天窗口）相比有何变化。计算在 source=global 上运行，窗口每半部分至少 MIN_BATTLES_PER_TREND_WINDOW = 3 场战斗 — 如果任何一半低于阈值，我们返回 null，UI 隐藏箭头而不是编造一个低信号数。

趋势由 pg_cron 任务每六小时在小表（public.brawler_trends，每个英雄一行）中预计算。在数据库中而非端点响应中执行此操作可避免在每次 ISR 刷新时扫描 14 天切片的数万行。如果预计算表超过 12 小时或为空，端点会回退到 meta_stats 上的分页内联路由，以更高的成本返回相同的响应。分页是必需的，因为 PostgREST 静默将未分页的查询截断为 1,000 行，这曾经导致大多数英雄因虚假欠采样而返回 null。

逻辑按设计重复存在: src/lib/brawler-detail/trend.ts 中的 TypeScript 版本（详细路由）和 supabase/migrations/022_*.sql 中的 SQL 版本（批量路由）。两者都使用相同的阈值、相同的窗口和相同的 source=global 过滤器。如果它们分歧，每个英雄的详细页面和聚合页面将为同一英雄显示不同的数字，所以任何更改都应用于两者。

数据更新的频率影响你应该如何解释，所以我们明确记录。静态页面（包括此页面）使用 24 小时重新验证的 ISR（增量静态再生）。动态数据的页面缓存 API 响应，直到相关任务使其无效。

英雄、小工具和星能从 Supercell API 同步，服务器缓存 24 小时。meta-poll（PRO 数据）每 6 小时运行一次，生成新的 meta_stats 行。7 天趋势预计算在 pg_cron 中以"17 */6 * * *"（每 6 小时的 17 分钟）运行，以避免与 meta-poll 冲突。游戏内事件轮换每 30 分钟刷新一次。

启用同步的高级用户的个别战斗在每场比赛后立即通过 sync cron 在滑动窗口中下载。一旦进入我们的数据库，它们以 source=user 输入 meta_stats，并是个人资料部分私有分析的基础; 它们从不出现在公开聚合中，也从不与 source=global 混合。