必须用 JavaScript 定时 fetch 微博真实 API 并重建 DOM，确保语义化序号、无障碍可读和 SEO 有效；禁用 location.reload() 和 CSS 伪元素计数等无效方案。

直接用 JavaScript 定时拉取 API + 重绘 <ol></ol> 列表，而不是刷新整个页面或靠 CSS 动画“假装更新”——后者根本不会改变 DOM 序号，对读屏软件和 SEO 完全无效。

为什么不能用 location.reload() 或 history.pushState() 模拟刷新

页面整页刷新会打断用户操作（比如正在复制某条热搜词）、触发反爬风控、丢失滚动位置；pushState 只改 URL 栏，不触发新请求，数据还是旧的。微博 H5 的 weibo.com/hot 本身就不返回真实数据，刷它等于白刷。

常见错误现象：
– 用 setInterval(() => location.reload(), 30000) 导致浏览器卡顿、请求被限频
– 把 <div id="hotlist"> 用 innerHTML 替换后，序号靠 CSS <code>::before 生成，但屏幕阅读器仍朗读旧序号
– 未重置 CSS counter，导致第 2 次更新后 li::before 显示 11. 12. 13… 而不是 1. 2. 3…

• 真实榜单必须依赖语义化 <ol></ol>，每次更新需重建整个 <ol></ol> DOM 节点，或至少调用 ol.replaceChildren(...newLis)
• 若保留原 <ol></ol> 节点，务必在重绘前执行 ol.innerHTML = "" 或 ol.replaceChildren()，否则 counter-reset 不会重新计数
• 不要在 li 内嵌套 <div> 或 <code><span></span> 作为容器——counter-increment 只作用于直接子元素，嵌套会断掉计数链

  fetch 微博热搜 API 时必须处理的三个硬性条件

  微博真实可用的接口是 https://weibo.com/ajax/side/hotSearch，但它不是“开箱即用”。漏掉任一条件，返回就是空数组或 418 I'm a teapot。

  立即学习“前端免费学习笔记（深入）”；

  

  DeepBI DHTML 页面生成器

  生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur

  下载
  • 必须带合法移动端 User-Agent，例如：Mozilla/5.0 (iPhone; CPU iPhone OS 16_6 like Mac OS X) AppleWebKit/605.1.15；PC UA 或空 UA 一律被拒
  • 必须携带 Referer: https://weibo.com/ 头，否则返回 {"ok":0,"msg":"非法请求"}
  • 响应 JSON 中真正要的数据在 data.realtime，不是 data.hotgov 或顶层字段；每条含 word、num、url（注意 url 是相对路径，需拼成 https://s.weibo.com/weibo?q=%23${word}%23）

  动态更新时保持 <ol></ol> 序号稳定不跳变

  单纯用 ol.innerHTML = newHtmlString 会导致序号闪烁、多行文字错位——因为浏览器要重排 layout。更稳的方式是用原生 DOM 方法 + CSS counter 配合控制。

  • 更新前先清空：ol.replaceChildren()（比 innerHTML = "" 更语义清晰，且不触发 HTML 解析开销）
  • 每条 li 创建后，显式设置 li.setAttribute("data-rank", i+1)，方便后续调试和无障碍标注
  • CSS 中 li::before 的 width: 2em 必须固定，不能用 ch（数字 1 和 10 占位不同）或百分比（缩放时失准）
  • 移动端要注意：若用 font-size: clamp(1rem, 2.5vw, 1.2rem)，em 单位依然可靠；但 px 在 iOS 缩放下会糊

  容易被忽略的兼容性雷区

  看似简单的刷新，在 Safari、微信内置浏览器、部分国产安卓 WebView 下行为差异极大。

  • Safari 对 fetch 的 cache 默认是 "default"，连续请求可能返回缓存响应；务必加 cache: "no-cache" 或带时间戳参数
  • 微信 Android WebView 的 XMLHttpRequest 在后台标签页中会暂停定时器，setInterval 实际间隔可能变成 5 分钟以上
  • 如果榜单需要支持 IE11（极少数政企内网场景），replaceChildren() 要 polyfill，或退回到 while(ol.firstChild) ol.removeChild(ol.firstChild)
  • 别用 IntersectionObserver 来“懒加载热搜”——热搜本身就是实时内容，延迟渲染等于丢数据

  最麻烦的其实不是技术实现，而是微博接口本身没有公开文档、参数随时可能调整、__rnd 时间戳过期时间不定。建议在代码里埋一个 fallback：当 API 连续两次失败，自动切到备用源 https://s.weibo.com/top/summary（虽然它只更新慢、无热度值，但结构稳定）。