关于 AsterDrive
第一个 alpha
AsterDrive 的第一个 alpha 版本，其实只是一个 file browser。
能上传，能下载，删错了还能从回收站捡回来。那时候我没有想着做一个完整云套件，也没有先画一张很大的架构图。我只是想要一个自己用起来不别扭的地方。文件传得上去，下载得下来，删错了还能捡回来。就这三件事。
听起来很小，但对我来说，这已经够成为一个项目的理由了。
最开始的动机也没有多宏大。我只是用现成的自托管云盘用得不顺手。有些能力我需要，可它们被放在商业版本后面；有些交互每天都会碰到，却始终不像我想要的样子；偶尔传大文件时会卡住，虽然我也说不清到底是软件本身的问题，还是我自己的部署方式出了问题。
那种感觉很明确：它能用，可我很难把它当成自己想长期依赖的那个地方。
所以我开始写自己的。
给文件一个能停下来的地方
如果现在只能保留三个功能，我还是会选上传、下载、回收站。
上传和下载是入口，回收站是信任。没有回收站，我不会真的放心把重要文件放进去。人总会手滑，脚本也会写错，操作菜单也可能点错。一个文件系统如果连“后悔一下”的空间都不给我，它就很难成为我真正会依赖的东西。
所以 AsterDrive 一开始要做的事情很朴素：先让文件有地方停下来。
后来我开始把它想成一个中转站。
这个中转站首先要让文件安心停靠。文件进来以后，有目录，有权限，有回收站，有版本，有锁，有后台清理。出错时要能看见发生了什么，能追日志，能跑检查，能把该找回的东西找回来。
然后它还要能调度流向。文件不一定永远留在这台机器上。它可能落在本地磁盘，可能去 S3 / MinIO 这类对象存储，可能被写到另一台 AsterDrive 节点上。浏览器、WebDAV 客户端、Office 编辑器、分享页和后台任务都可能成为入口。AsterDrive 要做的，是把这些入口、去向、权限和生命周期整理清楚。
最后，它应该尽量让我自己掌控。文件在哪里，谁能访问，能不能分享，删了以后还能留多久，大文件该走哪条上传路径，这些事情我不想完全交给一个黑盒。
很早就开始给它留路
表面上看，第一个 alpha 只是一个 file browser。可在 alpha.1 之前，我已经开始想后面的存储层了。
我很早就知道，它不能永远只把文件当成本机目录里的路径。文件总有一天会离开这台机器，去对象存储，去另一台节点，去一个当时还没完全想清楚的地方。所以在它还很小的时候，我就开始给它留路。
这也是为什么 AsterDrive 后来会长出存储策略、策略组、S3、远程从节点、大文件上传协商这些东西。它们都在回答同一个问题：
文件进来以后，应该怎么可靠地走到它该去的地方？
现在 AsterDrive 可以从默认 SQLite + 本地存储起步，也可以接 PostgreSQL / MySQL、S3 兼容对象存储、远程 follower 节点。它能处理普通直传、可恢复分片上传、S3 预签名上传和 S3 multipart 上传。听起来已经不像最初那个 file browser 了，但它还是从那三件事长出来的：上传、下载、回收站。
我想把它做成什么样
我希望 AsterDrive 先是能用的。
能启动，能上传，能下载，能删除，能恢复，能升级，出错时能定位。文件系统这类东西，最基本的要求从来都不浪漫：数据不能随便丢，失败不能悄悄发生，恢复路径不能只写在愿望里。
然后它要好用。
我说的好用，不是演示视频里看起来很漂亮；是每天真的会顺手。打开文件夹、拖文件进去、建分享、改权限、看任务、清回收站、挂 WebDAV、用 Office 服务打开文档，这些动作不应该让人每次都重新思考。
最后它要适合我用。
这句话听起来有点自私，但我觉得一个个人项目如果连作者自己都不想长期使用，它很难长出真正的判断力。适合我用，意味着它要轻、要快、要改得动，要能从一台机器开始，也要在未来有路可以继续扩展。
如果别人也刚好需要这样的东西，那很好。你可以把它跑起来，也可以 fork 走，改成更适合你的样子。
为什么是 Rust
简短回答：因为我本来就写 Rust。
更完整一点说，Rust 刚好适合我想要的交付方式。AsterDrive 可以做成单个服务端程序，前端资源内嵌进去，默认 SQLite 起步，不需要先拼一整套运行环境。内存安全、性能和明确的错误处理，也很适合文件服务这种容易踩到边界条件的系统。
别的语言当然也能写文件服务。只是对这个项目来说，Rust 和我想要的“轻、稳、改得动”比较合拍。
适合谁
如果你想自己掌控文件，不想把所有东西都交给商业网盘，AsterDrive 可能适合你。
如果你想给家人、朋友或小团队放照片、视频、文档和资料，希望它能上传、分享、恢复、预览，也能通过 WebDAV 或 Office 服务接到现有工作流里，AsterDrive 可能适合你。
如果你关心文件最后落在哪里，想从本地磁盘开始，后面再把一部分数据放到 S3 或远程节点上，AsterDrive 可能适合你。
如果你想二开一个文件服务，不想一上来就被复杂生态、插件市场和巨大的历史包袱压住，AsterDrive 也可能适合你。
这几个“可能”是故意写的。文件系统很贴近每个人的数据习惯，跑起来试一次，比读十页介绍都更诚实。
不适合谁
如果你现在需要日历、联系人、聊天、邮件、插件市场和成熟企业协作生态，AsterDrive 目前不适合你。
如果你现在最需要的是成熟的本地文件夹双向同步客户端，也请先冷静一点。五端客户端我一定会做，macOS、Windows、Linux、iOS、Android 都在长期目标里。但第一阶段会更适合先做好访问、上传、下载、分享、预览和管理体验。真正的本地双向同步要更谨慎，因为同步一旦出错，代价会比网页端大得多。
如果你只想给服务器上的一个目录套个网页管理界面，AsterDrive 可能太重。
如果你需要多主热备、自动故障切换、跨地域强一致复制、复杂企业权限矩阵或合规认证，AsterDrive 现在也不适合。当前远程节点能力解决的是“把对象写到另一台机器”，离集群编排系统还有很远。
承认这些边界很重要。文件系统承诺太多，最后受伤的是用户的数据。
不假装比现实更可靠
我不会写“绝对安全”或者“100% 可靠”这种话。
硬盘会坏，网络会断，磁盘会满，软件会有 bug。AsterDrive 能做的是把上传、下载、元数据、回收站、版本和后台清理尽量做扎实，提供 doctor 这类检查工具，给出能定位问题的日志和错误码，再把备份恢复文档写清楚。
备份仍然是部署者自己的责任。你可以从 备份与恢复 开始看，也可以在上线前走一遍 生产检查清单。
我希望 AsterDrive 让人安心。这份安心应该来自清楚的机制，不该只靠漂亮的口号。
最坏的结局
我当然希望 AsterDrive 有人用。
如果有一天它真的能养活我，那会很好。一个项目能被别人需要，能让作者继续投入，这是很现实也很珍贵的事。
但如果最坏的结果是没人用，我也希望它至少还是一个完整、开放、能被别人拿走继续改的项目。代码在这里，许可证允许你阅读、修改、部署、fork，甚至从我的想法里长出另一个方向。
这也是我一直偏向 MIT / Apache 这类宽松许可证的原因。
我不想让一个项目只有在我手里才算活着。它最开始是因为我用得不顺手才诞生的，可如果有一天别人也遇到类似的不顺手，我希望他不需要从零开始。
这就是 AsterDrive 对我来说最重要的意义。
它不一定会成为最大的自托管文件项目。
但我会继续把它写成一个我愿意托付文件的地方。
想参与
- 先跑起来：从 快速开始 开始。
- 遇到问题：去 GitHub Issues 说清楚复现路径。
- 想改代码：fork，改，提 PR。带着真实问题来的改动最有价值。
- 想支持项目：可以 Sponsor，也可以通过 issue、文档反馈、部署案例来帮它变得更好。
- 商业部署 / 二次开发：可以从 GitHub 主页联系作者。
愿你用得顺手。