2、交易系统专有名词介绍
约 1630 字大约 5 分钟
2026-05-06
订单类型介绍
结合你提供的 GTC, IOC, IOC_BUDGET, FOK, FOK_BUDGET 这几个枚举值,它们之间的核心区别在于对 **“成交数量”**和 “总花费” 的约束不同。
简单来说,这几个类型可以按三个阶段来理解:GTC 是基础;IOC 和 FOK 引入了“时间”和“数量”的强制约束;而带 _BUDGET 的变体则是为了解决“价格跳过(Price Slippage)”问题,增加了一层“预算风控”。
🧱 基础阶段:GTC (Good Till Canceled)
这是最基本的订单类型,限定了时间。它的目标是尽量成交,直到完全成交或你主动取消它。
- 核心效果:如果没有立即完全成交,剩下的部分会留在订单簿里,等待未来的对手盘。
- 数量约束:灵活。能成交多少就成交多少。
- 预算控制:无。完全按照订单的总金额来计算。
⚡ 中间阶段:IOC 与 FOK
这两个类型都限定了时间和数量,要求订单必须“立即”处理。它们的区别在于对“数量”的处理上:
| 订单类型 | 处理逻辑 | 最终结果 |
|---|---|---|
| IOC (Immediate or Cancel) | 能成交多少就成交多少,无法成交的部分立即取消。 | 可能部分成交。 |
| FOK (Fill or Kill) | 必须完全成交,哪怕只有一股无法成交,整个订单都会被取消。 | 要么全部成交,要么全部失败。 |
示例:你下一个买入 10 股的 IOC 订单,市场只有 6 股可卖,你会成功买入 6 股,剩下 4 股被取消。而 FOK 订单则会因为数量不够而全部作废。
🛡️ 关键阶段:_BUDGET 变体的诞生
IOC_BUDGET 和 FOK_BUDGET 的出现,是为了解决一个实际痛点:防止“价格跳过”带来的超预算风险。
为什么需要预算版本?
假设你打算用 200 美元 买 10 股,心理底价是 20美元/股。但买单进入市场时,最便宜的卖单是 21美元/股:
- 如果没有预算保护,系统会认为“价格可以接受”,然后以 21美元/股 的价格成交,你实际会花费 210美元,超出预算。
- 有了
_BUDGET约束,系统会在成交前进行校验,如果按当前价格成交会导致总花费超过预算,则会阻止这笔成交。
IOC_BUDGET 与 FOK_BUDGET 的应用场景
这两种策略继承了基础版的“立即处理”特性,并叠加了预算风控:
IOC_BUDGET (预算版即时成交):在立即成交的前提下,增加了“成交总金额不得超过 预算上限”的约束。它常用于吃单(Taker) 场景,既能确保快速成交,又能严格控制单笔交易的总花费,非常适合用固定资金吃单。
FOK_BUDGET (预算版全部成交):在必须立即全部成交的前提下,增加了“成交均价不得超过 预算上限”的约束。它能确保你的大额订单在执行时,不会因为瞬间的价格波动而超出预算,常用于套利等需要精确控制成本的策略。
⚙️ 在交易所中的实现逻辑 (核心区别)
在像 exchange-core 这样的撮合引擎中,处理带 _BUDGET 的订单时,会多一步检查:
# 伪代码示例
def match_order(order, market_order):
available_volume = market_order.volume
# 1. 预算检查(_BUDGET 订单特有)
if order.is_budget_order:
# 预估成交后的总花费
estimated_cost = (order.avg_price + market_order.price) * min(available_volume, order.remaining_volume)
if estimated_cost > order.budget_limit:
return # 预算不足,禁止与这个对手盘成交
# 2. 执行成交逻辑...
if order.is_ioc or order.is_fok:
# ... 立即处理逻辑| 订单类型 | 时间限制 | 数量限制 | 预算控制 | 典型场景 |
|---|---|---|---|---|
| GTC | 长期有效 | 灵活 | 无 | 挂单做市,等待成交 |
| IOC | 立即 | 部分成交 | 无 | 快速吃单,但不怕部分成交 |
| IOC_BUDGET | 立即 | 部分成交 | 有 | 用固定资金吃单,精确控制花费 |
| FOK | 立即 | 必须全部 | 无 | 必须全部成交的策略(如特定套利) |
| FOK_BUDGET | 立即 | 必须全部 | 有 | 大额订单全成交,但绝对不超预算 |
💎 总结
- GTC 是你最基础的“挂单”工具。
- IOC / FOK 是“立即处理”的工具,核心区别在于能否接受部分成交。
_BUDGET变体 是在上述订单之上增加了一层“资金风控”,是更成熟的交易系统设计,能有效防范市场波动带来的超预算风险,你研究的exchange-core支持这些类型,说明它是一个考虑周全、贴近实战的系统。
希望这个解释能让你清楚地理解这几个订单类型。如果想继续了解 POST_ONLY 这类更精细的策略,或者 GTC 订单具体的过期时间设定,随时可以再问我。
市场类型或产品类型 介绍
FUTURES_CONTRACT
CURRENCY_EXCHANGE_PAIR
BOTH- FUTURES_CONTRACT 和 CURRENCY_EXCHANGE_PAIR 分别代表了两种最常见的、逻辑完全不同的金融产品。
- BOTH 则是一个便捷的标志,常用于系统组件(如风险管理或数据路由)需要同时处理这两类产品的场景。
📊 三种类型详解
| 枚举值 | 类型 | 核心逻辑 | 关键特征 | 处理难点 |
|---|---|---|---|---|
FUTURES_CONTRACT | 期货合约 | 预测未来价格,通常有到期日,允许加杠杆 | 有到期日、结算价、维持保证金 | 需要处理资金费率、到期交割、强平 |
CURRENCY_EXCHANGE_PAIR | 现货交易对 | 立即兑换资产,无到期日,所有权即时转移 | 如 BTC/USDT,直接兑换 | 逻辑相对简单,核心是保证资产安全 |
BOTH | 混合模式 | 一个接口或组件能同时处理期货和现货 | 通常是系统内部的一个标记或掩码 | 需要代码能适配两种不同的业务逻辑 |
⚙️ 在交易所系统中的应用场景
这些枚举通常会在系统的上层模块被用于区分业务逻辑:
- 风控模块:FUTURES_CONTRACT 需要检查保证金和杠杆,CURRENCY_EXCHANGE_PAIR 只需检查账户余额。
- 清算结算:期货合约可能涉及每日无负债结算,现货交易则是在成交后立即进行资产划转。
- 行情模块:期货和现货的价格(Price)、持仓量(Open Interest)等数据含义不同。
- API 网关:用 BOTH 表示该接口可同时服务于两类产品。