矽基流動金鑰聚合腳本實測：多把金鑰併成一個入口的三個前提

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

手上有好幾把矽基流動（SiliconFlow）API 金鑰的人，多半遇過同一個麻煩：不同專案各自綁一把金鑰，哪把快沒額度要一個一個登入查，程式呼叫時還得記住每把鑰匙對應哪個環境。GitHub 上 325 星的開源專案 Siliconflow-API-Management 把這件事變成一個貼上 Cloudflare 就能跑的網頁系統：所有金鑰丟進一個池，對外只給一個代理網址和一支代理金鑰，請求進來自動挑一把可用的金鑰轉發，管理介面順便把每把金鑰的餘額與狀態畫成圖表。我把它的兩個 worker 原始檔從頭到尾讀完、對照 2026 年 2 月那次安全修補前後的差異、再實測官方示範站的行為之後，結論是能用，但有三個前提：你拿到的是修補後的版本、你改掉了預設的全開模式、你把它的負載均衡當成隨機抽籤而不是聰明調度。

一個檔案貼上 Cloudflare 就能跑，簡單到沒有版本號可以對

整個專案沒有安裝程式、沒有套件依賴，全部內容是兩個 JavaScript 檔案：KV 版約 232 KB，D1 版約 264 KB，從後端邏輯到管理介面的 HTML、CSS 全部包在同一個檔案裡。部署方式照 README 的說法，是在 Cloudflare Workers 後台開一個 Worker、把檔案全文貼進編輯器、綁好 KV 空間或 D1 資料庫就上線。金鑰就存在你自己 Cloudflare 帳號的 KV 或 D1 裡，資料落地在自己家，這個邊界是清楚的。這種單檔設計對不熟指令列的人非常友善，也是它能在中文圈傳開的原因。

管理介面有一定的完成度。儀表板首頁放四張統計卡片：金鑰總數、有效數、無效數、平均餘額，下方是最近添加的金鑰列表，搭配餘額分布圖與趨勢圖；金鑰管理頁支援批次貼上、多選操作、依餘額排序與條件匯出。從作者展示的截圖看，一個管理兩百把上下金鑰的池子，資訊密度是夠的。

Pin

代價跟著而來：這種專案天生沒有版本號。整個 repo 沒有任何 tag 與 release，20 個 commit 有 18 個集中在 2025 年 3 月的一週內，再次出現已是 2026 年 2 月由外部貢獻者送來的安全修復，之後就停了。你從網頁複製檔案的那一刻，拿到的是哪個時點的程式碼，沒有任何機制告訴你。這件事平常只是小困擾，但 2026 年 2 月之後，它變成了安全問題。

2026 年 2 月之前，管理介面的整組 API 不設防

修補前的程式碼我逐行讀過，狀況比多數人想像的嚴重。這套系統的管理功能全部走 /admin/api/ 下的 HTTP 端點：讀設定、加金鑰、刪金鑰、改管理員密碼、觸發餘額檢測，每一個都是。舊版裡，讀取設定的端點完全沒有驗證身分，任何知道網址的人發一個 GET 請求，回應就是完整設定內容：管理員帳號、管理員密碼、代理金鑰、訪客密碼，全部明文。寫入端點更關鍵，新增金鑰、刪除金鑰、更新設定同樣不檢查身分，等於任何人都能把你的管理員密碼改成他的，接管整個系統，再把金鑰池整批匯出帶走。檔案開頭的預設存取模式又是完全開放，剛部署、還沒進後台設定的站，前台直接把金鑰列表連餘額公開給所有訪客看。

2026 年 2 月 9 日，一位外部貢獻者送出合併請求，修掉這批問題：所有管理端點加上統一的身分驗證閘門，訪客只能唯讀瀏覽金鑰列表，設定回應改為只回傳必要欄位、任何密碼一律不回傳，輸入也補上型別檢查。作者在 3 月 17 日把它合併進主線。修得算乾淨，問題是幾乎沒有人會知道這件事：README 對這次修補隻字未提，沒有 release note，沒有版本標籤。到 2026 年 9 月為止，四個開啟的 issue 沒有任何一個得到作者回覆，最早的一條從 2025 年 3 月掛到現在。修補存在的事實，只藏在 commit 歷史裡。

官方示範站到今天還在跑修補前的版本

最有說服力的證據來自作者自己。2026 年 9 月 19 日我對 README 列出的 KV 示範站發了一個不帶任何帳密的 GET 請求，讀取設定的端點直接回 HTTP 200，回應內容就是前面說的那幾項憑證，管理員帳號密碼、代理金鑰、訪客密碼全在裡面。同一個站的金鑰列表端點回 401，因為站方設了訪客密碼模式。這個行為組合與修復前的舊碼完全吻合，更新後的版本會把設定端點一起擋下。也就是說，作者把修復合進主線之後過了半年，自己的示範站還在跑有洞的舊版。憑證內容不會在這裡重現，我也沒有拿它登入任何地方，重點是狀態本身：連專案作者都沒更新，示範站的存在就不能當成這種部署方式安全沒事的保證。

Pin

這個發現對使用者的意義很直接。網路上任何一個用這套系統架的站，你無法從外觀分辨它是修復前還是修復後，71 個 fork 裡有多少還在跑舊碼也沒有人知道。把自己的矽基流動金鑰加進別人架的站，等於把金鑰交給一個你無法驗證版本、也無法驗證誠信的管理員。README 明白寫著示範站的訪客密碼要寫信跟管理員索取，這種服務形態本身就是把信任交出去的行為，省的是自己的部署工，押上是整池金鑰。

智慧負載均衡的真面目：從可用金鑰裡隨機抽一把

README 說這套系統用智慧負載均衡演算法自動選擇可用的金鑰。程式碼裡的實作是另一回事：挑金鑰的邏輯是把餘額大於零的金鑰列出來，用亂數抽一把，結束。沒有權重、沒有輪詢、沒有延遲偵測，被抽中的金鑰剛好失效，這個請求就把錯誤原樣回給你，不會自動換一把重試。所謂單一金鑰故障不影響服務，正確的理解是下一個請求有機會抽到別把，單一請求的容錯是零。對穩定性有要求的用法，重試要自己在應用層補。

餘額過濾還有一個實際會踩的坑：金鑰新增時餘額預設是零，而餘額等於零的金鑰永遠不會被抽中。照介面把金鑰貼進去、沒按檢測，等於整批金鑰都不在輪選池裡，打代理只會收到沒有可用金鑰的 503 錯誤。2025 年 5 月就有人在 issue 提出另一面：餘額用完的金鑰其實還能呼叫免費模型，這個過濾把它們全部排除掉了，這個建議掛了一年多沒有下文。主要用免費模型的人，要特別記得這個預設行為。

轉發層還有兩個值得知道的細節。代理端點的 CORS 設定對所有網域開放，代理網址加代理金鑰一旦外流，任何網頁都能直接從瀏覽器呼叫你的池子，不必經過你自己的站。串流回應倒是完整支援，請求怎麼進來就怎麼轉到矽基流動的 API，串流的輸出不會被拆掉。

餘額檢測不是免費操作：每按一次就是一個真實的推理請求

管理流程的核心動作是檢測，這裡的實作值得每個使用者先知道再按下去：判斷一把金鑰是否有效的方法，是拿它真實呼叫一次對話完成 API，模型固定、上限一百個 token，接著再查一次使用者資訊端點拿餘額。換句話說，批次檢測兩百把金鑰，就是兩百個真實的推理請求加兩百次資訊查詢，額度是真的會扣的。介面提供固定間隔與隨機間隔兩種節奏、可中途停止，這些設計本質上都是在控制這個成本。還有一個 D1 版才有的客戶端直連模式，把全部金鑰送到管理者的瀏覽器、由瀏覽器直接打矽基流動的 API，速度是快，但金鑰離開了 Worker，進到每一個開著管理頁的分頁記憶體裡。

檢測功能還面對一個專案本身控制不了的變數。2026 年 1 月有使用者在 issue 回報，矽基流動把餘額制改成了代金券制，這套系統的餘額查詢跟著失效，留言的結論是自己想辦法改。專案在 2026 年 3 月後沒有再更新，所以今天部署的人，檢測與圖表功能對現行 API 是否還完全正常，要自己驗一次再依賴它。這裡講的是 issue 裡的使用者回報現象，餘額 API 現在的實際行為我沒有驗證。

照 README 部署之前，先補上它沒講的檢查

README 的部署教學本身寫得算清楚，建資料庫、貼檔案、綁定、改密碼都有截圖步驟，但它假設你拿到的檔案是最新版，也沒有把初始設定的順序風險講透。以下是教學沒涵蓋、我會在貼上檔案之前做完的檢查。

• 確認檔案來源與時間：直接從 repo 主線下載，確認內容包含 2026 年 3 月 17 日的安全修補。任何二手轉載、來路不明的同款檔案都不要用，官方示範站就是活生生的例子。
• 先改預設再部署：檔案最上方的設定區有預設管理員帳號、密碼與代理金鑰，存取模式預設完全開放。在貼上 Cloudflare 之前就把這些改成自己的值，比部署後再進後台改少一段裸奔上線的時間。
• 存取模式選受限或私有：除非你就是要做公開分享站，完全開放會把金鑰列表連餘額直接攤在首頁。
• 儲存選 D1 不選 KV：這是作者自己標註的建議，KV 免費額度的讀寫上限在金鑰多、檢測頻繁時會撞牆。
• 部署完先驗行為：不帶帳密打管理端點應該回 401；金鑰還沒檢測過餘額時打代理會回 503，這是正常行為不是故障；按一次檢測看餘額欄位有沒有正常更新，沒有更新可能就是代金券那個相容性問題。

自架的前提是金鑰全屬於你，規模拉大就該換工具

適合的人很明確：手上有好幾把自己的矽基流動金鑰、想統一看餘額與狀態、願意花半小時摸懂 Cloudflare 後台的人。自架的核心價值是金鑰不出你自己的帳號，D1 資料庫就是你的金鑰保管箱。同樣的需求要拉到多人計費、通路分發的規模，站上先前介紹過的 New API 開源管理平台功能完整得多，代價是部署與維護的重量高一個等級；只想快速確認一把金鑰能不能用、延遲多少，API 測試工具更輕。想把模型接進自己的網站，也可以看自架 ChatWiki 那條路。

不適合的情境同樣清楚。把金鑰加進別人架好的同款站，等於把金鑰交給無法驗證版本的陌生人，這篇文章前半段的發現就是原因。對穩定性要求高的正式環境，隨機抽選加零重試的轉發層需要你在上層自己補重試邏輯，補不了就換更完整的閘道方案。要管理的金鑰不屬於矽基流動也不行，轉發端點全部寫死，2026 年 5 月有人詢問能不能支援其他供應商，至今沒有回應。

MIT 授權能商用，但別期待它會再更新

授權是 MIT，商用與修改都沒有問題。專案狀態要分兩面看：功能本身是完成品，管理介面、圖表、批次操作都有一定水準；維護面是停滯的，最後一次 commit 停在 2026 年 3 月那次安全修復，作者在 README 的未來規劃欄寫著最近事多先擱著，issue 全數未回。介面文字是簡體中文，繁中環境使用不影響功能，看個人接受度。拿來自架管理自己的金鑰，它是能用的工具；把它當成有人持續維護、出事會修的產品，現階段不是。