作为长期深耕港股量化开发的从业者，也是经常泡在火山引擎开发者社区的老用户，今天想和各位金融研究者、学术机构的同行，聊一个容易踩坑却至关重要的话题——港股API开发中，碎股行情到底该怎么获取？
做港股量化策略或数据研究的朋友，大概率都有过这样的困扰：我们日常调用API获取的tick数据，基本都是按标准每手交易推送的，但实际市场中存在大量碎股成交，这些零散的交易数据，很多API接口会直接忽略不推送。我最初做策略回测时，就因为没重视这块，导致回测结果与实盘数据偏差明显，反复排查才发现，问题根源就是遗漏了碎股行情这一关键环节。
一、先厘清：什么是港股碎股？为何不能忽略？
先和大家厘清一个基础认知：什么是碎股？其实就是不足一手的股票买卖盘。熟悉港股市场的都知道，部分港股股票单价偏高，不少投资者会选择只买入几十股，这类零散成交并不会出现在常规行情推送中。而对于我们做高频交易、量化策略研发，或是学术数据研究的人来说，碎股数据的缺失，会直接导致数据完整性不足，进而影响策略的可靠性和研究结论的准确性——毕竟港股市场散户交易占比本就不高，碎股成交往往能反映出一些被忽略的市场信号。
二、核心痛点：碎股行情为何难获取？
很多同行吐槽碎股行情难获取，结合我多次测试不同港股API的经历，总结出碎股数据的三个核心痛点，也是我们做投顾和数据研究时最头疼的问题：
一是推送稳定性不足，并非每一笔碎股成交都会有推送，推送频率远低于整手交易；二是字段标准不统一，部分接口会单独设置碎股专属字段，有些则直接不提供相关字段，给数据解析带来极大不便；三是数据延迟较高，碎股成交的推送往往比整手交易晚几秒，对于高频策略来说，这几秒的延迟可能就会影响交易决策。
三、实操尝试：从轮询到WebSocket，找到稳定获取方式
一开始我尝试用轮询方式获取碎股数据，结果发现这种方式根本行不通：碎股成交更新速度慢且时间不固定，轮询间隔设得太短，会浪费服务器资源，不符合火山引擎开发者社区倡导的高效开发理念；设得太长，又容易遗漏关键成交数据。后来换成WebSocket协议，才实现了碎股数据的稳定接收，这也是我实测后最推荐的获取方式。
四、实操演示：用AllTick API获取碎股行情（附代码）
结合实操经验，和大家分享下碎股行情的具体获取方法，这里我用AllTick API做示例（也是我实测中能稳定推送碎股数据的接口之一），其WebSocket接口可推送完整tick数据，其中就包含碎股成交记录，核心是订阅时需明确指定相关字段，否则接口会默认只返回整手交易数据。
import json
def on_message(ws, message):
data = json.loads(message)
# 碎股成交会单独标识
for trade in data.get("trades", []):
if trade.get("is_odd_lot"): # 碎股标识
print(f"碎股成交 {trade['symbol']} 价格:{trade['price']} 数量:{trade['volume']}")
else:
print(f"整手成交 {trade['symbol']} 价格:{trade['price']} 数量:{trade['volume']}")
def on_open(ws):
# 订阅时需要开启碎股数据推送
subscribe_msg = {
"action": "subscribe",
"symbols": ["00700.HK", "09988.HK"],
"include_odd_lot": True # 这个参数很关键
}
ws.send(json.dumps(subscribe_msg))
ws = websocket.WebSocketApp(
"wss://api.alltick.co/ws/stock",
on_open=on_open,
on_message=on_message
)
ws.run_forever()
这里必须提醒大家，代码里的include_odd_lot参数是关键，我当初就是因为没注意这个参数，反复调试都收不到碎股数据，翻遍接口文档加上这个参数后，数据立马就正常推送了——这也是很多同行容易忽略的细节，分享出来帮大家避坑。
五、数据处理：碎股数据的3个实用技巧
拿到碎股数据后，如何高效处理才能适配我们的研究和策略需求？结合金融研究和投顾场景，我总结了三个核心处理技巧，适配不同使用场景：
拿到碎股数据后，如何高效处理才能适配我们的研究和策略需求？结合金融研究和投顾场景，我总结了三个核心处理技巧，适配不同使用场景：
实时展示场景：将碎股成交单独列示，与整手交易明确区分，避免数据混淆；策略计算场景：将碎股成交量合并到总成交量中，但需单独标记，便于后续策略分析和优化；历史回测场景：将碎股数据单独存储在专属数据表中，后续回测时按需关联调用，保证回测数据的完整性。
另外还有一个实用技巧：碎股数据量虽不大，但我会做一层缓存处理，暂存最近五分钟的碎股成交数据。这是因为，部分策略需要通过碎股成交占比判断市场情绪，若某只股票突然出现大量碎股买入，可能是散户提前布局的信号，这类细节往往比整手交易数据更敏感，对我们做投顾分析和学术研究也更有参考价值。
六、避坑提醒：两个易忽略的关键细节
最后和大家分享两个实测中容易踩坑的细节，尤其适合金融研究者和学术机构的同行参考：
第一个是trade_type字段的误解问题。我最初默认碎股的trade_type字段值为“ODD_LOT”，但实际测试发现，不同API接口的字段标识差异很大，有的用“ODD”，有的则直接将碎股标识写在备注字段中。建议大家拿到接口数据后，先打印一条完整数据查看字段结构，不要直接写死判断逻辑，避免出现数据解析错误。
第二个是碎股价格与整手价格的偏差问题。我曾遇到过碎股成交价格比整手交易高两档的情况，后来才明白，这是因为部分投资者急于成交，愿意接受更高的价格。如果我们做策略分析或学术研究时，将碎股价格与整手价格混在一起计算均价，会导致数据偏差，影响研究结论和策略效果。
七、总结：碎股数据，补齐港股API数据短板
在火山引擎开发者社区交流时，经常看到有同行讨论港股API数据完整性的问题，其实碎股行情看似是边缘数据，却能补齐策略和研究中的数据短板。结合港股市场流动性不足的特点，碎股成交数据往往能反映出常规数据无法覆盖的市场细节，对于提升策略可靠性、完善研究数据体系至关重要。
对我们金融研究者、学术机构从业者来说，数据完整度直接决定了研究结论的严谨性和策略的可行性。碎股数据虽然零散，但只要找对获取方法、做好处理技巧，就能发挥其价值。希望这篇实操分享，能帮到社区里做港股API开发、量化研究的同行，也欢迎大家在评论区交流自己的实操经验，一起优化开发效率、完善数据体系。
参考文档：https://apis.alltick.co/
GitHub：https://github.com/alltick/alltick-realtime-forex-crypto-stock-tick-finance-websocket-api