群益API 訂閱額度有多少？為什麼「沒報錯」不代表全部訂上了

訂到一半就沒反應了：前面幾檔正常，後面加的沒有資料，而且沒有任何錯誤。

多數人這時會去翻程式、查連線、懷疑代碼寫錯。但如果你正在訂第 101 檔，問題可能不在程式，而是群益API 訂閱額度到了——而它不會告訴你。

群益API 訂閱額度有多少？兩層各有各的數字

群益API 訂閱額度分成兩份、分開計算，數字都寫在官方元件說明文件裡：

層	訂閱函式	額度
快照層	`SKQuoteLib_RequestStocks`	100 檔
深度層	`SKQuoteLib_RequestTicks`	10 檔

兩層的用途差別在上一篇講過（只要價走快照層、要五檔的量或逐筆明細才用深度層）。這裡要補的是：深度層只有 10 檔，是真的很少。拿它來看「最新價」，等於用十分之一的稀缺資源去做快照層一百檔都做得到的事。

額度綁在單一 SKQuoteLib 物件上。 官方對此另有一條限制——依官方說明，因應檔數限制，一個 SKQuoteLib 物件僅可擇一使用一個即時報價訂閱功能（SKQuoteLib_RequestStocks 或 SKQuoteLib_RequestStocksWithMarketNo），不能兩個都用。

官方還寫了一句：可重新連線即還原限制與設定。

這句話容易被讀反，所以要把操作意義講清楚：它的意思是斷線重連之後，你原本的訂閱都沒了，得自己重新訂回來——限制回到初始狀態，你的訂閱也一起歸零。那是重連之後要補訂的原因，不是一種繞過額度的方法。

超過額度時，兩層的反應完全不同

這是本篇最重要的一段：兩層在群益API 訂閱額度用完時的行為完全不對稱。

快照層：官方明文說它什麼都不說。 手冊裡有兩句：

如果帶入的股票數超過100檔，則僅以100檔處理，並不會回傳錯誤。

如果帶入的股票代號不存在，則會直接略過不處理，也不會回傳錯誤。

深度層：有專屬的錯誤碼。 超過可訂閱檔數時會拿到 3027（SK_SUBJECT_TICK_LIMIT_EXCEED），官方說明是「超過可訂閱 TICK／Best5／Best10 商品檔數。」

同樣是超額，快照層什麼都不說，深度層會給你一個碼。

由此推出一句對讀者最有用的話：在快照層，「沒有錯誤」不等於「全部訂上了」。

你送出一份 120 檔的清單，函式回傳成功——實際上只有前 100 檔生效，後 20 檔靜靜被丟掉。你送出一份含三個打錯代碼的清單，函式一樣回傳成功——那三檔直接略過。兩種情況你都不會收到任何訊號。

（上面兩句是官方文件的敘述。超過額度之後元件的實際行為是否完全如此，我們沒有實測過，這裡照官方說法陳述。）

快照層只有一頁：每次都要整批帶齊

群益API 訂閱額度之外，快照層還有一個限制——頁號。官方對 RequestStocks 的頁號寫得很明確：

一般用戶目前PageNo上限為1

也就是說你只有一頁可用。這件事決定了快照層的使用方式：每次刷新都要把完整清單一次帶齊，不能分批往同一頁追加——後送的那份會取代先送的，而不是加上去。

（深度層相反：頁號從 0 開始、一個 Page 只能訂一檔，那是上一篇的主題。）

所以快照層的心智模型是「整批覆蓋」，不是「逐檔加訂」。想多看一檔，要把原本的 99 檔連同新的那檔一起重送。

那要怎麼確認群益API 訂閱額度到底用掉多少？

既然快照層超額與代碼錯誤都不回報，回傳碼就不能拿來判斷訂閱是否完整。

// 快照層只有一頁：每次都把完整清單一次帶齊，不要分批加到同一頁
short page = 1;                                  // 官方：一般用戶 PageNo 上限為 1
string all = string.Join(",", watchList);        // watchList 已自行控制在 100 檔內

int nCode = m_pSKQuote.SKQuoteLib_RequestStocks(ref page, all);
// ⚠️ nCode == 0 不代表整份清單都訂上了
//    依官方說明：超過 100 檔只取前 100 檔、代號不存在直接略過，兩者都不回傳錯誤
//    要確認實際訂上幾檔，只能自己統計後續收到報價的商品數

唯一可靠的驗證方式，是自己數收到報價的商品數。

實務上的做法是：送出訂閱後記下你送了哪些代碼，然後在報價事件進來時把「實際有回報價的代碼」收集起來，兩邊比對。差集就是沒訂上的那些——可能是超額被截掉，也可能是代碼根本不存在。

這一步花不了多少程式碼，但它把一個「永遠查不出原因」的狀況變成一份清單。

自己包一層服務，不會變出額度

很多人會想到這個辦法：既然群益API 訂閱額度有限，那我寫一支程式負責訂閱，再把報價轉發給其他程式用，這樣是不是就繞過去了？

不會——因為橋接沒有新增任何訂閱。

它轉發的是你已經訂到的那份資料。從頭到尾只有那層服務在訂閱，它自己就要佔掉那 100 檔與 10 檔，下游所有程式共用的還是同一份。沒有新增訂閱，額度就連動都不會動。

而且中間多一跳轉發，就多一份延遲——你付出了架構複雜度，換到的額度是零。

橋接架構仍然有它合理的用途——例如讓非 Windows 的程式也能取得報價，或者集中管理連線。但它解決的是「誰能拿到資料」，不是「能拿到多少檔」——群益API 訂閱額度不在它的解決範圍內。

額度不夠用的時候，剩下的選擇是輪替

如果你要監看的數量本來就超過群益API 訂閱額度，那沒有技術手段可以變出更多——只能決定此刻誰在線上。

方向是：

先分層。只要價的放快照層，把深度層那 10 檔留給真正需要五檔或逐筆明細的商品。
只讓真正需要的在線上。不在關注焦點的商品先退訂，需要時再訂回來。
退訂要確實釋放。深度層退訂之後才空得出那一檔的額度，如果你的程式沒有把頁號釋放回去，額度會被佔著不放。

至於輪替怎麼排程、用什麼結構管理、什麼條件下換人上線，那是你的應用邏輯，取決於你的策略在看什麼。這篇能給的是限制的形狀，怎麼在限制裡安排是你的自由。

常見問題

群益API 訂閱額度是多少？兩層共用嗎？

不共用。依官方說明，快照層 RequestStocks 是 100 檔，深度層 RequestTicks 是 10 檔，兩層分開計算。額度綁在單一 SKQuoteLib 物件上。

群益API 訂閱額度用完時沒有回傳錯誤，是不是代表全部都訂上了？

不是。官方明文寫超過 100 檔只取前 100 檔、代號不存在直接略過，兩者都不回傳錯誤。要確認實際訂上幾檔，只能自己統計收到報價的商品數。

3027 是什麼意思？

SK_SUBJECT_TICK_LIMIT_EXCEED，官方說明是「超過可訂閱 TICK／Best5／Best10 商品檔數」。它是深度層的超額回報——快照層超額不會給你這種碼。

快照層可以分批訂閱，一次加幾檔嗎？

不行。一般用戶只有一頁，後送的清單會取代先送的。每次都要把完整清單一次帶齊。

自己寫一個服務轉發報價，可以突破群益API 訂閱額度嗎？

不行。橋接轉發的是你已經訂到的資料，沒有新增任何一筆訂閱——那層服務自己就要佔掉額度，下游共用的還是同一份。橋接解決的是「誰能拿到資料」，不是「能拿到多少檔」。

風險揭露

期貨與選擇權屬高槓桿商品，價格波動可能造成超過原始保證金的損失，交易人須自負交易責任。本文為程式開發技術教學，說明報價訂閱額度的限制與確認方式，不構成投資建議，也不保證任何交易結果。程式化交易並不降低市場風險，反而可能因程式錯誤造成非預期的委託行為——誤以為訂閱完整而實際缺漏，正是這類錯誤的來源之一。

投資人教育資源

機構	資源
臺灣期貨交易所（TAIFEX）	期貨及選擇權數位學習網
證券暨期貨市場發展基金會	證券期貨市場教育推廣
金融智慧網	金管會金融知識平台
中華民國期貨業商業同業公會	期貨業法規與宣導
證券投資人及期貨交易人保護中心	投資人保護與申訴

參考資料

額度數字（快照層 100 檔、深度層 10 檔）、psPageNo 上限、擇一使用的限制、超過檔數與代號不存在時的處理、重新連線還原限制，均依群益官方元件說明文件。
3027（SK_SUBJECT_TICK_LIMIT_EXCEED）常數名與說明出自官方錯誤碼表。
超過額度之後元件的實際行為，我方未實測，本文照官方說法陳述。
橋接不會增加額度：轉發既有資料不構成新的訂閱，故不消耗額外額度。

免責聲明

本文章僅作為群益API實作經驗分享，不構成投資建議，且策略及程式皆應自行撰寫。期貨及衍生性金融商品交易屬高風險投資，請謹慎評估自身風險承擔能力。