做自动交易、写策略脚本的朋友，多多少少都会对接股票 API 来拿实时行情。最开始我也有个简单想法：接口调用越勤，拿到的数据越新，策略反应就越快。但是实盘模拟跑久了才发现，这里面并不是这么简单，行情的实时性，和程序、接口的负载，本身就是需要取舍的。[淘股吧]
请求打得太频繁，API 的调用额度消耗很快，电脑或者服务器的 CPU、网络压力也会上来。反过来，如果数据拉取间隔设得太长，盘中关键的拐点很容易就漏掉，买卖信号出来的时候行情已经走出去一截，信号严重滞后。

不同策略，对延迟的容忍度差距很大：
做长周期、日线、多分钟级别：几秒甚至几十秒的延迟，对整体判断影响不大；日内短线策略：需要秒级的行情更新，延迟就必须重视；Tick 级超短策略：对延迟非常敏感，一点点时间差，就会出现条件满足，但现价已经变了，信号完全失真。高频轮询看着好用，实则暗藏隐患很多人图省事，直接写固定间隔轮询，比如每秒请求一次接口拿行情。代码写起来简单，但是长时间跑就会暴露出问题。
大部分时间盘面是比较平淡的，价格不会持续变动。高频轮询大部分拿到的都是重复的行情数据。白白浪费接口次数，程序还要反复处理一模一样的数据，白白消耗算力。
这里纠正一个很多新手容易踩的误区：不是请求频率越高，策略效果就越好。不结合自己的策略特点，一味追求高频刷新，只会徒增负担，回测看着漂亮，模拟盘反而效果变差。


两种获取行情的方式，结合自己策略选
如果只需要分钟 K 线这类低频数据，定时轮询就够用，跟着 K 线周期设置拉取间隔即可。
如果做短线，需要捕捉瞬间的价格变动，更推荐用 WebSocket 长连接推送。不用程序反复去请求服务器，盘面发生变化，服务端主动把行情推过来，可以减少大量无效请求。
我做测试的时候用 AllTick API 订阅 Tick 行情，拿到推送数据之后，再交给策略逻辑去判断要不要出信号。

就算 WebSocket 连上了，还有几个坑要多留意：
重复推送问题：部分接口会重复下发同一条行情，如果不去重，会导致同一个信号反复触发，重复下单；时间戳处理：不同市场时区不一样，直接拿原始时间来算 K 线、判断信号，容易出现时间错位；回调里别跑重运算：接收行情的回调函数不要写复杂策略计算。把接收行情、数据预处理、策略判断拆开。遇到大盘剧烈波动，防止线程卡死，人为造成额外延迟。


找准适合自己策略的平衡点
个人做量化，不用一味死磕极致低延迟。核心是权衡好策略需求和系统开销。
做中低频策略，数据稳定比追求极速更重要；做日内短线，就要重点看行情推送效率，还有本地程序处理速度跟不跟得上。
建议先自己测试，摸清楚你的策略最多能接受多大的延迟，再决定用轮询还是 WebSocket。没有一套万能的请求频率适配所有策略，适合自己交易体系的数据方案，程序才能稳得住。