Streamlit用户花3小时搭了个实时行情看板，发现产品化比写代码难10倍

一个能用的实时行情看板，和能塞进App里直接上线的产品功能，中间隔着多远？

有人用Python+Streamlit花了3小时搭了个原型，然后发现真正的坑不在代码，在怎么让用户3秒内看懂该看什么。

从"能跑"到"能用"：砍掉90%的数据噪音

大多数实时行情工具的毛病是信息过载。股价每跳一次就刷新，满屏数字跳动，人眼根本处理不过来。

这个看板的核心设计叫"Stress feed"（压力事件流）。它不显示原始报价，只在价格异动超过阈值时才弹出一条卡片式警报——比如1分钟暴涨3%、波动率突增50%。产品经理管这叫"降噪"，交易员管这叫"别让我瞎"。

对比传统行情软件的"全量推送"，这个机制直接砍掉了90%以上的无效刷新。代价是延迟几毫秒？不，代价是开发者要多写一套事件检测逻辑，把"数据工程"变成了"产品设计"。

三张卡片解决什么问题

看板拆成三个模块，每个对应一种决策场景。

Pulse table（脉冲表）是主屏。按1分钟涨跌幅排序，附带5分钟趋势、15分钟波动率、一个简化的"市场状态"标签。用户扫一眼就知道现在谁在被爆炒，谁在偷偷崩盘。行数可调，默认20条，防止信息过载。

Stress feed刚才说过。关键是"事件"而非"数据"——一张卡片一条叙事，比如"AAPL 1分钟跳涨2.3%，波动率进入高区间"。这比看原始报价快了大概……人类反应速度的那几百毫秒。

Correlation card（关联卡片）最容易翻车。实时相关性计算很脏：不同股票交易频率不同，时间对齐是噩梦。这个实现做了妥协——只算单锚定股票的相关性，用时间分桶对齐，且在高波动期自动缩短回看窗口。不追求精确，追求"现在谁跟我持仓一起动"。

Streamlit的隐藏成本

选Streamlit是因为快。但"快"有代价。

实时数据流需要WebSocket维持长连接，Streamlit的session机制会周期性重置。开发者得自己管状态：滚动缓冲区存最近N条报价、计算窗口指标、处理连接断线重连。这些代码不写，看板就是演示玩具；写了，代码量翻三倍。

另一个坑是UI刷新。Streamlit的rerun机制对高频数据不友好，直接绑定WebSocket消息会导致页面卡死。解法是做一层缓冲队列，批量刷新——又多了几百行胶水代码。

数据来源是EODHD的实时WebSocket接口。文档没提具体延迟数字，但从实现看，它推的是聚合后的快照而非逐笔成交。对"市场脉搏"这种场景够用，想做高频套利？换栈吧。

控制面板的微妙平衡

顶部放了三个控件：显示行数、关联基准股、时间分桶大小。

产品经理会纠结这里。选项太少，用户觉得被绑架；太多，变成设置页面，违背"扫一眼"的设计初衷。现在的平衡点大概是：让Demo看起来可交互，但不至于让人停下来思考每个选项的含义。

时间分桶那个选项尤其典型。数据稀疏时加大分桶，相关性计算更稳定；数据密集时缩小分桶，响应更快。这个选项暴露了一个底层事实：实时相关性没有标准答案，只有场景适配。

成品看板的演示视频在这里：https://gumlet.tv/watch/69b99df9554f0fb510c28ce6/

代码没开源，但从描述反推，核心循环大概是：WebSocket收数据→滚动窗口计算指标→阈值检测生成事件→Streamlit批量渲染。几百行Python能跑通，但要做成产品，还得补监控、容错、权限、移动端适配……

如果你现在就要搭一个，会先砍掉哪个功能保工期？