订单类型介绍

结合你提供的 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美元/股：

1. 如果没有预算保护，系统会认为“价格可以接受”，然后以 21美元/股 的价格成交，你实际会花费 210美元，超出预算。
2. 有了 _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	混合模式	一个接口或组件能同时处理期货和现货	通常是系统内部的一个标记或掩码	需要代码能适配两种不同的业务逻辑

⚙️ 在交易所系统中的应用场景

这些枚举通常会在系统的上层模块被用于区分业务逻辑：

1. 风控模块：FUTURES_CONTRACT 需要检查保证金和杠杆，CURRENCY_EXCHANGE_PAIR 只需检查账户余额。
2. 清算结算：期货合约可能涉及每日无负债结算，现货交易则是在成交后立即进行资产划转。
3. 行情模块：期货和现货的价格（Price）、持仓量（Open Interest）等数据含义不同。
4. API 网关：用 BOTH 表示该接口可同时服务于两类产品。

贡献者

codingLab