Mybili 開源 B 站收藏夾備份工具，把會消失的收藏自動存進 NAS

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

在 B 站按過收藏的影片，沒有一支在合約上屬於你。UP 主刪稿、版權方下架、帳號被封，收藏夾裡那格縮圖就變成一片灰色的「已失效影片」。開源專案 Mybili 的 GitHub 副標先寫明自己是 B 站收藏夾備份程式，接著用一句日文感嘆詞「アレ」帶出影片不見了的錯愕，整個專案就是為了這個瞬間存在的：趁影片還在，先把你自己那份備份抓下來。

Mybili 是一款用 PHP（Laravel 框架）寫的 bilibili 收藏夾備份程式，MIT 授權，設計目標是部署在 NAS 上長期跑。它定時讀取你的收藏夾清單，把標題、簡介、封面先存進自己的資料庫，再照佇列把影片檔案一份份抓到本地硬碟。收藏的內容什麼時候消失沒人知道，但消失之後才想備份，一切都晚了。這是它與一般「想下載就手動貼網址」工具最根本的差別。

Pin

收藏清單是你的，影片卻隨時可以不是

多數人對「收藏」的理解是「存起來以後看」，實際機制比較接近「記了一個隨時可被收回的連結」。平台上每一支影片的可見性由上傳者與版權狀態決定，按收藏只是把影片編號加進你的清單，並沒有複製任何內容。這也是為什麼老帳號打開多年前的收藏夾，常常一整頁都是失效條目。

想要留底的讀者，過去常見做法是裝個瀏覽器擴充功能，或把網址貼進下載網站，一支一支手動處理。這條路有兩個無解的問題：失效不會通知你，發現時已經來不及；收藏量一大，人力也完全不現實。TechMoon 先前介紹過的 bilive 處理直播這種「錯過即消失」的內容，bilibili-history-fetcher 處理觀看紀錄的留存，Mybili 補上的位置則是收藏夾。三個工具面對的其實是同一件事：平台不替你保管回憶。

從同步到失聯警報：原始碼裡的三段循環

從原始碼看，Mybili 的核心是一條「同步、下載、失聯處理」的循環，三段各有對應的排程與資料表，全都攤在程式裡。

同步段由 Laravel 排程器驅動。README 寫「定時 5 分鐘獲取收藏夾所有影片」，但排程設定檔 routes/console.php 裡，收藏夾列表、收藏夾影片第一頁與訂閱更新三個任務實際都是每 10 分鐘跑一次，每天凌晨四點另有一次完整掃描與失效修復。文件與程式的頻率差了一倍，功能不受影響，但看得出文件沒有跟著程式走。

下載段把每一支影片交給 yt-dlp 處理。下載指令寫在程式的下載動作裡（下載腳本 download-video.sh 也留有同一組參數），格式是 bestvideo+bestaudio/best，並帶著你的 cookie 去請求。這表示畫質上限完全由帳號決定：一般帳號拿得到 1080P，大會員才拿得到 4K 與高更新率內容，工具本身不做任何破解。併發預設同時跑 10 個任務，下載佇列每分鐘消費一次；收藏夾裡的 B 站音訊區內容在佇列裡是獨立的任務類型，走專屬的下載流程抓最高品質音軌。幾個貼心的細節也寫在程式裡：每個檔案落地時附一份 sha256 記錄檔，重新掃描時以這份記錄的存在判斷影片是否已完整下載過（不做內容重算）；設定裡有一欄標題排除規則，符合關鍵字的影片會自動跳過，不想備份的內容不用先刪收藏。

第三段最有意思：失聯偵測。程式在拉取影片資訊時檢查 B 站 API 回傳的稿件狀態，一旦不為零（稿件不可見、審核中、僅上傳者本人可見等），就標記為失效。此時如果本地已有下載檔案，該影片會被凍結並觸發一則 Telegram 通知（若已設定 Telegram Bot），附上檔案大小與總時長，等於系統主動告訴你「這支影片線上已經沒了，還好你有一份」。反過來說，從未下載過就失效的影片只會被靜靜標記，什麼也救不回來。備份的價值全在事前，這段程式邏輯把它說得很清楚。

彈幕也在備份範圍內。設定開啟後，每支影片的彈幕會完整寫進資料庫，web 介面播放時可以直接掛上；2026 年 3 月的 v1.5.0 又補了彈幕更新功能，已下載的影片可以排隊補抓最新進來的彈幕。對於把彈幕當作品一部分的觀眾，這個細節頗有誠意。

「最高畫質」四個字，前提寫在你的 cookie 裡

README 承諾「按照最高畫質下載」，這句話成立的條件是 cookie 一直有效。B 站網頁版的工作階段有保存期限，過期之後 yt-dlp 只能以訪客身分拿低解析度格式，於是出現一種很實際的坑：過期那幾天同步進來的影片，全部以 480P 之類的訪客畫質落了地。GitHub issue #78 記錄的正是這個狀況，使用者問更新 cookie 之後能不能重抓高畫質版本。答案是現有檔案不會自動升級，因為下載完成後，程式看到本地檔案存在就直接跳過重抓。

官方對 cookie 過期的解法很誠實地寫在 README 裡：手動匯出的 Netscape 格式 cookie「幾天後自動過期」，長期方案是作者自己寫的 mybili-cookie 瀏覽器擴充功能，在背景把登入狀態自動同步給 Mybili 伺服器。作者在文件裡把原因說白了：網頁版同時在用會不斷換發新的短時 token，Mybili 若自己去取，代價是你的網頁版被踢下線，兩個方案各有各的麻煩。這個擴充功能不以商店形式散佈，而是要下載原始碼、打開開發人員模式手動載入。信任鏈於是多了一環：你的 B 站登入憑證，同時交給 NAS 上的容器和瀏覽器裡的擴充功能。

一個 Docker 容器、一份 SQLite，和給 Emby 的硬連結

部署面走 Docker Compose：Mybili 本體加一個 Redis（只做臨時快取與非同步佇列，不做持久化），資料庫用 SQLite 存在掛載的 /data 儲存卷裡，影片落在另一個掛載目錄。容器內部吃 80 埠，對外映射到 5151，裝起來就是一個開箱即用的 web 介面，可以瀏覽收藏清單、線上播放已下載的影片，也能手動取消或重試佇列裡的任務。

Pin

對於把 NAS 當媒體庫用的讀者，它還有一層貼心設計：原始檔以影片 id 命名存放，另有一個可開啟的「人類可讀目錄」功能，用硬連結把影片與封面組織成 movies（單 P）與 tvs（多 P 影集）兩種 Emby 慣用結構，硬連結不佔額外空間。要注意這個目錄照排程固定重新生成，每次都會先清空底下的子資料夾再重建，放進子資料夾的任何東西都會被刪掉，它只認程式自己生成的結構。

除了收藏夾，設定頁也能直接訂閱特定 UP 主或合集，排程每 10 分鐘檢查一次新片並自動排進下載佇列。這個功能讓它從「備份工具」往「訂閱下載器」多跨了半步，社群裡也確實有人希望它走得更遠（後面 issue 段會提到）。升級方式同樣簡單：映像有新版本時拉回來重建容器即可，資料都在掛載的儲存空間裡，程式自己不留狀態。

把帳號鑰匙交出去之前，先看清三件事

這是全文最需要停下來想的一段。Mybili 的 web 介面與 API 完全沒有登入機制。原始碼 bootstrap/app.php 裡，API 中介層只掛了強制 JSON 回應，cookie 上傳、設定讀寫、收藏清單、下載佇列全部裸奔。部署說明假設你放在家用區網，這個假設成立時一切合理；一旦 5151 埠被映射到公網或不可信網段，任何掃到這個埠的人都能讀你的收藏清單、覆蓋你的設定，甚至換掉你的 cookie。比起 TechMoon 寫過的 quark-auto-save 出廠就帶預設帳密的管理介面，這裡連預設密碼都沒有，因為根本沒有密碼這一層。

再看憑證的存放。你的完整登入憑證以明文存在 SQLite 資料庫裡，下載時再落地成 storage/app/cookie.txt 餵給 yt-dlp。拿到這份檔案的人等於拿到你的 B 站帳號。容器、掛載目錄與備份的存取權限，都要按「裡面有一份帳號密碼」的標準來設。

還有一件事最容易被忽略：官方 Docker 映像內建遙測。原始碼裡的 UsageStatisticsService 會每天向作者的 umami 統計服務回報一次，內容包含一組隨機產生的 UUID、程式版本、執行環境、作業系統與 PHP 版本、是否在 Docker 中執行，外加服務網址設定值。從原始碼自行建置時這個功能預設關閉（設定值預設空字串），但 CI 設定檔在打包官方映像時注入了統計站 ID。照著 README 用官方映像部署的人，這個回報就是開的；README 對此一字未提。設定介面裡其實有一個「使用情況統計」開關（預設開啟），但關掉它只會停掉網頁端的統計訊標，後端每日回報只認建置時注入的統計站 ID，想真正關掉還是得覆蓋環境變數或自己建置映像。資料本身匿名、不含帳號資訊，每日一次的量也談不上監控，但「工具會向作者回話」這件事，使用者有權在部署前知道。對於把這套工具放進長期運轉的 NAS 的人，這類小數累積的資訊流出，值得在部署的第一天就想清楚。

帳號紅線與版權紅線

用 cookie 大量抓取平台的內容，帳號風險是躲不掉的議題。程式自己也明白：下載請求碰到 B 站回 412（平台判定請求過於頻繁）時，會自動暫停相關工作佇列兩小時再恢復，等於內建了一套熔斷節流。這個機制保護的是「不要抓太猛」，沒有任何工具能保證帳號不被平台處置。收藏夾 API 呼叫與影片下載量級越大，風險越高，這條線要自己拿捏。

版權則是另一條更清楚的線。MIT 授權涵蓋的是程式碼本身，下載到硬碟裡的影片版權仍屬於原權利人。把自己收藏的內容留一份在自家 NAS 上看，與把檔案再分享出去，是法律性質完全不同的兩件事，後者無論在哪個司法管轄區都站不住腳。工具給了你複製的能力，邊界仍然要自己畫。

issue 迴響裡的真實痛點

看一個自架工具的成熟度，開放 issue 清單往往比行銷頁面誠實。目前 13 個開放議題裡，幾個高互動的值得部署前知道：#62 反映下載完成的影片檔案偶爾損壞（7 則留言），#67 反映升級版本後封面全部丟失（15 則留言），#77 則是部分影片始終快取不下來。功能請求方向的 #83（自動下載全部關注的 UP 主）有 8 則留言，顯示重度使用者的胃口遠超過收藏夾備份這個定位；也有人直接要求支援 cookiecloud 這類憑證同步服務（#21），背後同樣是 cookie 過期這個最大痛點。

這些數字對照 703 顆星與仍在推進的維護節奏（2026 年 2 月與 3 月接連發布 v1.4.3、v1.5.0，7 月底修了封面載入例外，8 月中仍有維護提交），可以看出這是一個活著的單人專案：不是棄坑，也還沒到工業級穩定。尤其下載檔案的完整性只看記錄檔存在、不做內容重算，與前面 #62 的損壞回報放在一起看，備份結果更需要抽查，不能全信綠燈。

誰該裝，誰該繞開

適合的族群很具體：收藏夾裡有大量捨不得失效的內容、家裡有常開的 NAS 或小主機、懂得把服務關在區網內、願意接受「帳號 cookie 放進容器」這個前提的人。對這群讀者，失聯凍結加 Telegram 警報這一整套流程，市面上同類工具很少做到這個完整度；再配上 Emby 目錄與彈幕備份，它更接近一套小型私人媒體庫的骨架。

反過來，如果你只是想偶爾抓幾支影片、沒有常開機器，或是不放心把登入憑證交給第三方程式，手動的下載工具已經夠用，上 Docker 加 redis 的重量並不值得。至於把 5151 埠直接開上公網遠端存取的用法，請直接打消念頭：這個服務的防護模型裡根本沒有那一層。想知道自己帳號在平台留下的痕跡有多深，可以參考先前的 aicu 一文，讀完對「交出 cookie」這件事會更有感覺。

留檔備份的真正成本，從來不是磁碟空間，而是你願意為「不消失」付出多少信任。Mybili 把技術那一半做得相當完整，信任那一半的帳，部署前要自己算清楚。