為什麼 qBittorrent 5.2.0 是媒體伺服器管理者必升版

qBittorrent 5.2.0 對媒體伺服器管理者是必升版，因為它同時提升穩定性、速度與分類控制。

我認為，跑 Radarr、Sonarr、Jellyfin 的管理者應該立刻升到 qBittorrent 5.2.0。這不是一次可有可無的介面更新，而是會影響日常下載、整理與自動化流程的版本。它帶來分類層級的分享限制、更快的 WebUI、非同步 piece 計算，以及一長串崩潰修正。對媒體伺服器來說，qBittorrent 往往不是最顯眼的元件，但它一旦卡住、當掉或吃掉儲存空間，整條下載到入庫的鏈路都會受影響。

第一個論點：分類層級控制，才是媒體自動化真正需要的功能

5.2.0 最有價值的更新，是把分享限制下放到 category 層級。以前多數人只能全域設定 ratio 或時間限制，或是逐個 torrent 調整，對 Radarr、Sonarr 工作流來說都很笨重。現在你可以直接替電影、影集、動畫設定不同的做種政策，讓客戶端配合你的規則，而不是逼你接受一條規則管全部。

這不是抽象的便利，而是實際能省掉人工干預。假設你的電影分類要做種更久，電視劇分類要更快釋放空間，或是 4K remux 與 anime 要有不同保種策略，5.2.0 都能直接處理。再加上這版把 subcategories 變成無條件可用，對於會依來源、畫質、媒體類型細分資料夾的人來說，舊分類模型早就不夠用。這次更新終於把工具磨利了。

第二個論點：效能改善不是裝飾，而是家用主機的體感差距

非同步 piece 計算看起來像小改動，但在弱一點的硬體上差很多。5.2.0 把 piece hash calculation 改成非同步後，加入新 torrent 或重新檢查時，UI 不會像以前那樣被背景工作拖住。若你跑的是 Intel N100 這類迷你主機，這種差異很明顯，因為客戶端不會在處理大檔時像是整個凍住。

WebUI 也朝同一方向優化。這版改用 virtual list 來提升表格效能，對大量 torrent 的管理更順手。媒體伺服器管理者常常不是在看五個任務，而是在同時處理幾十甚至幾百個項目。再加上狀態列新增可用磁碟空間指示器，5.2.0 其實是在回應真實使用情境：長時間運作、磁碟常滿、而且一次錯誤下載就可能把儲存壓力推到臨界點。

第三個論點：穩定性比功能數更重要

光是崩潰修正，就足以構成升級理由。這版修掉了多個明確的當機情境，包括新增 torrent 後退出、在新增對話框開著時關閉程式、處理 ipfilter.dat 的無效條目、把 RSS 資料夾移到自己的子資料夾，以及在 macOS 上刪除 torrent。這些不是邊角料，而是會直接中斷自動化管線的故障點。

對 Radarr 和 Sonarr 使用者來說，最值得注意的是 watched-folder 的儲存路徑問題。只要路徑錯一次，匯入就可能落到錯誤位置，後續整理會多出一連串人工修補。Torrent Creator 也修掉了新建 torrent 無法開始做種的問題，對會自行產生 torrent 或管理內部分發的人尤其重要。這代表 5.2.0 不是單純加功能，而是在移除真實工作流中的失敗模式。

反方可能怎麼說

最強的反對意見，是相容性風險。qBittorrent 5.2.0 放棄 Qt 6.5，抬高函式庫需求，底層改動也足夠多，對舊系統或精簡部署來說，升級確實可能帶來麻煩。如果你跑的是嚴格鎖版的 Docker image，或是在老硬體上用發行版套件，這種大版本跳躍不該輕率對待。還有一點也說得通：既然現有 Radarr、Sonarr、WebAPI 整合已經能用，穩定環境看起來沒有立刻升級的必要。

這個顧慮成立，但不足以推翻升級價值。關鍵是，5.2.0 對一般媒體自動化是加法，而且 WebAPI 仍維持相容。真正的風險不是 Radarr 或 Sonarr 會壞掉，而是你的平台依賴太舊，撐不起新版本。那是部署環境的問題，不是版本本身的問題。如果你的系統無法滿足 Qt 6.10.3 與更新後的函式庫，就先修環境，或暫留舊分支；但對其餘大多數人來說，這版帶來的穩定性與控制力，值得承擔一次受控升級。

你能做什麼

如果你是工程師或家用伺服器管理者，先備份 qBittorrent 設定，再檢查 base image、發行版套件與 Qt 相依性，確認能承接 5.2.0 後再升級。升級後立刻設定分類層級的分享限制，重新核對 watched-folder 路徑，並在最大的一批 torrent 上測試 WebUI 反應。若你是 PM 或創辦人，這次更新提醒你：真正影響體驗的往往不是炫目的新功能，而是儲存可視性、崩潰率、以及大批量管理速度。