B 站影片下載器 BiliVideoDown，857 顆星卻從沒發過安裝包

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

想找 B 站影片下載器的人，遲早會在搜尋結果裡撞到 BiliVideoDown 這個名字：一個用 Flutter 開發的桌面下載器，支援 Windows 與 macOS，GitHub 上 857 顆星（2026 年 10 月數字）。先把最影響判斷的事實講在前面：這個專案從 2024 年 6 月誕生到現在，沒有發佈過任何一個安裝包。Releases 頁面是空的，版本標籤一個都沒有，打包用的自動化流程從未執行過。你能取得的只有原始碼，想用，就得自己架 Flutter 開發環境把它編譯出來。這篇的判斷都來自原始碼、完整 commit 與 issue 歷史，以及對它依賴的 B 站端點的實際檢視；App 本體我沒有編譯執行，執行面的速度與成功率不在結論裡。

Pin

這種「星數很高、看起來能裝」的項目特別容易讓人誤判，因為星數量的是關注，不是可安裝性。857 顆星對應的投入是：一位開發者、斷斷續續五段合計約三週的開發、最後一筆之後一年半的靜默。看到名字想裝來用之前，先知道自己在拿什麼，比什麼都省時間。

看起來像搜尋框，其實在等你貼連結

打開官方釋出的介面截圖，最上方是一個輸入框和一顆按鈕，看起來像關鍵字搜尋。原始碼顯示它等的是別的東西：程式用一段規則運算式，從輸入文字裡抓 BV 開頭的影片編號（B 站網址裡那串代碼），抓不到就跳「連結錯誤」的提示。換句話說，你要先在 B 站把影片或合集網址複製好，回來貼上，它才有辦法動作。它不是搜尋引擎，是貼連結的下載器，這個差異決定了它的使用節奏：找片在 B 站，下載才回這裡。

貼上之後，程式向 B 站的公開影片資訊端點要基本資料：標題、封面、發布時間、片長，以及這支影片隸屬的合集。合集是 B 站創作者把系列影片綁在一起的形式，教學、連載、課堂錄影常這樣整理；對下載器來說，合集幾乎是唯一有意義的批次單位。如果偵測到合集，它會列出選集清單讓你勾選。這裡有個實作上的限制值得知道：清單只讀合集的第一個分區，分成多個分區的大型合集，後面分區的影片不會出現在畫面上。勾選完按下一步，項目進入待下載佇列，接著逐一抓檔，全部完成後從佇列移進歷史清單。

下載這步走 B 站的播放位址端點，參數全部寫死在程式裡：畫質要求 qn=80（對應 1080p 等級）、平台指定 html5、再加一個高畫質旗標。接著程式只取回應清單裡的第一段串流網址，交給分塊下載器抓回來，存成「下載合集＋日期」命名的資料夾裡的 mp4 檔，檔名直接用影片標題（資料夾名在程式碼裡也是簡體字，會原樣出現在你的磁碟上）。整份依賴清單裡沒有 FFmpeg，也就是說它不做「影像與聲音分開抓、再合併」那套工程，伺服器端給它什麼單檔，它就存什麼。

官方畫面：待下載、下載中、已下載三個分頁

從官方截圖看操作全貌：選集清單每一列有封面縮圖、標題、發布日期、檔案大小與片長，勾選後送進下載佇列；下載管理視窗用三個分頁分待下載、下載中、已下載，每列可以暫停或移除。下載中的項目有進度條與已下載量的即時數字，完成的項目會記進下載歷史（存在本機的 SQLite 資料庫裡，不經過任何雲端）。這點是桌面工具該有的樣子。原始碼裡還有一個內建預覽播放器，下載前可以先看片段，不過這部分我沒有實際操作過，實際體驗以你自己的編譯結果為準。

介面只有簡體中文。按鈕與分頁名稱在畫面上全是簡體字，整份依賴清單裡也找不到任何在地化套件，繁中介面不在這個專案的選項裡。對台灣使用者來說，這一點要當成使用前提吞下去，沒有哪個設定能把介面變成繁中。

Pin

網路行為倒是乾淨得出奇。整個專案的對外端點常數只有兩個：影片資訊與播放位址，都在 B 站自己的網域下；依賴清單裡沒有任何統計、廣告或遙測套件，也就沒有背景資料上傳這回事。它連 B 站的會員登入都不做，自然也就拿不到你的帳號資訊。以「這支程式會碰什麼」的標準看，答案單純：B 站的兩個查詢端點、影片 CDN、你自己的硬碟。

全程匿名：沒有登入、沒有 cookie，畫質讓伺服器決定

匿名是這個工具最核心的設計選擇，也是它能力上限的來源。整份程式碼裡找不到登入流程，設定儲存只有兩個鍵：深色模式與下載資料夾；HTTP 層連自訂的瀏覽器標頭都沒設，請求以開發框架的預設身分發出去。B 站對匿名請求給什麼，它就收什麼。

後果有兩個。畫質方面，2024 年 7 月就有使用者反映無法選畫質（issue 編號 1），那個 issue 後來被關閉了，但對照原始碼，到最後一個 commit 為止都沒有出現畫質選擇介面；程式寫死的 qn=80 只是「許願」的參數，匿名請求實際拿到哪一檔畫質，由 B 站伺服器單方面決定，程式端沒有施力點。完整性方面，部分較舊的 B 站影片，播放位址會把影片切成多段，這支程式固定只抓第一段，遇到這類影片，存下來的檔案就是不完整的。

這條匿名路線在 2026 年還通不通，是更大的問號。我在 2026 年 10 月從自己的機器，以瀏覽器身分重打了這條流程的第一步：影片資訊端點給我的答覆是 B 站的錯誤頁面，換成在真實瀏覽器頁面裡發請求，結果相同。這不代表所有網路環境都被擋（這類風控通常看 IP 與流量特徵辦事），但這支程式沒有簽名機制、沒有登入備援，通路一旦收緊，使用者端沒有任何開關可以自救。

把時間感放進來看會更清楚：這套寫法是 2024 年中期的生態。那時候「不帶任何憑證、直接打 B 站公開端點」的小工具滿地都是，能不能用通常只看運氣。兩年後的現在，平台端的防護明顯升級，同樣的程式碼一行不改，換個網路環境結果就可能不同。對一支已經停更的程式來說，這種外部條件的漂移，比程式本身的 bug 更致命。

想裝的人，成本長這樣

自己編譯是唯一的取得路徑，前置需求是 Flutter 3.19.6（專案的版本鎖定檔指定的版本），Windows 再加 Visual Studio 的 C++ 工具鏈，macOS 加 Xcode。專案附了兩支打包腳本：Windows 那支把編譯產物連同根目錄一顆 sqlite3.dll 一起壓成 zip（資料庫套件在 Windows 需要這顆檔案，作者直接把它 commit 進 repo）；macOS 那支做的是相反的事，把專案裡的簽章設定整段移除，產出來的是未簽章 App，第一次開啟要靠右鍵選單繞過系統檢查。

把成本講白：對一般使用者，這是半天起跳的開發環境工程，裝完還要承擔匿名路線不確定能不能通的風險；對本來就有 Flutter 環境的開發者，抓下來到跑起來也許十分鐘。同一件事，兩種身分的代價差很大，代價本身就是判斷要不要用的分水嶺。也要提醒：未簽章 App 在 macOS 上的開啟繞道，對不熟系統設定的使用者是另一道門檻，流程走不到「點兩下就開」那種順。真要編譯，選哪個分支也有差：main 分支是 2024 年定下來的版本，dev 分支是 2024 年 8 月起改用 Riverpod 的新寫法（一路更新到 2025 年 5 月），走得比較遠、但打包流程沒有走完，一般需求拿 main 就好。

編譯完成後想驗證它今天還能不能用，不用真的下載一支影片：貼上一段 B 站連結，看它能不能帶出標題與選集清單。清單有出來，代表資訊端點通了，再讓它抓一支短影片試水溫；連清單都帶不出來、直接跳錯誤提示，就是這條匿名路線在你的網路環境被擋住了，這時不必再糾結設定，問題不在你這邊。

時間線：main 十個 commit 定格，dev 的打包夢停在 2025 年 5 月

main 分支全部只有 10 個 commit：2024 年 6 月 13 日建立專案（當天就修了一個 macOS 網路權限問題，看得出作者自己邊跑邊補），6 月中旬到 6 月 25 日之間主體成形；8 月 12 日是最後一次程式修改，內容是修 bug 與 macOS 圖示尺寸；9 月與隔年 2 月的兩個 commit 都只動說明文件。寫程式的時間加起來約兩週，其餘是收尾。

dev 分支活得比較久，26 個 commit 橫跨 2024 年 6 月到 2025 年 5 月：換掉狀態管理框架（改用 Riverpod）的重構發生在 2024 年 8 月；2025 年 4 月底到 5 月 8 日的最後一段（8 個 commit）是打包自動化與 CI 的嘗試，依賴清單裡還多了圖表套件，看得出有繼續長功能的打算。變更紀錄裡只寫了「自動化打包測試」一行；CI 設定檔的觸發條件是推送版本標籤，而標籤從頭到尾沒被打過，工作流程的執行次數是零。自動化打包停在草稿狀態，repo 從 2025 年 5 月上旬之後靜默到今天。

議題區的氣氛同樣安靜。三個 issue 全部關閉、零開啟：2024 年 7 月問畫質選擇，10 月關閉；2024 年 10 月直接請求發佈 zip 安裝包，2025 年 3 月被關閉，沒有拿到任何檔案，2025 年 7 月還有人留言「同求」，無人回應；2025 年 1 月許願收藏夾批量下載與介面改版，同年 3 月關閉。許願沒有實現，issue 先關了。全部互動到此為止，貢獻者名單上自始至終只有一個人。

Pin

README 連向 GPL，授權條款檔其實不存在

README 的授權段連向 GPL 說明頁，但 repo 裡找不到任何授權條款檔案，GitHub 因此把這個專案的授權狀態標為未附加。公開原始碼與取得授權是兩件事：想把這份程式碼拿去修改、散布或商業利用的人，嚴格說處於授權未定的狀態，這在「開源 B 站下載器」這類轉述標題裡看不出來。真要以它為底做自己的東西，先把授權補齊是第一步。

使用前提還有兩條。README 的聲明段寫明這個專案僅用於學習交流，切勿用於其他用途；下載 B 站影片本身就有版權界線，作者把責任畫得比多數同類工具更窄。fork 側也沒有社群續命的跡象：73 個 fork 裡星數最高的一個只有 1 顆星，沒有任何一份接手繼續開發。想等別人把它救活，目前看不到這個人。

判斷：把它當什麼用

當日用工具，不建議。理由疊起來很具體：沒有安裝包可裝、匿名下載路線能不能通要看網路臉色、沒有畫質選擇、介面只有簡體中文、多段影片會存得不完整、維護已經停了一年半。這幾條裡任何一條都足以讓日常使用變得彆扭，加在一起，它撐不起「找個下載器存影片」這個日常需求。只是想保存幾支影片的偶爾需求，用不著為此架一套開發環境。

當參考程式碼，它有實實在在的價值。專案很小，扣除平台模板後約 40 個 Dart 檔；main 與 dev 兩個分支正好對照 Flutter 兩代狀態管理寫法（GetX 與 Riverpod），分塊下載器與 B 站端點的呼叫方式全部攤在明處。想理解這類下載器怎麼運作、或想在它基礎上做自己工具的開發者，這是一份誠實的 2024 年切片：短、完整、而且不再變動。要救活它也不難想像工程在哪：補登入與 cookie、跟上平台端的簽名要求、加畫質選擇、處理多段影片，每一項都是實打實的工作量，也正是它停在那裡的原因。

如果你的需求其實落在別的位置，站上有更合適的落點：錄 B 站直播可以看 BiliBili Live Recorder 開源直播錄影工具；把 B 站影片轉成文字稿有 Bili2Text 影片逐字稿工具；線上快速剪一段片段有 BiliCut 線上影片剪輯；下載其他平台的影片，SnapDouyin 抖音下載與 DLPanda X 影片下載都整理過。

857 顆星買到的不是一個能裝的工具，而是一堂攤開來的實作課。要找 B 站下載器的人，把這個前提記進搜尋清單：名字會一直流傳，安裝包從來沒有存在過。