Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
AList 開源網盤聚合工具：把多雲端縫合成一個自架 WebDAV 入口，介面層不是儲存層
AList 是 AGPL-3.0 開源的檔案清單程式（AlistGo/alist，Go 語言、約五萬顆星），能將本地 NAS、阿里雲盤、OneDrive、Google Drive、百度網盤、S3 相容物件儲存等數十個後端整合到同一個自架網頁與 WebDAV 介面。它不是另一顆硬碟，而是資料閘道：檔案仍在原雲端，AList 只用官方介面做轉譯。本文誠實拆解介面層與儲存層的界線、把所有雲端 token 收進同台的憑證風險，以及中國網盤政策變數。
用 AI 摘要這篇文章：
AList 是一套以 AGPL-3.0 釋出的開源檔案清單程式，用 Go 寫成，能把本地目錄、物件儲存、與數十種商業網盤的檔案，整合到同一個自架的網頁與 WebDAV 入口。它走的是聚合索引這個定位：實際的檔案仍躺在原本的雲端或磁碟裡，AList 只是用各家官方介面，把「取得那個檔案」這件事統一成同一個瀏覽、預覽與掛載體驗。本文要回答的核心問題不是它能不能用，而是當你把一堆雲端 token 收攏到一部自架伺服器之後，要承擔哪些長期維護與合規成本。
AList 把你帳號裡的各種雲端儲存，縫合成一個自架的檔案瀏覽器與 WebDAV 伺服器。檔案還在原來的地方，AList 只是把存取入口集中；而這層集中的責任，是你要親自扛起這部伺服器的安全、授權續期與合規。
目錄
它處理的是多雲端切換的疲勞
常見的情境是這樣：一名接案設計師把進度中的素材丟在 Dropbox 跟客戶共用，完成的成品歸檔到自家 QNAP，合約文件塞在 Google Drive，截圖素材又落在 OneDrive。每個平台都有自己的網頁、桌面客戶端、行動 App 與登入規則，找一份資料常常要在四、五個地方輪流切換。AList 處理的就是這種切換疲勞：你只要登入它那一個網頁，就能跨平台瀏覽，甚至在兩個儲存後端之間直接複製、搬移檔案。
但這個價值的前提要先講清楚：AList 不會讓你的檔案變多，也不會讓儲存空間變便宜。它只是把分散的入口收斂成一個。如果你的痛點其實是「容量不夠」或「某個雲端太慢」，AList 解不了，那是採購與頻寬的問題；如果你已經是 NAS 玩家、VPS 站長，或者手上有三個以上雲端帳號每天都要點開，AList 才會真的減少你的摩擦。
Docker 起手，但維運才是主戰場
官方提供的 Docker 映像檔是 xhofe/alist，跑一段 docker run 就能把服務帶起來，預設監聽 5244 埠，第一次啟動會產生管理員密碼，接著進後台新增儲存後端。整個技術棧是 Go（後端用 Gin 框架）加上 SolidJS（前端），編譯成單一二進位檔，資源佔用對小 VPS 算友善。
真正吃力的從來不是第一次部署，而是後續維運。一旦這部伺服器要整合第三方介面、又要對外提供存取，它就會變成一個長期的安全與授權維護工作，而且這個負擔會隨著你掛的後端數量線性增加。最現實的成本是授權續期：掛載不同網盤要拿各自的 Token、Client ID 或 Cookie，而各家介面政策會不定期調整，今天能用的掛載方式可能下個月就需要重新授權或被降速。另一條來源沒點明、但實際會踩到的成本，是多帳號共用時的稽核負擔：AList 可以開放訪客上傳、可以為不同使用者設目錄權限，但這代表你要定期檢查誰還有存取權、哪些共享連結還開著，這不是裝完就結束的一次性設定。安全這條線更不能省：AList 過去在 GitHub 安全公告出現過漏洞，公網暴露的版本必須維持在最新穩定版、走反向代理上 HTTPS、設強密碼，並把管理後台鎖在內網，這是一筆每個月都要撥出時間去盯的事。授權條款則是另一個要先畫清楚的邊界。AList 採 AGPL-3.0，它的傳染條款會要求衍生作品一併開源，個人自用不受影響，但若想包進自己的 SaaS 或閉源產品，這條線得先讓法務看過。
支援哪些儲存後端，以及為什麼廣度不等於穩定度
AList 的賣點是支援的後端數量。README 列出的驅動涵蓋三大類，可以把它想成一個「雲端轉接頭清單」：
- 本地與標準協定：本地目錄、FTP/SFTP、SMB、WebDAV、S3 相容介面、Azure Blob Storage。
- 國際商用網盤：OneDrive（含 SharePoint、世紀互聯版本）、Google Drive、Dropbox、Mega.nz、MediaFire、ProtonDrive、Yandex Disk、Seafile。
- 中國大陸網盤與周邊：阿里雲盤（個人與分享）、百度網盤、夸克網盤、UC 網盤、115、123 盤、天翼雲盤（個人/家庭/群組）、移動雲盤（139yun）、迅雷、PikPak、Terabox、藍奏雲、飛機盤、Teambition（中國/國際）、dogecloud、又拍雲。
但廣度不等於穩定度。每一個後端背後都是一家服務商的官方介面，而這些介面會改。中國大陸那批網盤尤其明顯：限速、風控、Cookie 失效、被官方政策收緊，都會讓掛載體驗起起伏伏。如果你打算把 AList 當成長期依賴的檔案入口，建議優先用它掛載介面穩定的物件儲存、SMB、本地目錄，把那些商業網盤當成「能用就用」的加分項，而不是核心依賴。這也是它與 rclone 之類純協定工具的差別：rclone 把力氣花在標準協定與一致性，AList 把力氣花在廣度與網頁預覽，取捨不同。
預覽與多媒體
除了純粹的列表，AList 內建了一組相當實用的預覽引擎，這也是它跟 rclone、SMB 掛載比起來，更接近「打開就能用」的原因：
- 檔案與程式碼：PDF、Markdown、純文字、程式碼檔（內建語法高亮），README.md 會直接渲染。
- 媒體：圖片（含相簿畫廊模式）、音訊與視訊串流預覽，支援字幕與歌詞。
- 辦公文件類型：docx、pptx、xlsx 可在瀏覽器直接預覽，不必下載。
- 其他：資料夾打包下載、檔案永久連結複製、單檔多線程加速下載、離線下載、兩個後端之間互拷、可開放訪客上傳。
換句話說，AList 把「網盤網頁」該有的基本體驗都做齊了：你不用為了看一份 PDF 或預覽一段影片，先把檔案拉回本地。但它終究是預覽，不是專業的媒體庫或文件編輯器，如果你需要的是影音轉檔、協同編輯，那還是要走 Plex、OnlyOffice 那類專用方案，AList 提供的是「在統一介面裡快速看一眼」這一層。
WebDAV 與網路磁碟掛載
對很多技術使用者來說，AList 最有價值的不是那個網頁，而是它對外提供標準的 WebDAV 介面。這代表你可以在 Windows 用「對應網路磁碟機」、在 macOS 用 Finder 連接伺服器，或搭配 rclone、Mountain Duck、Infuse 這類支援 WebDAV 的工具，把遠端的雲端目錄掛成彷彿本地的網路位置。對習慣本地檔案總管工作流程的人，這條路比一直開瀏覽器舒服得多。
但 WebDAV 不是萬能。它的讀寫效能受限於底層後端。掛在阿里雲盤上的資料夾，再怎麼掛成網路磁碟，速度與穩定性終究被阿里雲盤的限速與介面策略綁住；掛在本地 NAS 或 S3 上才會接近真實磁碟的體驗。如果你是想拿 WebDAV 當主力工作磁碟，請把它對應到介面穩定的後端，不要對著高風險的商業網盤抱太高期待。
檔案到底存不存在 AList 上
這是評估 AList 時最容易誤解的一點。它的 README 與免責聲明都講得很直白：程式只做 302 導向與流量轉發，不攔截、不儲存、不竄改使用者資料。也就是說，你透過 AList 看到的檔案，本體還在原本的雲端或硬碟上，AList 只是把「取得那個檔案的連結」這件事統一了。這個定位有好有壞。
好的地方是，你不會多一份風險：檔案沒有被再複製一份到 AList 伺服器上，移除 AList 也不會動到原檔。壞的地方是，AList 不提供額外的加密、備份或冗餘；後端雲端斷線、刪檔、改政策，AList 那一側無能為力。要真正的資料主權（檔案實際握在自己機器上、能加密、能備份），那是要把資料放進自架儲存（例如自己跑的 MinIO 或 Nextcloud）才拿得到的東西，AList 在這條路上頂多擔任前端的聚合視圖，不是資料歸宿。
帳號憑證風險
要讓 AList 跨平台工作，你必須把各個雲端的 Token、Cookie 或 Client ID 交給它，存在你的自架伺服器裡。這件事的效益很明顯，一次設定、處處可用；但對應的暴露面也必須看清楚：這部伺服器等於變成你所有雲端帳號的「鑰匙圈」。一旦它被入侵、設定疏失、或跑了一個來路不明的第三方分支版本，外洩的不只是一組帳號，而是你名下一整批雲端儲存的存取權。這跟本地工具的信任邊際是同一類問題，只是規模放大：讀本地檔案的小工具出事，影響範圍限於那一部機器；AList 出事，影響的是你雲端身份的存取權。
實務上的幾個自保動作：部署前確認用的是官方映像檔（xhofe/alist 或 AlistGo 官方發布），不要亂抓第三方 fork；公網暴露一定要走 HTTPS 與強密碼，並把管理後台限制在內網或特定 IP；為不同使用者開獨立帳號與目錄權限，不要全部用管理員在操作；定期更新到最新穩定版本，留意官方的安全公告。如果你不打算花這個心力做隔離，那 AList 對你來說，風險會比效益大。
中國大陸網盤的合規與政策變數
AList 起源於中國大陸開發者社群，驅動清單裡也以中國網盤數量最多。這件事不是中性的：阿里雲盤、百度網盤、夸克、UC、115、迅雷這些服務，其介面政策、風控規則、內容審查、跨境可用性都會被各自的營運商與中國大陸的監管環境影響。實際使用上會遇到幾種狀況：某些後端僅在中國大陸 IP 才穩定，海外 VPS 掛載會被限速或拒絕；某些後端會因為服務商調整介面而突然失效，需要社群跟進修補；分享型的阿里雲盤資源連結，也可能因為上游被刪而失效。
從台灣本地連線使用的務實建議是：把 AList 當成「可以同時掛本地、國際、與中國網盤」的工具來用，不要把核心工作流綁死在單一中國後端上。如果你的需求其實是統一管理 OneDrive、Google Drive、Dropbox 與自家 S3，那 AList 完全勝任；如果你是為了「免費蹭阿里雲盤空間」才裝它，請先接受那個空間隨時可能被限速或政策調整的事實，並把重要檔案另尋穩定的儲存歸宿。
與 Nextcloud、Cloudreve、rclone 的差別在哪
這是評估 AList 時最常被問到的問題，因為它跟幾個鄰近專案看起來很像，但定位完全不同。把它們擺在同一張表會清楚很多：
| 專案 | 核心定位 | 資料存在哪 | 強項 | 弱項 |
|---|---|---|---|---|
| AList | 多儲存聚合的檔案清單與 WebDAV 閘道 | 仍在各個後端（AList 不存本體） | 後端廣度、網頁預覽齊全、WebDAV | 不提供加密備份、依賴各後端介面穩定 |
| Nextcloud | 完整的自架雲端硬碟與協作平台 | 存在你這台 Nextcloud 伺服器上 | 資料主權、外掛生態、行事曆聯絡人 | 資源吃重、聚合外部雲端非強項 |
| Cloudreve | 自架的輕量網盤系統 | 存在 Cloudreve 自己的儲存體 | 部署輕、介面乾淨、支援多策略 | 不是聚合外部網盤的工具 |
| rclone | 命令列的雲端同步與掛載工具 | 仍在各個後端（無網頁服務） | 協定一致性、同步規則成熟、穩定 | 無網頁 UI、不主打中國網盤廣度 |
| FileBrowser | 單一本地目錄的網頁檔案總管 | 本地磁碟 | 極輕量、單純 | 不聚合多雲端、無 WebDAV 伺服器 |
換個方式講：你要的是「一個自架、檔案在我機器上的雲端硬碟」，那是 Nextcloud 與 Cloudreve 的賽道；你要的是「在命令列把多個雲端同步、備份、掛載」，rclone 更專精。AList 卡的位置是「我已經有這些雲端，想要一個自架網頁把它們攤開來看，順便掛成 WebDAV」。rclone 沒有網頁 UI、Cloudreve 不聚合外部網盤，在這個交集上 AList 是少數同時滿足三個條件的選項，這就是它的位置。
適合誰，不適合誰
一個只用 Google Drive 共用試算表的 SOHO 族，或一個完全沒接觸過 Docker、反向代理、網路設定的人，AList 大概率不是最省心的選擇，直接用各家官方客戶端、外接硬碟，或買一個成熟的企業網盤服務，會比自架一套多雲端聚合服務划算。它的目標使用者很明確：本來就在玩 NAS 或 VPS、手上有三個以上雲端帳號、願意花時間做權限隔離與定期更新的人。對這群人，AList 在自架檔案管理領域是知名度與生態成熟度都名列前茅的選擇之一，花點時間跑起來並做好安全設定，它確實能給你一個更統一、更可控的私有檔案入口。
最後的判斷可以很具體：先列一張你每天會點開的雲端清單，少於三個的話，AList 大概率不值得你架；如果你本來就天天在五個網盤之間切換，那它解的痛是真的痛，值得認真架一次、然後每個月撥半小時去做授權續期與安全更新。
官方資源與部署入口
- 官方文件中心（alistgo.com）：Docker 部署、WebDAV 設定、各儲存後端掛載教學。
- GitHub 專案（AlistGo/alist）：原始碼、Release、安全公告，建議訂閱更新並維持在最新穩定版。
- 線上 Demo（al.nn.ci）：可先看看介面與預覽能力，再決定要不要自架。
- Docker 映像檔（xhofe/alist）：官方維護的部署管道。
使用提醒：AList 能接的網盤種類受各雲服務商介面政策限制，公開部署時務必做好權限隔離與網路安全防護，並遵守當地法規與各平台的使用條款。如果你也在評估把網站搬到穩定的主機環境，可以參考我們整理的虛擬主機評比；想知道怎麼用備份外掛把 WordPress 內容保護起來，UpdraftPlus 教學有完整步驟；若你正在找可以在本機處理 PDF、不把檔案上傳雲端的替代方案，Scanned Maker是另一條思路。
如果你不想自架伺服器，另一條 Serverless 路線是把 Telegram 機器人當檔案倉庫、Cloudflare 當介面，拼出一個零伺服器成本的私人雲端，但檔案會落在第三方平台。
