自选股越来越多,A 股、港股、美股的行情怎么接?

TickDB Research ·

自选股越来越多,A 股、港股、美股的行情怎么接?

每天看自选股,少不了打开行情页面、翻一遍列表,再点进几只股票看看。二三十只还好;要是 A 股、港股、美股都有关注的公司,名单分在几处,来回切换就有点费劲了。

这时很容易冒出一个小想法:做张自己的看板,把几个市场的自选股放在一起,价格、涨跌幅和成交额一起更新,符合条件时提醒一下。工具能先帮自己省下这些重复操作,就已经有了用处。

用着用着,股票池可能就变大了。原本每个市场只关注一小批公司,后来想把 A 股的某个行业、港股的同行公司、美股的相关企业都放进来,合起来就可能有几百只。再往后,还可能想在盘中持续扫某个市场,把原本没在自选里、却出现了关注信号的股票找出来。

同样是“做个选股工具”,要盯多少股票、想多快知道变化,会让行情 API 的接法差很多。

这里用 TickDB 的普通 Ticker REST 接口做例子。像 600519.SH、700.HK、AAPL.US 这样的代码,可以放在同一批查询里。做看板时,几个市场可以共用查询行情、更新最新价和计算筛选条件这套代码,多加一个市场,也能沿用已有的处理流程。

只有 30 只自选股时,把股票代码一起传过去,一次拿回这批行情,再按自己的条件筛一遍。这个接口单次最多查询 50 个代码,这样的小池子一条请求就能装下。用户打开页面时查一次,或者隔一段时间刷新,通常就够用了。

如果想让工具一直盯着这几十只股票,满足条件就提醒,普通 Ticker WebSocket也能用。它支持在一个订阅消息里放多个股票代码,后面持续接收行情更新。自选股数量不多,照样可能有持续盯盘的需求。

到了几百只候选股,批量查询仍然有用。比如在几个市场里按行业或基本面圈出 300 只,再每分钟用行情重排一次,拆成 6 批请求就可以完成一轮。只是刷新越快,请求也越密;改成每 10 秒跑一轮,光这一件事就需要每分钟 36 次请求,还得给其他接口调用留点余量。刷新间隔要对照接口限流来安排,也可以考虑用普通 WebSocket 订阅这个候选池。几百只股票能否一起订阅,要看实际的订阅额度。

而当目标变成盘中一直从某个市场里发现新候选,全量 WebSocket 就更贴近这个需求了。A 股、港股和美股都有各自的全量 Ticker,按关注的市场分别订阅。

比如做港股扫描,订阅一次 HK_Stock,先接收分批到达的市场快照,后续继续接收变化行情。工具里保留每只股票的最新状态,哪只股票有更新,就重新看看它是否满足条件。原本没有关注过的公司,也有机会从这里进入候选列表。

接上以后,提醒怎么发也值得花点心思。同一只股票可能连续更新很多次,条件刚满足时提醒一次,往往就够了。程序重连后,再把市场快照接起来,继续更新股票池。这些小处理做好,工具才能在盘中安静地帮人盯着。

这种接法适合持续运行的全市场扫描工具,接入前需要开通对应市场的全量权限。要是每天只扫描几次,可以用全量 REST 快照:需要时取一批市场数据,跑完规则就结束这一轮。港股全量快照可以这样用,A 股和美股也有各自的接口。

写这篇时是 10 月 2 日。我先用交易日历接口分别查了 A 股和港股当天的安排,结果 A 股休市,港股是全日交易日,于是这次就拿港股做例子。

同时盯几个市场时,这个查询就能用上。每天准备开始扫描时,先看看各个市场今天有没有交易,再按各自的交易时段安排刷新。休市的市场就暂停盘中扫描和提醒,页面保留最近一次行情,旁边标上更新时间。像今天这样,A 股和港股的假期安排不同,两边也能各跑各的;美股也按它自己的交易日和时段安排。

接着,我实际调用了一次港股全量 REST,这次返回了 3,326 条行情记录。先留下自己关注的品种,再跑一轮筛选条件,看看候选名单里会出现哪些名字。之后要继续盯住这个市场,就用全量 WebSocket 接着更新。

按覆盖范围和更新频率选择行情接口

行情接回来以后,最容易想到的筛选条件就是涨跌幅。动了多少,谁排在前面,一眼就能看懂。但只按涨跌幅排一个榜单,能看到的东西还是少了点。Ticker 里还有开盘价、昨收、当日高低价,以及累计成交量和成交额,这些字段可以给价格变化补上一些背景。

拿刚才全量快照里的腾讯控股来看,数据时间是当天 11:43:25,最新价 422.4 港元,比昨收的 431 港元跌了约 2%。

单看这个跌幅,容易把注意力都放在“跌了多少”上。再看一眼开盘价,是 422 港元,最新价其实比开盘还高了 0.4 港元;这时的当日最高价是 425,最低价是 420。相对昨收是下跌,相对开盘却略高一点,日内价格又落在什么位置,几个字段放在一起,同一个价格就有了更多可看的背景。

假如两只股票都涨了 3%,一只已经离当天高点较远,另一只还贴着高点,仅看涨幅时它们很相似,加上高低价之后,就能分开观察了。有人想找靠近日内高点的股票,有人更关心从低点回升的幅度,这些想法都可以变成股票池里的一列。

成交量和成交额又提供了另一种视角。价格在动,交易有没有跟着活跃起来?腾讯这笔行情里的当日累计成交额约为 41.15 亿港元,股票池里也可以把成交量、成交额一起摆出来看。

盘中把同一只股票前后两次的累计值留住,还能看这几分钟新增了多少成交量、成交额。假设前五分钟新增成交 2000 万港元,接下来的五分钟新增了 5000 万港元,就能看出最近这段交易更活跃。某只股票刚进入价格筛选条件,又出现这样的变化,就可以把两个现象一起写进提醒里,留给用户进一步判断。比起只弹出一个股票代码,这样的提醒有更多可看的内容。

不过,成交额本来就会受到公司体量和交易活跃程度的影响。大公司的成交额高,很常见;一只股票今天成交多,也要和它平时的情况比较。比如上午十点的累计成交额,可以和前几天同一时间放在一起看,才更容易判断是不是放量。这里就可以接K 线数据,把当前的量额放回历史里看。

股票池跨了几个市场时,成交额还得看币种。人民币、港元、美元放在同一列里,只排数值大小就容易看错。看板里标明币种,跨市场比较前再统一换算,读起来会清楚些。

如果接下来想比较不同股票的活跃程度,可以通过综合指标接口补查量比、换手率;想进一步看资金流向,再参考资金流向指标。先有一个想弄明白的问题,再决定往看板上添哪一列,工具也比较容易保持好用。

选股工具做到这里,就开始有了自己的用法。自选股只有几十只,可以围绕熟悉的公司设置提醒;候选池到了几百只,可以把价格、日内位置和成交活跃度放在一起重排;需要扫全市场时,则用全量行情不断发现新名字,再给这些候选补上历史走势和其他指标。

也不必一开始就把所有条件都堆进去。先挑一个自己确实关心的现象,把提醒做得有用,再慢慢补充背景。最后呈现给用户的,可以是一句具体的话:这只股票进入了设定的涨幅区间,目前接近日内高点,最近五分钟的成交额也高于前五分钟。至于它是否值得继续研究,用户可以带着这些线索往下看。

用起来以后,还可以把这些提醒留下来,过一阵子再回看。提醒太频繁,就收紧一点条件;某个行业想多看几眼,就加进候选池。个人开发者做自己的看板,研究团队做内部筛选工具,都可以从一个具体的小需求开始,边用边改,慢慢做成顺手的样子。

本文仅介绍行情 API 的应用思路。文中股票、行情样本及筛选条件用于演示,不构成投资建议或任何证券买卖推荐。

查看相关行情工具

相关文章

Python 股票行情 API 实战:用 React 构建实时行情与 K 线面板,支持美股历史数据下载

Python 股票行情 API 实战:用 React 构建实时行情与 K 线面板,支持美股历史数据下载 接入一个行情 API,通常只需要几行请求代码。把 A 股、港股、美股、外汇、黄金、指数和加密资产放进同一个可用的页面,还需要解决另一组问题:代码可能存在歧义,涨跌幅的统计窗口不同,部分品种没有成交量,股票休市后仍然会返回最后一条报价,历史 K 线的最后一根也可能继续变化。 这篇文章用 Re…

TickDB Research ·

适合开发者的实时行情 API 怎么选:REST、WebSocket、MCP 和七个工程边界

直接答案 选择实时行情 API 没有统一标准答案。正确的做法是走三步:先核对市场、粒度、数据时效和授权,再选择传输协议,最后用真实请求验证字段与时间戳。具体来说,需要逐条检查七项工程边界: 1. 目标市场与资产类别。 2. 快照、K线、逐笔、报价、订单簿等数据粒度。 3. REST、WebSocket、MCP、SDK、批量文件等接入方式。 4. symbol、字段名、timestamp 和时区

TickDB Research ·

A 股实时行情 API 2026:从参数到错误处理,一次跑通 ticker 查询

> 调通了 API ≠ 拿到了正确的价格。 你以为"查一下贵州茅台现价"只是一行 HTTP GET。第一次请求返回 ——参数名写错了。修好后,价格字段是 ——取了 而不是 。再修好,触发了限流——没有退避逻辑。最后终于通了,但你用 判断"数据是否新鲜",在周末看到的价格其实是周五下午三点的收盘价。 四次失败,没有一次是网络不通。全是参数、字段和错误处理的细节。 下面用一张误写自查表、一段可复现

TickDB Research ·

行情 WebSocket 从握手到断线重连:symbol 格式不一致才是真正让你对不齐数据的元凶

> 凌晨三点,你的行情数据断了。重连代码在跑,心跳也在发,但系统空转了两个小时——心跳只发了 ping,没检查 pong。更隐蔽的是:品种目录返回的 symbol 是 ,REST 行情接口要的却是 。WebSocket 推送用的是哪种?你的同一套业务代码在处理同一只股票时,格式对不齐,数据关联静默失败——不是报错,而是你的系统里同一个股票在两条链路上用的是两个不同的代码。 一、那个被 Demo 藏

TickDB Research ·

Python 行情 WebSocket 从握手到断线重连:symbol 格式不一致才是真正让你对不齐数据的元凶

> 凌晨三点,你的行情数据断了。重连代码在跑,心跳也在发,但系统空转了两个小时——心跳只发了 ping,没检查 pong。更隐蔽的是:品种目录返回的 symbol 是 ,REST 行情接口要的却是 。WebSocket 推送用的是哪种?你的同一套业务代码在处理同一只股票时,格式对不齐,数据关联静默失败——不是报错,而是你的系统里同一个股票在两条链路上用的是两个不同的代码。 一、那个被 Demo 藏

TickDB Research ·