摘要：经常和网盘打交道的家友，一定对 开源网盘应用 “ Alist ” 很熟悉。 为了应对不同网盘资源之间繁琐的切换操作，Alist 应运而生。

经常和网盘打交道的家友，一定对 开源网盘应用 “ Alist ” 很熟悉。 为了应对不同网盘资源之间繁琐的切换操作，Alist 应运而生。

不过，这个曾被用户誉为“网盘统一入口”的神器 Alist，正在经历一场隐秘的资本收割。今年 6 月初，有不少 Alist 用户发现前几天还能正常播放网盘视频，如今 却提示“授权失败”。

与此同时， 在 GitHub 上，大量用户正在刷屏式留言，询问 Alist 到底发生了什么情况？今天（6 月 18 日），IT之家小编就和大家聊聊这个话题。

01.

Alist，网盘集大成者

按照惯例，先给不了解情况的家友介绍 Alist。2021 年，Alist 在开源仓库发布，一开始它只是基于阿里云盘的个人网盘目录列表应用。后来随着不断迭代升级，Alist 逐渐集成更多的操作方式。

比如，面对网盘资源不互通的情况， Alist 支持挂载许多主流网盘 （阿里云盘、OneDrive、Google Drive 等）， 可部署在多种环境， 包括个人电脑（Windows/macOS/Linux）、服务器（VPS）或网络存储设备（NAS）上，打通资源壁垒。

另外， Alist 可以自建网盘。

用户可以将图片、视频、音频等文件保存到其中，并且能够进行预览、打包下载、离线下载以及 跨存储文件同步 等操作，方便文件管理和使用。

通过这些操作，Alist 相当于一个实现了挂载网盘和云存储双重服务的文件管理工具。

功能强大加上部署方式灵活，Alist 在推出之后就受到许多开发者和用户的青睐。

开源社区一直有开发者贡献相关代码，Alist 也在不断成长。 据 GitHub 统计，Alist 收获超 4.9 万星标，Docker镜像下载量突破 500 万次。

当然了，Alist 也有自己的短板。 因为使用私有 API，所以如果网盘方调整接口，来不及更新的 Alist 就无法正常使用。

而当用户习惯了它带来的便利，却没人想到这个“网盘集大成者”，已经在开发者的隐秘运作下悄然出售。

02.

项目易主，用户担忧

6 月 11 日，原开发者发布声明，证实 Alist 项目已被收购交由公司运营，自己则会帮忙审查开源版本仓库的代码。

项目易主本不稀奇，但 Alist 的交接过程却充满疑点。

IT之家注意到，按时间线显示，早在 2024 年 10 月，新域名就已经注册，原文档链接也被逐步替换，原开发者 Xhofe 的博客链接在 GitHub 仓库中消失。

而在整个过程中，用户没有看到任何公告和社区告知，只有部分用户偶然点开原官网链接，发现显示 404 错误页面时，才察觉有些不对劲。

真正的导火索是 Alist 被收购后出现的维护细节。

新维护者 alist666 提交的 PR #8633 被发现含有收集用户系统信息的代码，数据将上传至私有地址。

虽然舆论压力迫使该 PR 撤回，但很多用户意识到：自己存储在 Alist 中的网盘 Token、Cookie 等密钥，已经不再安全。

因为网盘想挂载 Alist，需要将 Token、Cookie 等 API 授权给 Alist。 也就是说，Alist 收购方可以通过这份 API，读取到用户网盘的内容，用户的隐私安全面临考验。

IT之家注意到，还有一些用户担心， Alist 出售后可能会遇到“供应链投毒”的情况。 简单来说，就是项目被恶意修改开源代码，植入后门或病毒，当大量用户使用时，造成数据泄露等严重后果。

用户的担心不是空穴来风，这些年来，开源项目安全漏洞事件不在少数。 比如最典型的 Log4j 漏洞，黑客可以完全控制运行未打对应补丁的设备。

Log4j 作为广泛嵌入企业系统的开源日志组件，加上该漏洞极易被利用，其在被发现后网络攻击数量激增。在这样的背景下，Alist 被突然收购且代码控制权转移，用户自然会担心自己的数据安全。

在 Alist 收购事件曝光之后，一场围绕用户数据的自保行动迅速展开。技术论坛里流传着紧急指南： 立即降级到 v3.40.0版本 （即收购前的最后“纯净版”），并同步解除所有网盘授权。

IT之家注意到， 出于对用户数据安全的保护，多家网盘采取了行动。

6 月 12 日，123 云盘率先发布公告撤销 Alist 的API权限，阿里云盘、115 网盘也紧随其后。 这些曾经开放接口的网盘平台，都因为 Alis 的仓促出售而做出紧急处理。

03.

开源本质，贵在信任

对开发者来说，维护一个开源项目需要投入大量的时间和精力，通常比较难获得直接的经济回报。

捐赠模式不稳定，而提供企业定制服务又面临技术和市场的双重挑战，在生存压力下，选择将项目出售给第三方公司，似乎成了一种无奈之举。

开发者将项目变现的需求合理，只是从用户角度来看，这种选择往往伴随着用户利益的潜在风险。

从另一个角度来看，Alist 项目被售事件，也给开源生态敲响了警钟。

对用户来说，过度依赖单一开源工具确实存在不小的风险，比如供应链安全、服务中断、隐私泄露等。

用户在选择使用开源项目时，还是要多关注其维护活跃度和开发者的稳定性，尽量选择由社区主导代码的项目，降低开发者突然停止维护或项目出售带来的不确定性。

而对于开源行业而言，建立更完善的规则迫在眉睫。

比如，要推动建立开源项目收购的 “社区监督机制”，要求收购方公开详细的技术路线图和安全承诺，接受社区监督。

另外，也要强化开源基金会的作用，将更多项目加入制度化保护，避免因开发者个人决策影响整个社区的利益。

毕竟，开源的本质是信任，信任开发者的初心，信任技术的共享精神。

本文源自IT之家

来源：金融界一点号