週期策略
點差和滑點怎麼算：訂單簿深度與成交驗收
從最佳買賣價、訂單簿累積深度與每筆成交，計算點差、加權成交均價和滑點；用真實 BTC/USDT 快照完成下單前估算與成交後驗收。
點差和滑點怎麼算，關鍵不是背一個固定百分比，而是把「下單前看見的價格」與「實際成交的加權均價」放在同一時間、同一方向和同一數量下比較。讀完本文，你可以從訂單簿估算市價單會吃掉幾層價格，算出點差、滑點與相對中間價的執行成本，並用成交明細判斷結果是否在預設範圍內。
本文是現貨交易的成本與風險教育，不構成投資建議。訂單簿會持續變動，靜態快照只能用來演示算法，不能保證之後的成交價格。
先看答案：點差、滑點與執行成本不是同一件事
| 指標 | 比較基準 | 回答的問題 |
|---|---|---|
| 買賣點差 | 同一時刻的最佳賣價 ask 與最佳買價 bid | 立即買入與立即賣出的報價缺口多大？ |
| 滑點 | 成交加權均價與送單前同方向最佳價 | 這張單吃穿訂單簿或等待期間移動了多少？ |
| 相對中間價的執行成本 | 成交加權均價與送單前中間價 | 點差與滑點合在一起，實際偏離公平基準多少？ |
| 交易總成本 | 執行成本、手續費及可歸因的資金成本 | 資產價格至少要移動多少才能覆蓋成本？ |
如果買入，最佳賣價是你當下能立即成交的第一層；如果賣出，最佳買價才是第一層。最新成交價只是上一筆交易，不能代替你的可成交價格。
第一步：先固定報價與時間
下單前記錄交易對、方向、預計數量、最佳買價、最佳賣價、訂單簿時間與時區。定義：
中間價 =（最佳買價 + 最佳賣價）÷ 2
點差 = 最佳賣價 − 最佳買價
點差（bps）= 點差 ÷ 中間價 × 10,000
1 bps 是 0.01%。用 bps 比單純看價差金額更容易比較不同幣種與不同價格區間。買入相對中間價通常先承擔約半個點差，賣出方向相反；但遇到離散報價、聚合報價或額外加價時，不應直接假設一定是精確的一半。
第二步：沿訂單簿累加深度
訂單簿的 ask 是等待賣出的數量，通常由低到高排列；bid 是等待買入的數量，通常由高到低排列。市價買單從最低 ask 開始吃，市價賣單從最高 bid 開始吃。
對每一層價格 pᵢ 與數量 qᵢ：
該層報價金額 = pᵢ × qᵢ
累積深度 = 逐層報價金額加總
當累積深度第一次覆蓋你的目標金額時，最後一層通常只取部分數量。不能把畫面上的「深度總額」直接當成可成交金額，也不能只看第一層：真正相關的是從最佳價到你的最差容許價之間，有多少同方向流動性。
可見深度也不是承諾。其他訂單可能先成交，掛單可能取消，新訂單也可能加入；你的網路延遲與撮合順序都會改變結果。因此預估值應保留緩衝，成交後仍要用每筆 fill 重算。
第三步：用成交量加權均價算滑點
一張單跨多層成交時，不能把各層價格做簡單平均。正確公式是：
加權成交均價（VWAP）= Σ（成交價 × 成交數量）÷ Σ成交數量
買入：
買入滑點（bps）=（VWAP ÷ 送單前最佳賣價 − 1）× 10,000
賣出：
賣出滑點（bps）=（1 − VWAP ÷ 送單前最佳買價）× 10,000
相對中間價的執行成本已經包含點差與滑點。買入可用 (VWAP − 中間價) × 成交數量，賣出可用 (中間價 − VWAP) × 成交數量。報表應選擇「半點差 + 相對最佳價滑點」或「相對中間價執行成本」其中一套，不要把兩套再相加。
如果還沒把交易手續費分離出來，可先讀站內的Maker、Taker 與真實總成本計算。手續費是平台扣款，滑點是成交價格偏離，兩者證據來源不同。
真實快照：同一市場、不同訂單大小
下表使用 Binance 公開 Data API 的 BTC/USDT 訂單簿，抓取時間為 2026-09-03T19:15:01+08:00，更新 ID 為 99617851692。API 回傳 1,000 層 bid 與 1,000 層 ask；計算只模擬立即按當時簿上數量成交，沒有送出真實訂單，也沒有加入手續費、延遲或掛單取消。
快照最佳買價為 77,822.88 USDT，最佳賣價為 77,822.89 USDT，中間價為 77,822.885 USDT。報價點差為 0.01 USDT，即 0.001285 bps。中間價上下 5 bps 內的累積報價深度，bid 約 3,986,807 USDT，ask 約 4,576,113 USDT；這些數字只描述該時點。
| 模擬方向與名義金額 | 加權均價（USDT） | 相對最佳價滑點 | 吃掉層數 |
|---|---|---|---|
| 買入 10,000 USDT | 77,822.8900 | 0.0000 bps | 1 |
| 買入 250,000 USDT | 77,825.7155 | 0.3631 bps | 75 |
| 買入 1,000,000 USDT | 77,829.3561 | 0.8309 bps | 124 |
| 賣出約 10,000 USDT 名義 BTC | 77,822.8800 | 0.0000 bps | 1 |
| 賣出約 250,000 USDT 名義 BTC | 77,822.4987 | 0.0490 bps | 11 |
| 賣出約 1,000,000 USDT 名義 BTC | 77,816.0067 | 0.8832 bps | 82 |
這個快照說明兩件事。第一，螢幕上的點差極小，不代表大單也能全部在第一層成交。第二，同一名義金額的買賣滑點可以不對稱，因為兩側掛單分布不同。不能把這組數字移植到別的時間、交易對或交易場所。
下單前怎樣估算自己的滑點
- 固定交易對、方向、目標數量與報價時間，不要用數分鐘前的截圖。
- 買入沿 ask 由低到高累加；賣出沿 bid 由高到低累加。
- 最後一層只取完成目標所需的部分數量。
- 用所有預計成交層計算 VWAP。
- 以送單前最佳 ask 或 bid 算滑點，再以中間價算完整執行成本。
- 加入手續費與延遲緩衝，和你預先設定的總成本上限比較。
如果平台只顯示幾層訂單簿，無法覆蓋你的目標數量，就不能假設畫面外仍有相同流動性。可以縮小訂單、分批執行、改用具價格邊界的限價單，或換到能提供足夠深度資訊的場所。分批不保證成本下降；市場可能在各批之間移動，因此每批都要重新取快照。
怎樣設定可接受的滑點上限
先寫總成本預算，再分配給已知費用、點差、價格衝擊與延遲風險：
可用滑點預算 = 總成本上限 − 手續費 − 半點差 − 延遲／波動緩衝
這不是通用推薦值。你的持有期、下單頻率、交易對流動性與策略失效條件不同，上限也應不同。若算出的剩餘預算小於零，問題不是「怎樣成交」，而是這筆交易在目前條件下已超出成本約束。
限價單能限制最差成交價，但不能保證成交；市價單提高立即成交機率，但不保證價格。Investor.gov 的訂單類型說明也提醒，大單可能分拆在多個價位成交。若要先熟悉 Market、Limit、部分成交與狀態檢查，可參考站內的現貨訂單與成交後驗收流程。
成交後的六步驗收
- 保存送單前的 bid、ask、訂單簿快照、時間與時區。
- 等訂單成為 Filled，或明確記錄 Partially Filled、Canceled 等狀態。
- 匯出每筆 fill 的價格、數量、時間、費用數量與費用資產。
- 重算成交數量、成交額與 VWAP；不要使用最後一筆價格代替均價。
- 分別計算相對最佳價滑點、相對中間價執行成本及手續費。
- 與預設上限比較；超標時記錄原因，暫停同類下單，避免用下一筆交易掩蓋異常。
驗收表至少保留：訂單 ID、方向、送單時間、基準 bid/ask、目標數量、每筆 fill、VWAP、滑點 bps、手續費、總執行成本與是否通過。較大倉位還應把最差合理成交情境放進倉位、壓力測試與再平衡框架，不要只依賴正常時段的一次快照。
常見錯誤
用最新成交價算點差
點差由同一時刻的最佳 bid 與 ask 決定。最新成交價可能在兩者之間，也可能已經落後。
用簡單平均算多筆成交價
不同 fill 的數量不同，必須使用成交量加權均價。最後一筆或價格平均都可能嚴重誤導。
把負滑點一律當錯誤
成交也可能優於基準價，形成價格改善。先確認方向、基準時間與符號定義，再判斷計算是否有誤。
把訂單簿深度當成保證
公開簿是當下狀態，不是鎖定報價。延遲、取消、其他交易與隱藏流動性都可能讓實際 fill 不同。
點差、滑點和手續費重複相加
若已用相對中間價計算執行成本，就不要再加入半點差與相對最佳價滑點。手續費仍需另外加入，因為它不是價格偏離。
來源與核對日期
- Binance Spot REST API 說明：公開市場資料端點、時間格式與資料來源說明。
- 本次 BTC/USDT 公開訂單簿端點：圖表與表格的原始即時來源；重新開啟會得到新快照，不會重現舊數字。
- Coinbase Exchange：Trading：市價單會取用可用流動性，大單可能跨多個價位；限價單控制價格但不保證成交。
- Investor.gov：Understanding Order Types：市價單成交價不保證及大單多價位成交的通用原理。 資料與來源核對時間：2026-09-03T19:15:01+08:00。實際交易前應重新抓取訂單簿、核對產品規則與帳戶費率；本文快照不能當作可執行報價。