周末断网一小时

2026-08-22

为什么要做这个测试

写了四篇文章介绍”不依赖云的离线效率系统”——离线词典、本地 RSS、私人词典、工具冻结。但这些都是一个个独立的模块。真正的问题还没回答：

把它们拼在一起，关掉网络，一个普通的周末小时能不能撑住？

不是理论上的”离线优先”，而是真正的压力测试。

测试规则很简单：

测试过程

第 0 分钟 — 关 Wi-Fi

关掉 Wi-Fi。打开 Emacs，打开终端。一切就绪。

第 0-15 分钟 — 写点东西

周末写作，没有工作目标，纯粹想整理一下最近读完几篇文章后的想法。

打开 Emacs，进入之前没写完的 org 文件。evil-mode 下正常编辑，:w 保存——完全没有问题。这些是纯本地操作，Emacs 不知道也不需要知道网络有没有连接。

写完后切到 git-bash，git add 加 git commit，本地提交成功。

状态：无阻碍。

第 15-25 分钟 — 读几篇文章

M-x elfeed 打开本地 feed 列表。之前刷新的文章全部可读，l 标签筛选未读，s 搜索关键词。

周末的阅读不像工作日那样带着明确的目的，更多是”看看有什么有趣的东西”。翻了几篇之前标记星标的文章，f 在本地 data 目录找到缓存的全文，读了一篇关于本地优先工具链的讨论。

状态：基本无阻碍。

第 25-35 分钟 — 查词

读文章时遇到两个生词：”idiosyncratic” 和 “paradigm”。M-x sdcv-lookup-word 瞬间弹出释义窗口，15 本词典可以 C-j 切换，私人词典里也有几个常查的口语短语。

整个过程没有任何网络请求。StarDict 格式的好处就是——所有词典都是本地文件，sdcv-pure.el 纯 Elisp 读取。

状态：完全无阻碍。

第 35-45 分钟 — 搜索

突然想起之前写过一些关于工具选择的想法，不记得存在哪个文件里了。

在 Emacs 里直接 M-x elgrep，输入关键词，选择要检索的目录。它基于 ripgrep 在多文件中检索，结果弹出一个带位置的缓冲区，点击就能跳到对应位置。很快定位到目标文件。

接着想找一篇之前写的草稿，命令行里直接 rg 搜关键词，同样很快命中。

状态：完全无阻碍。

第 45-55 分钟 — 查邮件

想确认朋友昨天发的一条消息。打开 Emacs notmuch 前端，用关键词检索。定时任务已经把最近的邮件同步到了本地，搜索结果正常显示，打开阅读没有任何问题。

状态：完全无阻碍。

第 55-60 分钟 — 翻书签

想找一个之前收藏过的工具介绍链接——Raindrop 打不开了，它是纯云服务。

状态：这是唯一的缺口。

测试结果汇总

活动 工具 离线状态 说明
写作 org-mode + evil-mode 完全可用 纯本地，:w 保存不受网络影响
搜索 elgrep + ripgrep 完全可用 多文件检索速度不依赖网络
版本控制 Git（git-bash） 完全可用 add、commit、log 都没问题
查词 sdcv-pure.el 完全可用 15 本离线词典，无延迟
阅读 Elfeed 完全可用 已缓存文章可正常搜索和阅读
邮件 notmuch 完全可用 定时同步，本地搜索和阅读正常
书签 Raindrop 不可用 纯云服务，无离线方案

分析

可用率：86%。 六项完全可用，一项不可用。

看时间分配更准确——60 分钟里有 55 分钟是流畅的。唯一的缺口是书签。

写作、阅读、查词、搜索、邮件——五个核心活动，全部离线可用。

Raindrop 是目前唯一的云依赖。 书签看起来是个小东西，但收藏过的链接里有很多是重要的参考资料。Raindrop 本身是一个不错的工具，问题在于它的数据只存在云端。这个缺口有解——以后可能写一篇文章讲本地书签方案。

结论

“不依赖云的离线效率系统”不是乌托邦。在一个安静的周末上午，核心活动确实可以完全离线——写作、阅读、查词、搜索、邮件，全部撑住了。

但这个测试也给了我两个更深的认识：

  1. 离线系统的价值，体现在断网时——平时你不会注意到你的工具栈有多依赖云端。只有真正关掉 Wi-Fi，才知道哪些环节是脆弱的，哪些其实早就有本地方案了。
  2. notmuch 是被低估的组件——很多人觉得邮件是最难离线的环节，但 notmuch + 定时同步的组合，让它变得和查笔记一样自然。这也是整个离线系统里最安静的一部分——它不性感，但一直在工作。

工具的目的是帮我们完成任务，而不是成为任务本身。断网一小时后重新连上 Wi-Fi，我没有丢失任何数据，没有遗漏任何想法。这一小时证明了一件事——大部分时候，你需要的东西其实就在手边。

系列回顾：

相关文章