评估一个挂载器，我第一件事不是看 README 打了几个勾。是翻架构，找 token 在谁手里。
proton-drive-linux-fs，让我第一眼舒服的就是这儿。内核 FUSE 层把读写请求转给挂载守护进程，守护进程是唯一一个直接碰 Proton API 的组件。托盘程序、以后可能有的 GUI，全绕到本地 unix socket 后面去问它；socket 不通，降级读状态文件。
听着像常识。我见过的同类小项目，十个里八个不这么干。
省事嘛。谁要显示个同步进度，谁就顺手把凭据揣自己兜里，直接问远端。代码短，一下午跑通，demo 好看。然后某天，某台机器的托盘 debug 日志里躺着一条 refresh token，被人原样贴进 issue。这个剧本我看过。
守护进程内部还按职责切了 fusefs、drive、auth 三块——文件系统归文件系统，Drive 逻辑归 Drive 逻辑，认证归认证。这切法啰嗦，多一层协议、多一堆错误码要处理。换来的是：凭据只有一个地方会漏，出问题只有一个地方要查。
半夜三点爬起来，最怕的从来不是 bug。是「到底哪个进程还攥着那把钥匙」。这一层洁癖，救的就是这个。
但真让我停下来多看两眼的，不是 token 放在哪一层。是写路径。
写入先落本地临时文件缓冲，等文件关闭，再在预设超时点整份传上去。读那头一样——目录和文件名直接拿元数据拼，内容等你真去读才拉。
这套我太熟了。Google Drive、Dropbox、OneDrive，桌面端全这思路，省带宽省盘。思路没错，代价也统一：从「本地写完」到「远端确认」，中间有一段谁都不敢担保的窗口。用户在编辑器里按了保存，光标回来了，以为没事，然后合盖、断电、拔盘。
这不是这个项目的毛病，是所有按需同步盘的共同欠账。区别只在于，有的产品把这段窗口摆到明面上——托盘转圈、状态写「待上传」；有的干脆让你以为写完就是写完了。
所以那个托盘程序不是装饰品。它是「这份数据现在到底在哪」的唯一出口。
我甚至觉得，它以后真做 GUI，优先级最高的不是好看的文件列表，是一个能一眼看出「哪些文件还没落远端」的视图。做不出来这个，前面架构再干净，该丢的数据一样丢。
远端改动那块也一样。项目走 Proton 的事件推送，收到之后让对应目录列表和已缓存内容失效。听着优雅，实际是脏数据最爱长的地方——失效早了，白拉一遍，浪费带宽；失效晚了，你本地看到的是三分钟前的版本，还以为自己改的是最新的。缓存失效没有标准答案，只有「你更怕哪一种错」。这个选择得写进文档，不然用户丢数据的时候，连怎么丢的都说不清。
扯远一句。FUSE 这种挂载器，死法跟别的进程不一样。普通服务挂了，日志一行栈，systemd 拉起来完事。FUSE 那头一断，用户看到的是个卡住的目录——ls 卡在那儿，shell 卡住，编辑器打开文件转圈。这时候重启守护进程都不一定干净，得先把挂载点强卸下来。我处理过不止一次这种「看着像磁盘坏了、其实是挂载进程早没了」的现场。所以这类项目我最想先翻的一页文档，是「守护进程挂了怎么办」。这页我在它文档站上没找着，也可能是我没翻仔细。站子是 Material for MkDocs 搭的，看得出作者愿意在这上面花时间，那这页大概只是还没写。
拉回来。
它自述里写得很明白：早期开发阶段，非官方，跟 Proton AG 没隶属关系，也没拿到背书和技术支持。这段话我读着舒服。比一堆 README 顶上写「production-ready」、出事再让你自己去看 license 的强。
翻译成人话：你拿它挂生产数据，出了事没人接你电话。issue tracker 那头可能就是作者一个人，还可能在睡觉。接电话的是你自己，那个冤种。
作者说在一个共享上跑通了读、写、建、删、改名、移动几条常见路径。这话实在，但分量同行都懂——一个人的 happy path 验证，覆盖面约等于他自己那台机器。他自己也承认，环境太多，覆盖不全，预期会遇到 bug。这就对了。承认覆盖不全的项目，比拍胸脯说全支持的，半夜更让人放心。
所以这东西现在能不能上主力机？
我的答案：能挂，别挂唯一的副本。
具体一条规则——任何按需同步的挂载，先把「未上传」这个状态暴露出来，再做别的功能。看不到这个状态，你就等于把数据交给一个不告诉你什么时候写完的黑盒。这种事我见过太多次，最后都是以某个人一份文档没了收场。
至于 token 只肯放在守护进程一层——那是加分项。加分项救不了丢数据，但它能让你半夜爬起来的时候少查两个地方。
说句实话，少查两个地方，就已经值回票价了。