你發出一筆 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
