AsterDrive 的第一个 alpha 版本，其实只是一个 file browser。
能上传，能下载，删错了还能从回收站捡回来。
那时候我没有想过要做一套完整的私有云，也没有先画一张塞满箭头的架构图。我只是想要一个自己用起来习惯的地方：文件传得上去、下得下来，删错以后还能从回收站找回来。
最开始的动机也没有多宏大。我用过一些现成的自托管云盘，有些能力正好被放在商业版本后面，有些每天都要碰到的交互始终不像我想要的样子。偶尔传大文件时还会卡住，我甚至很难立刻判断，问题究竟出在软件、网络还是自己的部署方式。
它们并不是完全没法用，只是我很难把它们当成自己愿意长期依赖的地方。
所以我开始写自己的。
我一进来我就发现有三个需求
网盘的核心在于，文件上传下载得了，以及我能在回收站找回来。
上传和下载是入口，回收站是信任。人总会手滑，脚本也会写错，菜单也可能点错。一个文件系统如果连「让我后悔一下」的空间都没有，我不会真的放心把重要文件交给它。
这也是为什么，AsterDrive 一开始做的事情非常朴素：先给文件一个能安心停下来的地方。
文件进来以后，要有目录、权限、回收站、版本和锁；出了问题，至少要能知道发生了什么，而不是只得到一句「上传失败」。后台清理不能悄悄吞掉仍然被引用的文件，删除和恢复也不能只改一个界面状态就算完成。
这些内容不会直接出现在用户的界面上，却决定了我是否敢真的使用它。
AsterDrive v0.5.1 用户工作区界面
后来，文件不只需要停下来
一开始的需求达到了，我就想把 AsterDrive 做成一个中转站。
文件也不会一直停在你的电脑里。它可能去往 S3、RustFS 一类的对象存储，也可能留在 OneDrive 上，甚至被送到另一个 AsterDrive 节点。
文件的入口也不只有网页里的「上传」按钮。浏览器、WebDAV 客户端、Office 编辑器、公开分享页和后台任务，都可能让一份内容进入或离开系统。
问题也就变成了
文件进来以后，怎样可靠地走到它应该去的地方？
就是这样，AsterDrive 一点点长出了存储策略、策略组、远端节点和各种大文件上传方式。这些东西早已超出了一个 file browser 的范畴，它们只是一次次回答「文件该去哪里，又该怎样可靠地到达」之后，自然而然留下来的结果。
但对使用者来说，动作仍然只是把一个文件拖进工作区。至于它最后进入本机目录、对象存储还是远端节点，不应该要求每个用户先理解一遍 Provider SDK。
文件可以前往各种各样的地方 AsterDrive v0.5.1 后台存储策略页面
不想成为什么都有的私有云，但允许用户扩展
功能越做越多以后，我反而更需要提醒自己，AsterDrive 不准备做什么。毕竟开发伤脑经。
它目前有个人和团队工作空间，也有分享、回收站、版本历史、WebDAV 和 WOPI，可以接入常见的 WebDAV 客户端，也可以借助 OnlyOffice、Collabora 一类服务打开 Office 文件。但像 Nextcloud 这类老牌私有云所拥有的日历、联系人、聊天和邮件，我没有打算把它们塞进 AsterDrive 的核心，以后也不会。
AsterDrive 通过 WOPI 配合 OnlyOffice 打开文档
我们只想专心把文件本身做好：它怎么来到这里，我们该把它送往哪个站台，谁有权把它带走，它离开之后，我们还应该把它的版本和记录保留多久。
守住核心的边界，不代表把所有门都焊死。我希望以后能通过插件的形式，让每个人按自己的需要接入通知、自动化和其他工作流：AsterDrive 只管把文件做好，更多可能性交给扩展。只不过这套扩展机制目前还在设计阶段。
所以 AsterDrive 并不适合所有人。只想给一个目录套网页，它可能太重；需要完整的办公协作套件，它又不够。它更适合那些想掌控文件去向和生命周期，同时需要工作空间、分享、大文件上传与多种存储的人。
从能用，到逐渐敢把文件交给它
2026 年 7 月发布的 0.4.0，是我觉得 AsterDrive 开始拥有完整产品轮廓的一个版本。
那条开发线补上了下载中心、跨个人与团队工作区移动、OneDrive 浏览器直传、公开分享导航和一批认证边界。WebDAV 也不再只是「客户端连得上就算成功」，而是加入 Litmus 测试，作为一条可重复的兼容性基线
AsterDrive v0.4.0 下载中心重构
面向 0.5.0 的工作，我们没有急着继续增加页面，而是在清理过去含糊的地方。
具体来说，我们开始清理那些能跑，但说不清为什么能跑的地方：上传流程不再靠猜测状态，WebDAV 的协议处理和文件业务被分开，多实例部署也不再靠负载均衡器背后的运气。该共享的状态必须共享，暂时没有把握的路径就明确拒绝。
界面不会因此多出一个漂亮按钮，却决定了系统出错时能说清原因，也决定了我以后敢不敢继续把文件交给它。我宁愿把做不到的地方写明白，也不想用一句理论上应该可以，让用户替项目承担风险。
那么，古尔丹，代价是什么呢
AsterDrive 目前还没有成熟的桌面和移动端同步客户端。如果最需要的是像 Dropbox 一样的本地文件夹双向同步，它现在并不是合适的选择。同步一旦出错，代价往往比网页上传大得多。在开发初期我们暂时放缓了这一方向，不过最近有同好开发者正在往这个方向推进，等真正做出足够可靠的东西，再让它和大家见面。
还有两件事，我一直惦记着
一件发生在文件被修改以后：明明只动了其中一小部分，为什么还要把整份文件重新传一遍？
AsterDrive 现在已经可以在上传中断以后接着传，但「接着走完没走完的路」，和「只搬走发生变化的部分」，毕竟是两回事。真要做到后者，我还得想清楚文件应该怎么切、哪些内容可以在不同版本之间共用，以及那些再也没人需要的数据究竟什么时候才能清理。这里的账没有算明白以前，delta upload 也只是一个听起来很厉害的名字。
另一件发生在文件刚进门的时候：这次该把它送去哪里？
现在的策略组更像一个简单的分流员：先看文件大小，再按照顺序找到第一个合适的存储。以后我希望能把话说得更具体一点——图片留在这里，大文件送去那里；两块对象存储大致按比例分担，其中一块维护时就先别往那边送。最好它做完选择以后，还能回过头告诉我：为什么是这里，为什么不是那里。
两件事都在接下来的计划里，但计划写得再漂亮，也替不了真正跑起来的代码。等它们确实能够解决下一次上传的问题，再算 AsterDrive 自己的本事。
代码咋是 Rust
简短的答案是：因为我本来就写 Rust。
完整一点说，Rust 刚好适合我想要的交付方式。AsterDrive 可以把前端资源嵌入单个服务端程序，默认用 SQLite 起步，不需要先拼出一整套运行环境。类型系统也适合表达上传状态、存储能力和部署边界，让一些本不应该出现的状态组合尽早暴露。
别的语言当然也能写文件服务，Rust 也没有自动替我解决分布式系统、数据库迁移和业务建模；五百行的 service 函数换成 Rust 写，仍然是五百行的灾难现场。只是对 AsterDrive 来说，它和我想要的「稳定、能预见、改得动」比较合拍。
（顺带一提，在我自己服务器上 Docker 部署的 AsterDrive v0.4.0 常驻内存只有 35MB 不到，并发高的时候也只有 40MB，个人还是很满意的）
最坏的结果，也不应该是从零开始
我当然希望 AsterDrive 有人使用。如果有一天它真的能够养活我，那会很好。一个项目被别人需要，也能让作者继续投入，这是很现实的事情。
但如果最坏的结果是没有多少人使用，我也希望它仍然是一个完整、开放、可以被别人拿走继续修改的项目。它使用 MIT 许可证，代码、迁移、前端和文档都放在公开仓库里。别人可以阅读、部署、fork，也可以从我的想法里长出另一个方向。
我不想让一个项目只有留在我手里才算活着。AsterDrive 最开始是因为我用得不顺手才出现的；如果以后有人遇到相似的不顺手，他至少不必重新从空目录开始。
它不一定——或者说，很可能不会——成为最大的自托管文件项目。
但我会继续把它写成一个自己愿意托付文件的地方。
如果你想试一下
AsterDrive 已经提供 Docker 镜像，可以从 快速体验指南 开始。第一次启动会引导创建管理员和默认存储策略；本地 HTTP 体验与正式 HTTPS 部署的 Cookie 配置不同，请按文档操作。
项目代码、Issue 和版本记录位于 AsterDrive GitHub 仓库，更完整的部署、备份、WebDAV、存储后端和多实例边界可以在 AsterDrive 文档站 查看。
当前功能都在公开仓库和正式镜像中，没有兑换码，也没有需要解锁的高级版。如果你实际跑起来遇到问题，欢迎在评论区或 GitHub Issue 里留下环境、版本和复现步骤。
愿你用得顺手。
发表回复