OpenListTeam/OpenList

如果你有一堆散落在百度网盘、OneDrive、S3 和本地磁盘上的文件，想要一个统一入口，OpenList 值得花时间了解。它是 AList 的社区治理分支，吸引人的不仅是功能，还有代码由谁掌控这件事。

解决什么问题

典型场景：旧照片在百度网盘，工作文档在 OneDrive，备份在 S3，家里 NAS 还存着一堆东西。想找一份文件，得先回忆它存在哪个服务，再打开对应客户端，有时还得先下载才能播放。OpenList 在中间加一层网页文件管理器：每个网盘账号配置一次，之后在一个页面里浏览和预览所有文件。它还提供 WebDAV，桌面和移动客户端可以把聚合后的视图挂载成磁盘。

有什么不同

它的机制是一个 Go 服务端，为每种存储后端封装官方 SDK 或 API。README 列出了约四十种后端，包括阿里云盘、OneDrive、Google Drive、S3、WebDAV、百度网盘、夸克、115、Mega、FTP/SFTP 等。文件通过流式转发或重定向访问，不先集中拷贝一份；README 称它只做 HTTP 302 重定向或流量转发，本身不存储用户数据。

在存储层之上，它还提供 PDF、Markdown、代码、Office 文档、图片、视频和音频预览，支持密码保护路由、文件夹打包下载、网页上传以及跨存储复制。这样一堆账号就更接近一个个人文件门户。

代价也很实际。存储列表虽然长，但每个后端都依赖对应服务商的 SDK 或 API，免责声明明确说使用风险自负，包括账号被封或限速。列表里不少是国内消费级网盘，它们的条款未必欢迎这种网关式访问，所以可用性会跟着服务商的态度走，而不取决于 OpenList 自己的发版节奏。

README 还说明这是因原项目信任问题而从 AList 分叉出来的项目。这个治理背景是它存在的理由，但本身不能保证某种维护水平。据其声明，项目免费、没有付费计划，文档和 API 服务主要依赖 Cloudflare 提供的公益资源。

谁值得试

适合：手上有多个网盘账号、又有家庭服务器的用户，想要一个统一浏览入口和 WebDAV 挂载，同时不想搬动几个 TB 的数据。Docker 部署方式让它能和其他自托管服务一起跑在容器里，官方演示站可以让人先看看界面再决定。

不适合：期待应用商店式成品或全托管服务的人。如果你的文件本来就在一个生态里、也不需要跨存储浏览，额外管理账号和令牌只是增加工作量。如果某个服务商的 API 变动导致后端失效，你面对的是社区项目而不是厂商支持合同，README 也没有承诺任何 SLA。

使用条件与边界

你需要一台运行服务端的机器，通常是 Docker，并为每个接入的存储配置凭据或 OAuth。由于流量经过服务端转发，这台机器的带宽和稳定性会直接影响大文件在线播放的体验。

更大的长期成本是兼容性。README 的存储清单很长，但每个后端都绑定一个外部服务；服务商改 API 或收紧权限时，对应的存储可能停摆，直到社区更新适配。账号安全明确由用户自己负责，封号也被列为可能风险。AGPL-3.0 许可证还影响二次分发：如果你修改并对外提供服务，衍生部署需要以同样条款保持开源。

HotRepo 点评

HotRepo 只有一条带日期的记录：2026-10-25 该项目进入每日榜单，当时 25,259 星，当天 +34。这个单点快照能说明仓库年龄和那一刻的活跃度，但时间段内的比较数据不足，因此无法判断关注度能否持续。

真正需要先确认的，是你依赖的那个存储现在是否还能正常使用，而不只是出现在清单里。建议对照项目文档和 README 中的存储列表检查后端及其配置说明，并先用一个不重要的账号测试，再考虑迁移主网盘。