说实话，一开始我的想法非常直接，甚至Ke以说有点简单粗暴：直接把接口调通再说。打开文档，目光锁定在 /v1/market/ticker 这个端点上，我的第一反应就是——写个 fetch，把返回的 JSON 打印出来kankan这数据到底长什么样。这大概是所有程序员面对新 API 时的本Neng反应，别否认，你肯定也这么干过。

但hen快我就停下来了。因为我还没想清楚：这个页面到底要长什么样。 Ru果连 UI 结构dou没定下来写再多的请求逻辑也只是空中楼阁。所以我决定先稳住心态，把页面结构定下来。UI 结构一旦定型，后面的实现就有了明确的边界。后面所有的工作，本质上dou是在这张结构里“往里填东西”。

面板Neng稳定刷新了但又会遇到一个hen现实的问题：没人想kan所有 Symbol。 市场上有成千上万个交易品种，Ru果你的面板只是无脑地展示所有数据，那它就毫无价值。

用户真正想要的是：“我关心的那几个 Symbol”。这听起来hen简单，但背后隐藏着一个关键的设计决策：自选列表到底算什么？

一开始我以为自选列表需要后端支持，搞个数据库存一下。但实际上，这是一个纯前端状态问题。这个决策kan起来简单，但它背后有一个判断：自选列表是用户状态，不是行情状态。 它不需要后端支持，不需要账号系统，只需要浏览器本地存储就够了。

于是我把 watchlist 提升为明确的状态：

state = {
  watchlist: loadFromStorage
}
function updateWatchlist {
  state.watchlist = list
  saveToStorage
}
function refresh {
  fetchTicker
}

把 watchlist 提升为明确的状态后行情刷新逻辑反而变得geng简单：每次刷新只请求 watchlist 里的 Symbol。我还把自选列表存到 localStorage。Ru果每次刷新页面dou要重新选 Symbol，用户会直接放弃。到这里为止，这个面板具备了Zui小可用性：刷新稳定、关注列表可保存、打开就Neng继续用。

面板Neng跑了但Ru果真的使用起来马上会遇到一个问题：没人愿意一直点“刷新”按钮。

一开始我以为自动刷新hen简单：setInterval 调一下 fetchTicker 就行了。但实际跑起来发现，这简直是个灾难。本质上是请求重叠导致的时序问题：上一轮没回来下一轮又开始了。这会导致数据错乱，甚至把浏览器搞崩。

所以我必须引入一个“刷新中”状态来控制节奏：

  state = {
    isFetching: false,
    nextRefreshAt: null
  }
  function refreshTicker {
    if  return
    state.isFetching = true
    fetchTicker
      .finally => {
        state.isFetching = false
        state.nextRefreshAt = now + interval
      })
  }

关键是：刷新行为本身必须是显式、可控的状态，而不是隐形的副作用。我在工具栏这一行还Zuo了一件事：显示“下次刷新: 5s”，每秒倒计时。我当时的想法是：当用户Nengkan到“还有3秒刷新”，他会知道系统没有卡住、刷新是有节奏的、Ru果数据没变不是系统坏了而是市场本身没动。

Demo 里默认是 5 秒刷新，但也Ke以切换 3 秒或 10 秒。我当时选 5 秒的原因是：3 秒收益不明显但请求量翻倍，10 秒用户会觉得“有点慢”，5 秒是在“感知延迟”和“系统成本”之间找到的平衡点。

页面结构定型后我把 fetchTicker 接到 /v1/market/ticker 上，先跑通一次“从请求到渲染”的闭环。但真正麻烦的是：同一张表里不同市场返回的字段并不一致。

这次我Zuo的是一个 Ticker 行情面板：把外汇、贵金属、美股、A 股、加密货币放进同一张表里满足“kan一眼行情”的需求。有的没有成交量，有的缺少涨跌额/涨跌幅，有的只有买卖价相关字段。

Ru果不Zuo字段容错，页面会直接报错或显示 NaN。所以我必须Zuo字段容错：有值就显示，没有值就显示 -。这样无论行情接口返回什么数据，表格douNeng正常显示。

Zuo到这里其实行情面板的“正常路径”Yi经跑通了。但我hen快意识到一件事：Ru果这个 Demo 真的要给别人用，异常路径不Neng空着。

Zui直接的问题就是一旦接口出错，现在的页面只会“什么dou不显示”。这在自己调试时还Neng接受，但对使用者来说hen难判断到底发生了什么。逻辑上并不复杂，大致就是把数据请求和渲染包在一层异常处理里：

try {
  data = fetchTicker
  render
} catch  {
  showErrorState
}

于是我补了一套Zui基本的错误状态处理：API Key 未配置、请求失败，以及接口返回错误码的情况。同时把底部状态栏的信息也补全了统一展示 API 状态、请求延迟和上次geng新时间。

错误码这块我参考了 TickDB 的错误文档，Zuo了友好提示：1001 是 API Key 无效或Yi过期，2002 是交易品种不存在3001 是请求频率超限。这些细节虽然琐碎，但它们决定了这个 Demo kan起来像个“玩具”还是个“工具”。

面板Neng用了但当我加了几十个产品的时候就会遇到一个问题：找不到想kan的那个。

我引入了基础筛选和搜索：市场筛选、搜索框。

这里有个坑：Ru果把筛选逻辑放在请求层，每次搜索dou要改请求参数，那刷新节奏就全乱了。所以我把搜索/筛选限定在视图层：它只改变表格展示的行，不改变请求的 symbols 列表。这样请求层和渲染层解耦，避免为了 UI 交互去打乱刷新节奏。这样筛选逻辑和行情逻辑就Neng彻底解耦，互不干扰。

右上角的“延迟”也是这个阶段加的。hen多 Demo 截图kan起来hen漂亮，但不知道它是不是真的在跑。加一个延迟数字，100ms150ms，这个 Demo 就不再是“演示品”，而是一个真实的系统。

另外我在底部状态栏加了一个“导出 CSV”的按钮。当时的想法hen简单：Ru果用户Neng把当前行情数据直接导出来自己再Zuo分析或处理，这个 Demo 就不只是“kan一眼效果”，而是Yi经具备了Zui小可用的价值。

hen多行情系统一上来就想Zuo“实时”，第一反应是上 WebSocket、Zuo秒级刷新、加动画。但实际跑起来会发现：用户根本不需要秒级geng新，连接管理、断线重连、消息积压反而成了负担，前端性Neng问题比接口延迟geng严重。

具体来说Ru果用户只是“kan一眼价格”，定时刷新够用；Ru果用户需要“盯着价格变化Zuo决策”，才需要 WebSocket 推送。这不是技术选型问题，而是场景判断问题。

这个 Demo 用的是 REST Ticker + 定时刷新，这是我在这个场景下的选择。数据来源用的是 TickDB 的 /v1/market/ticker，目标hen简单：Neng稳定跑起来、Neng长期用起来。

回头kan，这个面板之所以Neng成立，不是因为选了什么“高级技术”，而是每一步dou围绕同一个目标：让刷新节奏可控、让状态可解释、让用户Neng长期用。在“kan一眼行情”的场景里REST Ticker + 定时刷新就是顺势而为。

这个 Demo 是纯 HTML + 原生 JavaScript，无需构建工具。这个 Demo 的代码我Yi经整理成一个完整仓库，包括页面结构、数据请求、刷新逻辑和异常处理。Ru果你想直接跑一下、或者对某一步的实现细节geng感兴趣，Ke以在 GitHub 里kan到完整代码。

工程上的专业，恰恰是知道什么时候用什么技术。在“行情展示”这个场景里REST Ticker + 定时刷新通常Yi经Neng满足需求；这篇我用一个可运行的 Demo，把这件事Zuo出来验证一遍。

这个页面没有秒级跳动、动画效果、深度盘口、K 线图，但它Yi经Neng回答Zui常见的问题：现在价格是多少？今天涨还是跌？波动范围大不大？不同市场Neng不Neng放在一张表里kan？

Ru果这是一个“盯盘页”，那页面结构会完全不同：需要大字号价格、跳动动画、实时连接状态。Ru果这是一个“列表页”，那就是另一回事。但既然是“kan一眼”，那就让它简单、纯粹、稳定。