AList 是这几年自建圈里最出圈的项目之一：把阿里云盘、百度网盘、OneDrive、S3、WebDAV、甚至本地硬盘挂进同一棵目录树，然后用一个网页把它们通通变成一个「文件列表」，支持在线预览、直链下载、WebDAV 挂载。仓库现在有 5 万多星、近 8000 个 fork，用 Go 写（Gin + SolidJS），AGPL-3.0 协议，2020 年 12 月建仓，最新提交在 2026 年 10 月。
多数介绍会从「支持多少种网盘」开始，但那不是它最值得说的地方。真正决定它能力边界和使用风险的，是它对流量的处理方式——这一点搞清楚了，剩下的都是配置问题。
一、它不搬数据，只发一张「通行证」
你在页面上点一个文件的下载，AList 做的事是：校验你有不有权限 → 向对应的网盘换取一个带签名的真实地址 → 把这个地址塞进 302 响应返回给浏览器。接下来浏览器直接连网盘服务器下载，流量根本不经过你的机器。
这个设计带来三个直接结果。第一，一台 1 核 1G 的小机器可以挂几 TB 网盘而不卡——因为它不转发数据。第二，你的服务器带宽和流量几乎不被消耗，只承担页面与 API 那一丁点请求。第三，网盘的限速、风控、封号风险全部落在你的账号上，这跟服务端没关系——README 的免责声明写得很直白：使用前应了解并自行承担相应风险，包括但不限于账号被封禁、下载被限速等。
同理，它也支持用 Cloudflare Workers 做代理层，本质是在 302 链路上再加一跳，把请求来源换成 Workers 的地址。这套玩法在国内网络环境下有自己的适用场景，但也意味着链路更长、可控性更低。
二、四十多种存储，装进一个目录树
README 的存储清单是 AList 最有说服力的部分，粗看可以分成三类：
| 类别 | 覆盖 | 实际用途 |
|---|---|---|
| 国内网盘 | 阿里云盘、百度网盘、115、123 盘、天翼 189、移动 139、夸克、UC、迅雷、蓝奏云等 | 把散在各家的资源合并成一个入口 |
| 境外网盘 | OneDrive / SharePoint、Google Drive、Google Photos、MEGA、Dropbox、PikPak、Terabox、MediaFire、Proton Drive、Yandex | 团队共享盘、个人备份盘统一访问 |
| 存储与协议 | S3 兼容、又拍云、Azure Blob、Seafile、WebDAV、FTP / SFTP、SMB、本地磁盘、Cloudreve | 接对象存储与内网 NAS 的常规路径 |
关键在于抽象是一致的：不管是网盘还是 S3，加进来之后都是「一个存储」，配上挂载路径，就出现在目录树里。于是「把公司的 OneDrive 和家里的 NAS 放进同一个列表，再分享一个只读链接给同事」这种事，配置成本只是加两个存储。
三、除了「能看文件」，它还做了什么
- 预览：PDF、Markdown、代码、纯文本、图片画廊模式、音视频（支持字幕与歌词），Office 文档（docx / pptx / xlsx）也能在线看。
- 权限：可为目录设置密码或指定账号访问，公开路径与受保护路径并存。
- WebDAV：整个站可以当 WebDAV 服务器用，于是能被 PotPlayer、Infuse、nPlayer 这类播放器直接挂载——这是很多人用它的真实原因。
- 操作：网页上传（可允许访客上传）、新建目录、重命名、移动、复制、删除；支持跨存储复制文件；支持打包下载。
- 加速：单线程下载/串流的场景下做多线程加速，对某些限速网盘有实际效果。
- 离线下载：把链接交给网盘侧去下，不消耗自己带宽。
- 其它：深色模式、多语言、文件永久链接、README.md 渲染。
四、2025 年的那次分叉，得说清楚
2025 年 6 月，社区出现了 OpenListTeam/OpenList，仓库简介写的是「A new AList Fork to Anti Trust Crisis」。目前它已有 2.5 万星，更新节奏比原仓库更密（2026 年 11 月仍有提交），文档独立放在 doc.oplist.org。
这件事对使用者的实际影响是：你现在有两个活跃的分支可以选择，而它们的配置与生态并不完全互通。选之前最好先看一眼各自最近的提交记录、issue 响应情况和文档完整度，别在网上随便抄一份教程就照着装——2025 年之前的教程基本都指向旧版本。
至于当年到底发生了什么，公开信息里有各种说法，本文不做评判。可以确认的事实只有两条：原仓库仍在更新（AGPL-3.0 未变），分叉仓库自述是为「反信任危机」而建。
五、合规这件事，绕不过去
AList 本身是中立工具：它调用各家网盘的官方接口，只做 302 跳转与流量转发，不拦截、不存储、不篡改用户数据（README 原话）。但「工具中立」不等于「用法无风险」：
把有版权的内容挂成公开目录对外分享，风险在你；用别人的账号挂载，账号被封的风险在号主；把受保护的目录设成无密码公开，责任也在站长。README 里那句「请遵守相关法律法规，不要滥用」，不是客套。
另外 AGPL-3.0 是有约束力的许可：自己搭、自己改都可以，但如果改造后对外提供服务，源码需要同样开放。
六、适合谁，不适合谁
适合：手上有几个网盘、一台常年开机的小主机，想把资源合并成一个入口，还想用播放器通过 WebDAV 直接看片的人。也适合做内网文件门户——把 NAS、对象存储、共享盘挂成一份列表，比记五个不同的后台地址舒服得多。
不适合：想要多人协作、版本管理、在线编辑的人（那是 Nextcloud / Seafile 的活）；以及不愿意承担账号风控风险的人——只要用了第三方网盘做后端，这一条就躲不开。
它解决的是「入口分散」的问题，不是「存储不够」的问题。想清楚这一点，就不会期待它变成网盘。
本文整理自公开资料并重写：AlistGo/alist 仓库 README（存储清单、功能列表、免责声明、许可说明）与仓库元信息（星标、fork、语言、协议、建仓与最近提交时间）；OpenListTeam/OpenList 仓库元信息与项目自述（2025 年 6 月建仓、简介原文、文档地址）；以及两者的提交活跃度对比。数据截至 2026 年 11 月，具体以各仓库页面为准。配图两张均为依据 README 内容自绘的信息图（请求链路与存储清单），未使用任何官方截图或第三方图片。原 README 中的赞助商、社群与讨论区入口、捐赠链接、徽章一律未收录；演示站地址未收录。文中对分叉的陈述仅限公开可查的事实，不构成对任何一方动机的判断；使用相关网盘服务请遵守服务条款与当地法律。
本文整理自公开资料并做重写，原始出处：https://github.com/AlistGo/alist。文中配图已去除站点叠加水印与推广信息；版权归原作者所有。