Daily 热榜聚合的工程化落地

daily 热榜看起来只是把多个平台的热门条目放到一个页面里，实际落地时会同时遇到数据源不稳定、榜单更新频率不同、字段结构不一致、缓存过期策略难统一等问题。尤其是微博热搜、百度热搜、知乎热榜、GitHub Trending 这类来源，用户关心的是“当前是否可信”，而不是系统内部是否成功请求过某个接口。

本文讨论的是面向个人站点、内部看板或内容运营工具的 daily 热榜聚合方案。结论是：不要把热榜当成一次性爬虫任务，而要把它设计成“多源采集、统一归一、短缓存、可降级、可追踪”的数据产品；榜单排名只适合短期展示，长期沉淀应保存快照和来源信息。

实时信息核验时间：2026-07-17 15:03:33 CST。检索到的可参考实现和数据入口包括 DailyHotApi（支持 JSON/RSS、可部署的热门数据聚合 API）、今日热榜官方 API 文档、今日热榜聚合站、微博热搜页等；这些来源共同说明热榜类数据覆盖多平台且更新频繁，工程实现需要把时效、缓存和来源标识作为一等需求处理。

一、问题背景

daily 热榜的价值不在于“复制一个榜单页面”，而在于把分散在不同平台的实时热点压缩成可扫描、可检索、可复用的数据流。对个人博客来说，它可以辅助选题；对团队来说，它可以做舆情观察、竞品跟踪或内容分发参考；对自动化系统来说，它可以作为后续摘要、分类、订阅和告警的输入。

本文限定在工程实现层面，不讨论平台热度算法本身，也不判断某个热点是否值得传播。讨论范围包括数据源选择、抓取节奏、字段归一、缓存、降级、发布前检查。由于热榜排名天然会变化，文章不固化某一刻的具体榜单名次，只保留抓取时间和来源类型。

二、核心思路

• 把“榜单源”抽象成独立适配器。每个来源只负责请求、解析、错误转换和最小字段输出，不在适配器里做跨平台排序。
• 统一字段要足够克制。常用字段包括 source、rank、title、url、hot、fetched_at、raw_id，不要一开始就强行设计复杂内容模型。
• 缓存策略按来源区分。微博热搜这类高频榜单可以使用 1 到 3 分钟短缓存；GitHub Trending 这类更新节奏较慢的来源可以使用 30 到 60 分钟缓存。
• 聚合层只做合并和过滤，不替代来源排名。跨平台热度值口径不同，直接用数字混排容易误导，默认应按来源分组展示。
• 快照比最新值更适合分析。若要做趋势判断，应定时保存榜单快照，再基于标题、来源、排名变化做统计。
• 任何实时数据都要可追踪。页面或 API 响应中必须带上 fetched_at、cache_hit、source_status，否则排查问题时只能猜测。

三、落地步骤

第一步，先定义最小数据结构。字段少一点，后续扩展比回滚复杂模型更容易。

{
  "source": "weibo",
  "rank": 1,
  "title": "示例热点标题",
  "url": "https://example.com/item",
  "hot": "123456",
  "fetched_at": "2026-07-17T15:03:33+08:00",
  "raw_id": "optional-source-id"
}

第二步，为每个来源实现适配器。适配器的输入是来源配置，输出是统一结构数组；异常必须转换成可记录的错误对象，不能直接让整个聚合请求失败。

type HotItem = {
  source: string;
  rank: number;
  title: string;
  url: string;
  hot?: string;
  fetched_at: string;
  raw_id?: string;
};

type SourceResult = {
  source: string;
  items: HotItem[];
  ok: boolean;
  error?: string;
};

第三步，增加缓存和超时。热榜页面通常是读多写少，不应让每次访问都直接打到上游。

# 示例：每 2 分钟刷新一次高频来源
*/2 * * * * /usr/local/bin/node /app/jobs/fetch-hot-list.js --group=fast

# 示例：每 30 分钟刷新一次低频来源
*/30 * * * * /usr/local/bin/node /app/jobs/fetch-hot-list.js --group=slow

第四步，保存快照。最新榜单放缓存，历史榜单入库或写对象存储。快照主键可以使用 source + fetched_at，条目去重可以使用 source + raw_id 或 source + title_hash。

第五步，对外输出时带上状态信息。即使某个来源失败，也要返回其他来源的可用结果，并明确标注失败来源。

{
  "generated_at": "2026-07-17T15:03:33+08:00",
  "sources": [
    { "name": "weibo", "ok": true, "cache_hit": true },
    { "name": "github", "ok": false, "cache_hit": false, "error": "timeout" }
  ],
  "groups": []
}

四、常见坑

• 只看 HTTP 200，不校验内容结构。很多来源页面改版后仍会返回成功状态，但字段已经变了。
• 把所有平台热度值直接混排。不同平台的热度数字口径不一致，跨平台排序应单独建模。
• 缓存时间一刀切。高频榜单缓存太久会失去意义，低频榜单刷新太快只会增加失败率。
• 没有记录抓取时间。用户看到“今日热榜”时，首先需要知道这是当前数据还是几小时前的数据。
• 失败时返回空列表。空列表会被误解为“没有热点”，更合理的做法是返回来源状态和最近一次成功快照。
• 忽略来源合规要求。公开页面、开放 API、第三方聚合服务的使用边界不同，接入前要确认频率限制、授权方式和展示要求。
• 用标题做唯一标识但不做归一。标题中的空格、标点、话题符号变化会导致重复记录。

五、检查清单

• 每个数据源都有独立适配器和超时配置。
• API 响应包含 generated_at、fetched_at 和来源状态。
• 缓存时间按来源更新频率分别设置。
• 单个来源失败不会影响其他来源返回。
• 最近一次成功快照可以在上游失败时降级展示。
• 历史快照保留来源、排名、标题、链接和抓取时间。
• 页面上明确展示数据更新时间，避免把过期榜单误认为实时榜单。
• 接入前确认来源的访问频率限制和使用边界。

六、小结

daily 热榜系统的关键不是抓得多，而是能持续、可解释地交付“某一时间点从哪些来源得到什么结果”。只要把数据源适配、缓存、快照和状态输出拆清楚，后续无论接入开放 API、第三方聚合服务，还是自建抓取任务，都能保持同一套消费接口。

对于博客或内部工具，第一版可以先做来源分组展示和短缓存，不急于实现全网统一排序。等快照积累到一定规模，再考虑趋势分析、关键词订阅和异常告警，会比一开始追求复杂推荐算法更稳。