你发出一笔 10,000 单位的订单，而订单簿上在你那个价格只有 1,000。另外那 9,000 会怎么样？每一笔订单在被发出之前，就已经带着这个问题的答案了。fill or kill、immediate or cancel 与 all or none，是回答它的三种方式——而它们并不是同一个设置的三个变体。
有效期到底决定了什么
有效期（time in force）设置，是附在一笔订单上的一条指令，而它只解决一个问题：此刻无法成交的那一部分会怎么样。要么那一部分留在订单簿上等待，要么它在撮合的那一刻被丢弃。
整根轴就只有这一根。一个“撤销前有效”的订单走第一条岔路，它会一直挂在订单簿上，直到它成交、或你把它移除。一笔 good-till-date 订单以同样的方式等待，但会停在一个你自己设定的期限上。immediate or cancel 与 fill or kill 走第二条岔路，那里根本没有任何东西被留下等待。
FIX 协议，一份历史悠久的订单处理行业规范，把这个字段定义为“规定订单保持有效多久”，而它自己的默认值是一个交易日设置，继承自那些会收市的交易场所。Kraken 在自家的下单接口上把“撤销前有效”设为默认。三种设置在首次出现时都写全，从这里开始简写为 IOC、FOK 与 AON。
immediate or cancel：拿走眼前有的，丢掉其余的
一笔 immediate-or-cancel 订单，会在那一刻拿它能拿的部分与订单簿成交，然后把剩余量丢掉。它允许部分成交：如果你那 10,000 里有 1,000 能在你的价格上成交，就成交 1,000，另外那 9,000 干脆不再存在。
Kraken 把这个设置描述为：立刻撤回任何在到达时无法成交的数量。Coinbase 对同一个行为的措辞是：任何剩余数量都被取消。两个场所，一套机制。
这里的 immediate 指的是撮合的那一刻，不是速度。当订单簿深到足以吸收整笔订单时，一笔 IOC 与一笔同价的普通限价单走同一条路、落到同一个地方。差别只在有东西剩下的那一瞬间才出现。
fill or kill：此刻要么全成，要么一点不成
一笔 fill-or-kill 订单，在同一种即时性之上多加了一个条件：全部数量，或者什么都不要。它是一笔 IOC 加上一条完整性要求，而两个条件必须同时成立。如果你那 10,000 里有 9,000 能成交，IOC 会成交那 9,000，而 FOK 一点也不成交。
FOK 保证的是数量，不是价格。它可以在一个远差于你当时看到的价格的均价上全额完成，因为它会消耗掉完成这件事所需要的任何深度。价格控制是另一件工具——一个限价，或者一个滑点容差——而拿 fill or kill 去躲开一个糟糕的价格，是在向它要一件它并不提供的东西。
Kraken 还记着一条限制，值得你在去找这个设置之前先知道：它的 fill-or-kill 选项只对限价单可用。
all or none 是另一种设置，不是第三种期限
all or none 看上去像 fill or kill 的同胞，其实不是。在 FIX 里，有效期住在一个有八个取值的字段里，而 all or none 不在这八个之中。它住在另一个字段上，那个字段管的是订单处理指令，码值为 G，在那里被描述为 all or none。
这个后果是实务上的，不是文书上的。因为 AON 坐在另一个字段上，它可以与一个期限组合起来：一笔同时是“撤销前有效”的 all-or-none 订单，会挂在订单簿上等待，但永远只会以一个完整的整块成交。fill or kill 把即时性与完整性捆进了同一个有效期取值里，所以它没法等任何东西。
| 剩余量能否留在订单簿上 | 允许部分成交 | 不允许部分成交 |
|---|---|---|
| 能，它等着 | “撤销前有效” | all or none，挂着的 |
| 不能，它被丢弃 | immediate or cancel | fill or kill |
什么都没成交时，状态说的是什么
一笔从未成交过的订单，并不就自动是一笔失败或过期的订单。在 FIX 之下，一笔没有成交的 fill-or-kill 或 immediate-or-cancel 订单，终结于取消；而规范把这两者列为过期状态的明确例外。
这与“取消”的日常含义读起来有点别扭——日常含义里，取消意味着有东西曾经挂着、随后被移除。调和的说法是：这笔订单确实生效了，它只是从未挂在订单簿上。Coinbase 从另一个方向说了同一件事：一笔 fill-or-kill 订单，只有在它会被立刻且完整地成交时，才会被送上订单簿。
官方给出的逐步走法，把这笔算术摆在了明处。一笔 10,000 的 fill-or-kill 订单若无法完成，结束时什么都没成交，于是已成交数量是 0、剩余数量也是 0。一笔同样是 10,000 的 immediate-or-cancel 订单，若找到 1,000 可成交，结束时是成交 1,000、取消 9,000。同一批表格里还带着一条拒绝的分支；而规范另有一处注明：一笔订单即便已经被确认，仍然可以从新建转为拒绝。拒绝与取消是两种不同的结局，所以要读你的交易场所报出来的那个状态，而不是自己假定哪一个适用。
几种设置并排看
| 设置 | 剩余量 | 部分成交 | 它住在哪个字段上 |
|---|---|---|---|
| “撤销前有效” | 一直挂着，直到它成交或你把它移除 | 允许 | 有效期 |
| good-till-date | 一直挂到你设的那个期限 | 允许 | 有效期 |
| immediate or cancel | 当场丢弃 | 允许 | 有效期 |
| fill or kill | 当场丢弃 | 不允许 | 有效期 |
| all or none | 取决于与它搭配的那个期限 | 不允许 | 订单处理指令 |
各自在什么时候是对的选择
当一个部分仓位比没有仓位更糟时，去用 fill or kill。一条只有在完整规模上才成立的套利腿或对冲腿，是最清楚的情形：它的一半并不是好处减半，而是一个新的、你并不想要的敞口。你为这份确定性付出的代价是：差一点没成，就什么也拿不到。
当你想吃掉眼前这些流动性、又不想在身后留下一笔看得见的订单时，去用 immediate or cancel。它穿过订单簿上挂着的那些订单，方式很像一笔市价单；不过市价单讲的是拿走可得的最优价格，而不是拿剩余量怎么办。
当等待本身就是目的时，去用一个挂着的设置。如果你的价格还没有出现在订单簿上，而你也乐意坐等它到来，那么在撮合的那一刻就把订单丢掉，正好背离了目的。
小结
有效期只回答一个问题，也只回答这一个：此刻无法成交的那个数量会变成什么。immediate or cancel 丢掉剩余量，留住它已经拿到的。fill or kill 彻底拒绝部分的结果，所以它要么完成，要么让你一无所得。all or none 根本就不是一个期限，而是另一个字段上的一条完整性规则——这正是它能挂在订单簿上等、而 fill or kill 不能的原因。
在你用其中任何一个之前，先弄清你实际在回答的是两个问题里的哪一个：这笔订单该活多久，还是一个不完整的结果能不能接受。把两者弄混，就是让 fill or kill 被当成一种预期价格保护的原因——而它从来都不是。 想系统学习更多加密基础知识，可以关注 Bitbase（币贝）学院的后续内容。
相关阅读
币贝上与本主题相关的其他文章：
风险披露：本文为 Bitbase（币贝）学院的科普内容，仅供教育与信息参考，不构成任何投资、交易、税务或财务建议。加密资产波动剧烈，请自行评估风险。本文撰写于 2026 年 9 月，请以官方最新信息为准。
参考资料
[1] FIX Trading Community，FIX Application Layer: Order State Changes（FIX Latest，截至 EP284，2023 年 11 月） fixtrading.org
[2] Onix Solutions，FIX 4.4 字典，TimeInForce(59) onixs.biz
[3] Onix Solutions，FIX 4.4 字典，ExecInst(18) onixs.biz
[4] Kraken API 文档，WebSocket v2，Add Order（字段 time_in_force） docs.kraken.com
[5] Coinbase 开发者文档，Advanced Trade API，Create Order docs.cdp.coinbase.com
