aastock港股如何深入分析?用十档盘口与逐笔成交

TickDB Research ·

aastock港股如何深入分析?用十档盘口与逐笔成交

摘要: 在 AASTOCKS 看完港股报价,若还想判断买卖盘厚度、观察成交节奏或复盘价格变化,需要把盘口和逐笔记录接入程序。TickDB 的港股盘口支持买卖各最多十档,逐笔查询返回成交价格、数量、方向与时间,并可订阅实时成交。本文用深度失衡和成交样本均价说明这些数据的用途,同时区分最近成交窗口与可按日期回查的历史数据。

image.png

搜索 aastock,打开 AASTOCKS(阿思达克)查看港股报价,是观察市场的一个起点。但一个最新价无法回答更细的问题:当前买卖报价之间隔了多远?买一背后的几档还有多少挂单?某次价格跳动是一笔小额成交,还是一段密集成交的结果?

这些问题分别需要盘口深度和逐笔成交。TickDB 对港股应用的具体价值,在于把买卖各最多十档的价格与数量、可查询的逐笔成交明细,以及实时 depth / trade 推送提供给程序,让看盘观察能够继续进入计算、告警和记录复盘。本文围绕这一数据用途展开,不把 AASTOCKS 当作待抓取的数据源,也不暗示两家存在接口合作。

十档盘口让报价从一个数变成价格梯度

最新成交价描述已经发生的成交,盘口描述当前可见的买卖报价。只看买一和卖一,可以计算最优价差;继续看买二至买十、卖二至卖十,才能观察靠近市场价格的挂单分布是否集中、是否存在明显的数量落差。

当前港股 depth 文档标注每侧最高十档,REST 返回 bids 和 asks,每档包含价格与数量;也可以通过 WebSocket depth 持续接收更新。买盘按价格降序、卖盘按价格升序排列。这里的“十档”是每侧上限,不保证每次都有十档;空档、流动性不足或休市时可能返回更少。

这带来两个可计算的观察量。第一个是最优价差,即卖一减买一。第二个是当前可见深度失衡,即“买方档位数量之和减卖方档位数量之和”,再除以两边数量之和。比较时应固定档位范围并核对数量单位;若只有部分档位,要报告实际档数,不能把结果命名为完整十档指标。

image.png

图 1:十档盘口支持对多档挂单进行计算。数值为构造示例,数量单位一致,不代表任何股票的实时报价。

例如买方十档数量合计 12,000、卖方合计 8,000,则失衡值为 (12000−8000)/(12000+8000)=0.20。它表示这一可见范围内买方数量较多,可以作为观察盘口变化的输入;它并不意味着价格将上涨 20%,也不能证明大单一定会成交。挂单可以撤销,十档报价也没有提供逐笔委托身份或完整订单队列。

还可以在“当前挂单保持不变”的假设下,按卖一、卖二等逐档累加,估算一个给定买入数量会涉及哪些可见价位。这是静态深度测算,不能当成实际成交价格或滑点保证;超出已返回档位覆盖的数量,应标记无法估算。

逐笔明细补上实际成交的过程

盘口回答“现在挂着什么”,逐笔成交回答“实际成交了什么”。港股逐笔记录包括成交 ID、价格、数量、方向和毫秒时间戳。程序可以据此统计样本内成交笔数、数量分布、成交间隔,以及成交量加权平均价,进一步判断一段价格变化对应怎样的成交活动。

一个简单构造样本包含三笔成交:价格 100.00、数量 100;价格 100.20、数量 200;价格 100.10、数量 100。样本均价为 (100×100+100.20×200+100.10×100)/400=100.125。这个结果只描述这三笔成交,不能称为全天均价。研究时需要同时保留样本最早与最晚时间,避免把“最近若干笔”误读成“最近一分钟”。

方向字段有 buy、sell、neutral 三类。可以分别统计各类数量,但应保留中性成交,也不要把方向标签直接改写为“主力净流入”。成交方向分类本身不提供交易者身份;具体分类方法和数量单位仍需核对。

历史逐笔明细需要分清服务范围。 当前公开 REST 文档支持查询成交记录,默认 100 笔、最多 1000 笔,列出的参数为 symbol、limit、type。已核验材料没有给出按起止日期回查多天成交的参数、分页方式或逐笔保留年限。因此,本文把它用于最近已发生的成交查询,不把它宣传为任意历史日期的全量逐笔下载。

若目标是今后持续复盘,可以订阅 WebSocket trade 并由应用归档。港股推送中的成交位于 data.trades 数组,一条消息可能包含多笔,不能只取第一笔。历史 K 线的可查询范围也不能直接当作历史逐笔的保留范围。

image.png

图 2:逐笔查询与实时订阅可进入同一个复盘流程。归档是应用实现的能力,断线缺口仍需检查。

组合盘口与成交才能解释更多现象

假设卖一数量减少了,只看两次盘口无法判断它是被成交消耗,还是被撤走。加入相邻时间段的成交记录后,可以检查该价位附近是否出现相应成交;若同时观察到报价补充,还能研究挂单消耗和补充的节奏。这是多份证据的对照,不能凭一次数量变化断言某个参与者在吸筹或出货。

这里需要防止时间上的误用。盘口与成交来自不同消息或请求,必须保留各自原始时间和本地接收时间。只有确认时间含义可比较后,才能做近似对齐;不要拿成交之后的盘口倒推成交之前的可见流动性。缺少事件序列、消息存在间隔时,也不能把近似对齐包装成精确还原。

对于港股看板、流动性观察工具和成交异常提示,这正是结构化行情接口的价值:应用可以把同一标的的最新价、盘口状态和成交事件分开存储,再按自己的问题计算。它比只在程序里显示一个价格多了实际分析空间;这不等于断言 AASTOCKS 的其他产品没有相应功能。

查询十档盘口并计算成交样本指标

下面的 Python 3 示例分别查询 700.HK 的盘口与最近成交,输出实际档数、价差、可见深度失衡、成交笔数、样本时间范围和样本均价。代码只依赖标准库,保存为 hk_depth_trades.py,在环境中设置 TICKDB_API_KEY 后运行。

当前官方权限表将 depth 和 trades 标为基础版及以上可用、免费版不可用;具体仍取决于账户权益与标的覆盖。程序不是撮合器,也没有实现流式归档。

import json
import os
from decimal import Decimal
from urllib.parse import urlencode
from urllib.request import Request, urlopen


def fetch(path, **params):
    url = "https://api.tickdb.ai/v1/market/" + path
    request = Request(url + "?" + urlencode(params), headers={
        "X-API-Key": os.environ["TICKDB_API_KEY"]
    })
    with urlopen(request, timeout=10) as response:
        body = json.load(response)
    if body.get("code") != 0:
        raise ValueError("API business error")
    return body["data"]


def positive(value):
    number = Decimal(str(value))
    if not number.is_finite() or number <= 0:
        raise ValueError("Invalid price or quantity")
    return number


def summarize(depth, tape):
    if depth["symbol"] != "700.HK" or tape["symbol"] != "700.HK":
        raise ValueError("Unexpected symbol")
    bids = [(positive(p), positive(q)) for p, q in depth["bids"]]
    asks = [(positive(p), positive(q)) for p, q in depth["asks"]]
    if not 0 < len(bids) <= 10 or not 0 < len(asks) <= 10:
        raise ValueError("Empty or unexpected depth")
    bid_qty = sum(q for p, q in bids)
    ask_qty = sum(q for p, q in asks)
    unique = {}
    for trade in tape["trades"]:
        key = (trade["id"], trade["timestamp"])
        if key in unique and unique[key] != trade:
            raise ValueError("Conflicting trade records")
        unique[key] = trade
    trades = list(unique.values())
    amounts = [(positive(t["price"]), positive(t["quantity"]))
               for t in trades]
    total = sum(q for p, q in amounts)
    vwap = sum(p * q for p, q in amounts) / total if total else None
    times = [t["timestamp"] for t in trades]
    return {
        "bid_levels": len(bids), "ask_levels": len(asks),
        "spread": str(min(p for p, q in asks) - max(p for p, q in bids)),
        "visible_depth_imbalance": str((bid_qty - ask_qty) / (bid_qty + ask_qty)),
        "depth_timestamp_ms": depth["timestamp"],
        "trade_count": len(trades),
        "trade_window_ms": [min(times), max(times)] if times else None,
        "sample_vwap": str(vwap) if vwap is not None else None,
    }


if __name__ == "__main__":
    depth = fetch("depth", symbol="700.HK", type="stock")
    tape = fetch("trades", symbol="700.HK", type="stock", limit=1000)
    print(json.dumps(summarize(depth, tape), indent=2))

这里特意保留两套时间:盘口的 depth_timestamp_ms 和成交样本的 trade_window_ms。两个请求先后执行,不是同一时刻的原子快照,因此代码仅分别统计,不把两者硬拼成因果结论。sample_vwap 是返回记录的成交量加权均价;visible_depth_imbalance 只覆盖实际返回档位。

示例在单次响应内用成交 ID 与时间戳组合处理完全重复记录,冲突记录直接报错。这不是对成交 ID 跨日唯一性的假设。长期归档还应确认 ID 作用域,保存原始记录和来源,并单独处理更正、重复消息与断线区间。数量无效、盘口为空等情况会报错;时间有效性、市场状态、异常价差和账户限流需要在生产应用中进一步处理。

代码和文中计算已用构造样本离线验证,未进行带密钥的在线查询或持续订阅实测。公开文档核对日期为 2026 年 10 月 22 日,示例数值不是真实行情。

接入后的验收要落在分析任务上

选择港股行情服务时,应检查要研究的标的能否返回预期档位、逐笔记录是否含所需字段、订阅后如何保存和重建自己的样本窗口。请求了 1000 笔不代表返回了 1000 笔,更不代表覆盖完整交易日;持续订阅也不自动证明没有漏数。

TickDB 在本文场景中的优势,是把十档报价梯度与逐笔成交过程都变成可计算的数据输入,并提供查询和订阅两种接入方式。对需要从 AASTOCKS 日常看盘走向自主分析的人,这能支撑盘口观察、成交节奏统计和自有记录复盘。实际选用时,再按标的、权限、时效和历史覆盖需求逐项验证。

资料依据:AASTOCKS 官方网站;TickDB 港股行情说明、盘口深度、逐笔成交及 WebSocket depth / trade 文档。核对日期:2026 年 10 月 22 日。

查看相关行情工具

相关文章

港股投资者必备:三大数据源对比,哪种最适合实时行情与回测?

港股投资者必备:三大数据源对比,哪种最适合实时行情与回测? 想做一个港股自选股看板,或者回测一套港股策略,第一步往往都是找数据接口。可等到真正开始接入,问题就变得具体了:拿到的是最新报价,还是正在变化的日 K 线?成交量已经是“股”,还要不要乘每手股数?历史数据缺了一段,是休市、停牌,还是接口只返回了部分记录? 这些问题会直接影响选型。 看板重视更新方式与失效识别,回测重视历史覆盖、字段口径…

TickDB Research ·

做港股量化前,先检查这 8 个数据细节

引言:港股量化,策略不难,数据难 做港股量化的人,真正花时间的往往不是写策略,而是跟数据格式较劲。 腾讯到底是 还是 ?为什么有些数据源返回的盘口只有 5 档?半日市那天策略为什么下午还在报警?哪些股票是港股通标的,名单在哪更新? A 股和美股量化生态相对成熟,数据格式形成了事实标准。港股不一样——香港交易所(HKEX)是单一交易所,但不同数据源之间的格式差异反而更大。原因很简单:港股既有内地资

TickDB Research ·

别再盲目装插件了!ClawHub 排名前 5 的金融行情 Skill 深度盘点与选型指南

最近给 AI Agent 接入金融数据源的需求非常火爆。很多新手一上来,打开 ClawHub(AI 插件市场)搜到“Finance”或“Market”相关的 Skill 就一顿狂装。 结果往往是:装了一堆功能重叠的插件,AI 在调用时反而会因为不知道该选哪个而“精神分裂”,导致输出错乱。 给金融 Agent 选数据源,核心不在于“谁绝对碾压谁”,而在于“你的场景到底适合哪一款”。为了帮大家理清思路

TickDB Research ·

微信里问一句 AI 就帮你查好行情信息:OpenClaw + 微信 10分钟极简搭建指南

> 不用打开行情软件,不用敲代码,微信对话框里问一句“黄金多少钱”,AI 把实时价格推给你。甚至还能让它每隔 3 分钟报一次价。 > 这套方案,十分钟就能搭好。 --- 一、开篇:从“人找数据”到“数据找人” 我最近做了一件很爽的事:把 AI 接进了微信,让它帮我盯行情。 现在我可以直接在微信里问: - 黄金现在多少钱? - AAPL 最新价格 - 腾讯今天走势怎么样? 它会把实时数据整理好,

TickDB Research ·

基于腾讯云 CVM + TickDB 构建全球资产配置数据底座

做投资,最怕把鸡蛋放在一个篮子里。前两年美股大涨,满仓科技股的投资者赚得盆满钵满;但去年利率飙升,纳斯达克跌了30%,如果账户里只有美股,回撤就难以承受。反过来看,同期港股表现更差,而黄金却逆势上涨——这就是分散配置的价值。 但真正做全球配置时,一个现实难题摆在了面前:数据太散了。想看美股,开一个网站;想看港股,换一个APP;想查黄金价格,又得翻另一个平台。更别提还要自己换算汇率、调整时区,光是把

TickDB Research ·