只是和同事分一個訂閱，何必背一套沉重系統：SubLane 這則分享，也是一次工具取搗的練習

2026 年 9 月 29 日，開發者 murongxdb 在 V2EX 的「分享創造」板發了一篇帖，談他自己寫的小工具 SubLane。背景很單純：他們組四個人湊錢買了一份 AI 訂閱，原本用 sub2api 這套網關來分配用量，用了小半年，功能齊全，但每次伺服器遷移都得連 Postgres 和 Redis 一起搬。有一次 Redis 因為記憶體超量掛掉，整個網關直接罷工，他排查了半天。後來他想通一件事：四個人的小團隊，用不著這麼重的東西。

於是他用 Go 加 SQLite 自己寫了一個單容器的輕量閘道，前端直接編譯進同一個二進位檔，備份就是備份那個資料卷。開源在 GitHub 上，有興趣的人可以自己去看。

這篇帖和回覆裡，其實藏著幾件和你的日常工作、甚至和「怎麼判讀一個工具值不值得用」有關的事。

共用訂閱的第一個問題：帳號安全

回覆串裡有人問，為什麼不直接把帳號授權給大家登入就好？原 po 的回答很實際：同一個帳號被多人授權登入使用，容易被服務方封號，尤其是 Claude 這類對共用行為比較敏感的服務。

這裡要先說清楚一個前提：多人共用一份訂閱，本身是否違反服務條款，要看各家條款怎麼寫。有的服務允許家庭或團隊方案內的合理共用，有的明文禁止憑證分享。這一點各家說法不一，你自己在做之前，值得把條款翻出來看一眼，而不是只看別人「目前還沒被封」就照做。回覆裡也確實有人說自己用另一個服務「目前好像沒封」，這種經驗談只能代表當下狀態，不能當成保證。

如果你們團隊確實走共用這條路，比較穩的做法是：發給每個人獨立的 key，用量各自紀錄，誰用多了看得到。這也是 SubLane 這類閘道的基本邏輯。至少出了狀況，你知道是哪把 key、哪個環節的問題。

重工具與輕工具，沒有標準答案

回覆裡的討論其實滿誠實的。有人指出類似的輕量網關已經不少，功能還更多、更成熟；也有人擔心，三、四個人的 key 要從 sub2api 遷移過去很麻煩，而且新模型、新功能都得等作者一個人更新，sub2api 那邊更新比較勤。原作者的回應是，新模型走線上更新，維護上就是一個 Go 程式加一個 SQLite 資料庫，他自己修 bug 的速度很快。

這是所有自架工具都會遇到的取捨：輕，意味著你要搬運的東西少、壞掉的環節少；但也意味著生態、更新和長期維護都繫在少數人身上。重，代表功能完整、社羣活躍；但也代表你為了四個人的需求，背著為四十人、四百人設計的複雜度。

這個判斷沒有標準答案，取決於你們要的是什麼。如果你的情境跟原 po 一樣，就四個人、只需要分 key 和看用量，那輕工具的維運負擔確實小很多。如果你們之後可能擴編、需要更細的權限和審計，一開始就選功能全的那套，可能省得日後搬家。

自架服務的身心成本，也值得算進去

原 po 提到一個很有共鳴的細節：Redis 掛掉那次，他排查了半天。這句話背後是很多人熟悉的處境：下班後或週末，因為一套自己其實用不到那麼多功能的系統出狀況，得盯著螢幕找問題。

如果你也有類似經驗，可以反過來想：這套工具替你省下的時間，和它讓你花掉的維運時間，哪邊多？工具的存在是為了讓事情變簡單，當它開始穩定地製造額外工作，那就是一個該重新檢視的訊號。偶爾的故障難免，但「每次遷移就頭痛」「常常要救火」這種模式化的負擔，值得認真對待，而不是當成理所當然。

順帶一提，如果你平常就花不少時間在這類自架服務的折騰上，熬夜追版本更新的你那篇文章裡聊過的作息照顧，同樣適用在這裡。救火盡量留在白天，深夜的故障如果沒有立即影響，先記下來隔天處理，通常不會怎麼樣。

一點資訊識讀的角度

最後提醒一件小事。像這樣的開源專案分享，看到時可以先確認幾件事：程式碼是否真的開源可查、作者過往的維護紀錄如何、有沒有 demo 可以實際試用。原 po 在回覆裡被問到 demo，也坦承這點還沒做好、這幾天會補上，這種誠實回應是好事。

另外，這類閘道會經手你的訂閱憑證，屬於敏感資訊。作者說憑證加密、不放進 SDK 的管理器，這是設計上的用心，但對使用者來說，更務實的做法仍是：用之前自己看一下程式碼結構，或至少看看社羣裡有沒有其他人審視過。開源不等於自動安全，它只是給了你檢視的可能。

四個人分一個訂閱，聽起來是小事。但從條款確認、key 管理、工具取捨到維運負擔，每一步都是可以做得更清楚的選擇。工具輕重沒有對錯，知道自己要什麼，才是那個真正省心的答案。