如果有人问我最近业余时间在折腾点什么我大概率会甩出三个字母rea。全称是 Resource Efficiency Assistant翻译成大白话就是“资源效率助手”。它听起来很宏大实际上功能非常克制——把散落在剪贴板、终端输出、网页高亮和临时便签里的碎片信息统一收进来存在本地支持全文检索和轻量提醒仅此而已。这篇文章就围绕 rea 从想法到最小可用版本的全过程聊聊我踩过的坑和取舍给想自己搭效率工具、认同本地优先理念、或者纠结桌面应用技术栈的朋友一个参考。之所以把它当成一个“正经项目”而不是随便写个脚本是因为我发现一个尴尬的事实工具越多信息越碎。浏览器里存了一批网页片段IM 里躺着一堆文件本地终端跑出来的结果没人整理截图更是不可能有索引。等三个月后想找一条当初明明见过的重要信息能翻出一身汗。rea 要解决的就是这个“过几天就再也找不回来”的问题它不追求炫酷只追求一件事你曾经见过的内容任何时候都能被搜回来。1. 项目缘起“rea”三个字母背后解决的真实痛点1.1 一天里的信息碎片都在哪里我随便列一下自己某天的工作流上午处理线上问题终端里滚动过几百行日志最后定位到关键报错时我复制了那行错误码下午给一个需求写方案浏览器里开了十几个标签页其中一段关于接口返回结构的描述很有价值我顺手高亮了一下晚上读文章时看到一个不错的架构图截图丢进了系统截图目录中间还穿插了别人发来的临时文档、自己敲的几行灵感便签。这些碎片有一点是共同的它们都真实存在过却在不同的容器里。终端日志不属于任何笔记软件截图没有 OCR 更谈不上搜索浏览器高亮数据大概率只存在于内存里。想“回头再找”是极端困难的事因为压根没有一个统一的、可搜索的视图。这不是靠自律能解决的问题。人脑的记忆检索本来就依赖上下文当上下文被拆散到五六个工具里检索失败是常态不是例外。所以我决定自己做一个东西把所有不需要二次加工的原始内容统一丢进去让“记录”变成零成本动作让“搜索”成为唯一出口。1.2 为什么“买现成的”不合适自然会有人说这类效率工具不是有很多吗那些在线剪藏笔记、大纲软件、云同步便签不都是干这个的确实它们做得比我的小工具成熟得多但我实际用下来总有几个点让人不舒服。数据总是在云上。哪怕只是几千条文本片段也默认被同步到服务商的服务器本地客户端更像一个“窗口”。对一个只想私下检索个人资料的场景来说这种设计是多余的。离线能力普遍很弱地铁上或者网络抽风时连打开历史记录都会转圈。格式是私有的导入导出永远丢元数据进去容易出来难。插件生态也都是围着别人家的格式转我想加一个“从终端直接丢一段高亮”的功能几乎不可能。还有一个更微妙的问题很多工具的设计重心是“组织”也就是让你手动分类、建文件夹、写标签。但碎片信息的本质是“来不及组织”。我要的东西是把组织成本降到零靠全量存储和全文检索兜底。所以从需求最底层就分道扬镳了——我需要的是一个沉默的、本地优先的抄录员不是另一个等待我精心维护的文件夹系统。1.3 命名由来与边界感rea 这个名字是临时起的。当时想着项目名必须短短到单手能敲完于是就有了 rea。全称 Resource Efficiency Assistant正好对上“资源效率”这个定位。rea 在另一种语言里还能解读成“真实、真正”算是私心加的一点双关真正可检索、真正属于你自己、真正离线可用。这个命名也帮我把项目边界框死了。三个字母的项目野心不能大。rea 从一开始就明确不做四件事不做云端协作不做多人共享不做富文本编辑器不做移动端。它只做三件事收进来、存得下、搜得出。边界一旦划清后面所有技术决策都变得容易很多——凡是超出这三个动作的需求一律砍掉或者推迟到一个叫“以后再说”的清单里。1.4 最小闭环的定义我给自己定义的最小闭环是剪贴板里复制过的文本能被自动记录一两行命令可以把当前终端内容推给 rea再打开一个极简的搜索窗口输入关键词能秒出结果。那时候我意识到只要这三件事通了这个工具就已经比大多数“把文件复制进云盘”的收藏方式更实用了。后面做的所有事情都是在这个闭环上的加固和体验优化。2. 核心架构本地优先的“输入-存储-检索”闭环2.1 三层模型输入管道、存储引擎、检索交互rea 的内部架构听起来很简单但为了保证后面不写乱我在一开始就拆成了三层。输入管道层负责接入各种来源。剪贴板监听、命令行推送、目录监视、浏览器扩展的转发都算这一层。每一个输入源都被抽象成 Producer输出统一格式的事件对象。这样有个明显的好处后续加新来源时不用动存储和检索层只要新写一个 Producer 就行。存储引擎层负责落盘和索引。我选择的是嵌入式数据库配合全文索引。这一层不关心数据是从哪来的只关心写入和查询性能。交互层是用户最终看到的那个搜索窗口。它不直接操作数据库而是通过一个查询接口拿结果。搜索窗口保持得极其薄重要逻辑全在底层这样以后想换界面技术栈也不用伤筋动骨。这个分层的好处是把“记录”和“检索”彻底解耦。记录时不需要等待界面检索时不需要知道数据源头。就算前端完全崩了数据还在换个壳子就能恢复。2.2 存储选型为什么用嵌入式数据库而不是文件目录存储层的选型是 rea 开发早期最需要想清楚的一件事。直觉方案是“一个目录 Markdown 文件”。比如每条记录一个文件文件名带时间戳正文就是原样文本。但这条路径会在数据量上千条之后逐渐难受全文检索要靠人工翻目录每加一个来源就要约定新的目录结构关联关系比如某条记录来自哪个窗口、当时的上下文是什么根本表达不了。这本质上是把“数据库该做的事”外包给了文件系统。所以我直接选了嵌入式数据库。数据全部落在一个单文件里不需要额外起服务进程死了也不怕支持 SQL 查询想按来源过滤、按时间范围过滤都很方便自带全文索引是现成的检索能力备份就是一个文件拷贝简单到不需要写备份工具。这个选择对整个项目影响极大。它意味着 rea 的每次“记录”都天然带上了结构化字段来源类型、原始文本、捕获时间、附加上下文。查“上周的终端日志”和“三个月前的一条剪贴板”在 SQL 层面没有任何差别。2.3 表结构设计一次建表改了三版rea 最早版本的建表语句非常朴素实际用了一阵子后迭代了三次。这里直接放最终版的精简结构CREATE TABLE events ( id INTEGER PRIMARY KEY AUTOINCREMENT, source TEXT NOT NULL DEFAULT clipboard, body TEXT NOT NULL, extra TEXT, created_at INTEGER NOT NULL, updated_at INTEGER ); CREATE TABLE tags ( id INTEGER PRIMARY KEY AUTOINCREMENT, event_id INTEGER NOT NULL REFERENCES events(id) ON DELETE CASCADE, name TEXT NOT NULL ); CREATE INDEX idx_events_created_at ON events(created_at); CREATE INDEX idx_events_source ON events(source);看起来简单但这三张表是踩过不少坑才定的。第一个版本没有 tags 表所有分类信息硬塞在 extra 字段里后来发现“按标签检索”和“按来源检索”是两种完全不同的需求必须拆开。第二个版本没有updated_at导致修改记录时不知道什么时候改的排查数据异常很费劲。第三版才稳定下来目前改了几个月都没动过表结构。原则上rea 不追求设计上的完美只追求“查得到”。把一张表拆成三张换来的是查询语句写起来舒服避免未来数据量上来后靠应用层硬过滤。2.4 本地优先带来的“免费福利”这个架构带来的第一个免费福利是隐私。全部数据都存在本机没有账号、没有同步端点、没有“产品经理在服务器另一端看着你”。第二个福利是速度。SQLite 的单文件读取在本地磁盘上几千条数据做全文检索基本是毫秒级完全不需要网络请求。第三个福利是可控性。数据库文件在哪个目录、要不要备份、要不要被备份软件带走都由我决定。当然本地优先也是有代价的换电脑时数据不会自动跟着走想在多设备间共享得自己设计同步方案。但至少第一版不用背这么重的包袱。工具是拿来解决问题的不是拿来制造新问题的本地优先在 rea 的场景里利远远大于弊。3. 技术选型的心路从 Electron 到 Tauri 的取舍3.1 桌面技术栈的横向对比rea 虽然把逻辑层和数据层独立出来了但总归需要一个桌面壳子。市面上常见的桌面方案我三个都用过或者调研过最后总结成一张对比表。方案打包体积内存占用主要语言生态成熟度适合什么场景WebView 系桌面框架通常 100MB 起步高单进程 200MB 很常见JS/TS最成熟快速出产品、团队协作项目Python 桌面框架中等但依赖地狱中Python数据处理方便原型、内部小工具Rust 后端 系统 WebView10MB 级别低空载约 50MBRust 前端仍在完善期追求体积小、性能高、隐私强的工具纯 Rust 原生 GUI小低Rust生态较窄极简工具、深度偏执玩家rea 的定位是“单人使用、常驻后台、开机自启”这意味着内存占用会直接影响日常体验。一个工具如果开个后台就吃掉几百兆内存即使功能再强也会有一天因为“感觉卡”而被关掉。所以我很早就排除了重壳方案。Python 方案在写脚本时很舒服但真要做常驻托盘程序打包和启动速度都会拖后腿。最终选择了“Rust 后端 系统 WebView”的方向。界面上不需要嵌入很重的框架因为 rea 的交互只有一块搜索框和一张结果列表用原生 Web 技术足够撑起来。而 Rust 后端负责全局快捷键、剪贴板监听、SQLite 封装这些脏活累活。这个组合的体积优势非常明显最终打包出来的安装包只有十几兆后台内存占用也保持在低位。3.2 为什么“壳子越薄越好”一个很反直觉的经验是桌面效率工具的价值不在于界面多好看而在于多快、多不易察觉。rea 的搜索窗口设计成“呼之即来、挥之即去”的形态用户按一个全局快捷键输入关键词回车关闭。整个流程不应该超过三秒。如果界面框架重了启动时有白屏、渲染卡片时掉帧这种体验就是在给用户“做减法”。所以我刻意把那层 WebView 用得像个“终端模拟器”不引入前端路由、不搞状态管理库、不搞组件体系一个静态页面加一个轻量的查询脚本就结束了。事实证明这个决策让首版开发速度快了一倍排查问题时也从来不用纠结“是不是前端的 bug”。3.3 全局快捷键、系统托盘和剪贴板监听的关键姿势桌面应用真正麻烦的不是写 UI而是与操作系统打交道。rea 主要依赖三个系统级能力全局快捷键、系统托盘、剪贴板监听。全局快捷键用系统的全局热键 API 注册难点在于不能和别的应用冲突。rea 的做法是允许用户自己改快捷键默认是 CtrlShiftSpace打开搜索窗CtrlShiftC 用来把当前剪贴板内容直接入库。剪贴板监听是一个典型的两难轮询简单但费 CPU事件监听省电但兼容性差。rea 在 Windows 上走事件订阅在 macOS 和 Linux 上退化为低频率轮询轮询间隔拉到 2000ms兼顾实时性和资源占用。这里还要处理一个很容易被忽略的点剪贴板里不只有我们主动复制的文字还有复制文件、复制图片、复制富文本等场景。rea 只关心纯文本内容所以监听器每次先判断格式如果是图片或文件就直接跳过避免把一堆不可检索的二进制灌进库里。3.4 前端界面“重剑无锋”的原则rea 的搜索界面没有用任何框架一个 HTML 页面加原生脚本就完成了数据请求和渲染。为什么这么做因为 rea 的交互路径太短了打开窗口、输入、回车、关闭。选项多了反而干扰。界面上只有三样东西一个输入框、一个结果列表、一个状态提示。前端逻辑里最重要的事情反而是“高亮命中词”。查询关键词在结果中用高亮标签包裹这样一眼就能看出为什么这条记录被搜出来。这个功能如果在重框架里反而要绕一圈在原生脚本里就是一段正则的事。界面保持简单还有一个好处就算换了个 WebView 内核页面代码基本不用动。越是简单的界面越不容易坏。4. 从零跑通最小版本的完整流程4.1 环境准备与项目初始化如果你也想复刻一个类似的工具我把最小可跑版本的全流程放在这里。首先准备基础环境Rust 编译链、Node.js 运行时、以及对应平台的系统 WebView 依赖。Rust 是后端主力Node 只是用来跑构建脚本后面你会发现真正的逻辑里几乎不需要 JavaScript。初始化命令大致是这样# 安装 Tauri 的命令行工具 cargo install tauri-cli # 创建项目骨架 cargo new rea --lib cd rea # 添加核心依赖 cargo add tauri cargo add sqlite cargo add arboard cargo add tao注意创建的是 lib 类型而不是 bin 类型因为桌面壳子的入口由 Tauri 管理主逻辑做在库文件里将来测试也更好写。这个结构是我试错了两次才确认的一开始用 bin 结构后来发现测试和命令行工具都要单独复用核心模块再改就麻烦了。4.2 剪贴板监听模块的实现最小版本里剪贴板监听是 rea 的“收入来源”。我用了剪贴板操作库它负责跨平台读写系统剪贴板。核心逻辑是一个循环读当前剪贴板文本和上一次快照比较有变化就投喂给存储模块。// rea/src/clipboard.rs // 示意代码rea 的剪贴板监听主循环 fn watch_clipboard(ctx: AppContext) { let mut last String::new(); loop { let current ctx.clipboard.get_text().unwrap_or_default(); if !current.is_empty() current ! last { ctx.ingest(ClipboardEvent { body: current.clone(), captured_at: now(), }); last current; } std::thread::sleep(Duration::from_millis(2000)); } }这段代码短但隐藏了一个细节如果剪贴板里有几 MB 的超长文本每次都要做全量比较和入库既浪费 IO 又污染数据库。我在实际版本里加了长度上限超过一定字符的剪贴板内容只存前一段或在界面上弹提示让用户决定是否存入。否则一条不小心复制了整篇文章的内容会把检索结果噪声拉高很多。4.3 存储模块的封装存储模块把 SQLite 的裸操作包了一层对外只暴露两个方法insert_event和search。insert 负责把事件对象变成数据库记录search 负责跑全文检索并返回带高亮信息的结果。封装的目的只有一个上层代码不要出现任何 SQL 字符串。// rea/src/store.rs // 示意代码存储封装的核心方法 pub fn insert_event(self, ev: Event) - Resulti64 { let conn self.conn.lock()?; conn.execute( INSERT INTO events (source, body, extra, created_at) VALUES (?1, ?2, ?3, ?4), params![ev.source, ev.body, ev.extra, ev.created_at], )?; Ok(conn.last_insert_rowid()) } pub fn search(self, query: str, limit: u32) - ResultVecSearchHit { let conn self.conn.lock()?; let mut stmt conn.prepare( SELECT id, body, source, created_at FROM events WHERE body LIKE ?1 ORDER BY created_at DESC LIMIT ?2, )?; // 展开查询参数映射为 SearchHit }第一版没有用全文索引直接用了 LIKE 查询。数据量在几百条时LIKE 的速度完全够用一天记录一百条一个月也就几千条SQLite 处理这种量级毫无压力。真正要上全文索引是数据量上万条以后的事到时候再把表迁移到 FTS5 也不迟。过早优化是新手最容易犯的错误rea 的原则是先跑通再加固。4.4 搜索窗口和全局快捷键的打通当数据已经能进来剩下的就是怎么把它搜出来。Tauri 提供了系统托盘和全局快捷键的能力。按下预设快捷键时前端窗口显示并聚焦输入查询词后前端通过一个 rust 命令把关键词传给后端后端调用 store.search把结果返回给前端渲染。# 示意代码tauri invoke 调用后端搜索 # 前端 JS 侧 const hits await window.__TAURI__.invoke(search_events, { query: keyword, limit: 50, });这里最需要注意的细节是“焦点管理”。搜索窗口打开后必须立即抢到输入焦点否则快捷键按下去后还要再点一下输入框体验就很断。rea 在窗口 show 事件里直接对输入框调 focus并且在失焦时自动隐藏窗口。这个交互看似微不足道却是效率工具是否“肌肉记忆”的关键。4.5 最小版本的验证清单当时我给自己列了一个验证清单全部通过才算跑通。剪贴板复制一段文字两秒后在数据库里查到终端里运行一条推送命令内容能进库按快捷键弹出搜索窗输入一个词能搜到对应的历史记录系统重启后rea 自动启动数据还在。这四条全过最小闭环就成了。跑完这个最小版本我发现整个流程最花时间的地方根本不是 Rust 或 Tauri 的 API而是“交互细节”。比如托盘的菜单文案怎么写搜索结果的排序怎么满足直觉快捷键冲突怎么提示。这些事看起来小堆起来就是用户体验的全部。5. 实测中踩过的坑性能、跨平台和数据库锁5.1 剪贴板轮询导致 CPU 飙升第一次把 rea 挂在后台跑了一天打开任务管理器吓了一跳一个看似啥也没干的进程CPU 占用在 10% 上下浮动偶尔冲到 30%。用分析工具一看罪魁祸首是剪贴板轮询循环每次循环都做“读剪贴板内容 全量比较字符串”而且根据系统库的文档读剪贴板本身在某些平台会触发全局锁竞争。解决办法是把“读剪贴板”的频率和“比较内容”的频率拆开。先用一个低开销的版本号或内容哈希做快速比对只有在哈希变了才真正读取完整文本。同时把轮询间隔从 500ms 改成了 2000ms。实测 CPU 占用直接降到 2% 以内。这个教训是凡是常驻后台的轮询一定要把“探测”和“处理”分开不要每次都用最重的操作去试探。5.2 剪贴板里没文本只有文件路径时真实环境里用户复制的东西千奇百怪。第一次遇到复制文件后rea 也能采到一条“路径文本”确实存进来了。但第二次复制同一个文件时由于路径一模一样就触发了“内容没变化就不入库”的规则导致后续这个文件相关的操作全部丢失。后来加了事件类型字段把剪贴板里的内容分为“文本输入”和“文件路径”文件路径每次都记录文本则做去重。其实很多坑都不是代码 bug而是把真实世界的多样性想简单了。5.3 SQLite 在 Windows 上频繁报 database is lockedrea 第一版在 Linux 上开发测试一直很安静。换到 Windows 后系统托盘和剪贴板监听模块同时在写库偶尔还会开着搜索窗口查库很快就出现了database is locked异常。这个问题的根源是 SQLite 默认在多个连接并发写时会互相阻塞而我的代码里没有做任何并发控制。修复方式有三个缺一不可。把数据库连接设置为单例通过互斥锁保证同一时刻只有一个写入者开启 WAL 模式让读写可以并行设置合理的 busy_timeout告诉 SQLite“如果别人锁着先等一下而不是立刻报错”。修完之后再也没见到 locked 异常。// 示意代码开启 WAL 模式与 busy_timeout let conn Connection::open_with_flags(path, OpenFlags::SQLITE_OPEN_READ_WRITE)?; conn.pragma_update(None, journal_mode, WAL)?; conn.pragma_update(None, busy_timeout, 5000)?;这个坑提醒我在 Linux 上跑通不等于跨平台跑通。桌面应用的人均使用场景一定包含 Windows所以在设计存储层时就要把并发模型想清楚。尽量不在业务代码里多个地方创建数据库连接统一走一个访问入口是最省心的做法。5.4 全文检索LIKE 的瓶颈和 FTS5 的中文问题数据量到了三万条左右LIKE 查询开始有感觉了尤其查询词碰巧是短字符全表扫描的耗时会上到几百毫秒。于是我把存储层迁到了 SQLite 的 FTS5 全文索引。这个迁移本身很顺但中文分词给了我足够的教训。FTS5 默认的 unicode61 分词器按空格和标点分词对中文句子几乎会切成整句 or 单字两种结果都不可用。比如“资源效率助手”这个查询在默认分词器下可能被拆成“资源效率助手”整串搜不到“效率助手”。我最终用了 trigram 分词器它按三个连续字符滑动切分对中文来说虽然会占用更多索引空间但至少短词也能搜到并且搜“效率助手”能命中“资源效率助手”里的片段。索引体积翻了三倍但换来的是查询体验正常值得。5.5 打包体积的控制与启动速度优化第一次打包出来安装包体积 8MB这个数字让身边用 Electron 做工具的朋友很惊讶。但 rea 的目标还不只是体积小启动速度也必须快。桌面效率工具的生死线是“按快捷键到出现窗口”超过一秒基本就废了。我把启动时间压进 500ms 内方法有两条窗口先显示骨架再异步加载数据避免启动时同步做 SQL 查询数据库连接惰性初始化用户没按快捷键时后端进程不被存储模块拖住。体积和速度其实是同一个哲学不必要的依赖都是慢性毒药。每加一个库都要问问自己它带来了多少价值又让安装包和启动时间付出了多少代价。5.6 一个容易被忽视的问题重复记录和脏数据随着使用时间变长重复记录开始出现。比如同一个网页片段被复制了三次或一份终端日志被推送了两次。rea 在存储层加了相似度检测对短文本做完全去重对长文本计算局部哈希若完全相同就直接跳过。这个机制避免了数据库里出现大量“同义反复”的片段也保证了搜索结果的质量。数据不是越多越好干净的数据才有检索价值。6. 后续路线rea 还能怎么长6.1 输入侧插件终端、浏览器、截图 OCR 一条龙最小版本跑通后最先想补的是输入侧。rea 把每个输入源都做成插件的形态插件只负责把外部内容变成统一事件推送进库。我目前接入了三个插件终端推送命令、浏览器扩展转发高亮文本、目录监视器。截图 OCR 排在下个版本识别出的文字直接入库这样连图片里的信息都能被搜到。插件接口设计得尽量薄一个插件就是一个脚本暴露produce()方法返回事件数组。这种设计让 rea 的扩展点清晰可见想接一个新来源甚至不用改主程序只要按接口写一个小脚本就行。6.2 输出侧插件不只是搜索结果输出侧的插件更有意思。除了搜索窗口rea 可以把符合条件的记录转发出去。比如凌晨把一天新增的碎片汇总成一个 Markdown 报告比如某条带提醒标签的记录到时间后在系统托盘弹通知。输出侧的核心是“按规则发货”把 rea 从被动查询变成主动服务。我实现了一个很轻的规则引擎订阅一个 SQL 查询再定义一个动作比如发送通知或写文件。这个设计让 rea 能胜任“每日回顾”和“定时提醒”两个场景而这一切依然全部在本地完成。6.3 给想复刻的人的三条建议如果有人想照着 rea 的思路做自己的工具我给三条建议。第一先做最小闭环再谈架构不要一开始就设计插件系统、同步方案一个剪贴板记录加一个搜索框就能跑完核心路径先把路径打通。第二把数据层和界面层彻底分开哪怕界面只是临时用的也要通过接口访问数据这样换壳子才不会是重写。第三尽早开启 SQLite 的 WAL 模式并统一写入口并发问题在开发时发现不了一旦常驻后台就会频繁咬人。rea 现在的状态离我理想中的“私人信息中枢”还有距离但核心价值已经出来了所有进去的东西都能出来出来的速度足够快。这种“确定性”是很多商业工具给不了的因为它不依赖网络、不依赖云端、不依赖服务商的良心。它只依赖一个本地文件和一行 SQL 查询。如果只让我留一个心得那就是个人效率工具最重要的不是功能多而是让人敢放心地把东西放进去。只要存储端绝对可靠、检索端绝对快速工具自然会被天天使用。rea 这个名字现在对我来说已经不只代表 Resource Efficiency Assistant更像一种提醒——真正属于自己的信息才谈得上高效。 
长河君 · 2026/10/20 17:49:26 · 阅读 1.2k 本地优先的剪贴板检索工具rea：Rust与Tauri构建碎片信息助手
如果有人问我最近业余时间在折腾点什么我大概率会甩出三个字母rea。全称是 Resource Efficiency Assistant翻译成大白话就是“资源效率助手”。它听起来很宏大实际上功能非常克制——把散落在剪贴板、终端输出、网页高亮和临时便签里的碎片信息统一收进来存在本地支持全文检索和轻量提醒仅此而已。这篇文章就围绕 rea 从想法到最小可用版本的全过程聊聊我踩过的坑和取舍给想自己搭效率工具、认同本地优先理念、或者纠结桌面应用技术栈的朋友一个参考。之所以把它当成一个“正经项目”而不是随便写个脚本是因为我发现一个尴尬的事实工具越多信息越碎。浏览器里存了一批网页片段IM 里躺着一堆文件本地终端跑出来的结果没人整理截图更是不可能有索引。等三个月后想找一条当初明明见过的重要信息能翻出一身汗。rea 要解决的就是这个“过几天就再也找不回来”的问题它不追求炫酷只追求一件事你曾经见过的内容任何时候都能被搜回来。1. 项目缘起“rea”三个字母背后解决的真实痛点1.1 一天里的信息碎片都在哪里我随便列一下自己某天的工作流上午处理线上问题终端里滚动过几百行日志最后定位到关键报错时我复制了那行错误码下午给一个需求写方案浏览器里开了十几个标签页其中一段关于接口返回结构的描述很有价值我顺手高亮了一下晚上读文章时看到一个不错的架构图截图丢进了系统截图目录中间还穿插了别人发来的临时文档、自己敲的几行灵感便签。这些碎片有一点是共同的它们都真实存在过却在不同的容器里。终端日志不属于任何笔记软件截图没有 OCR 更谈不上搜索浏览器高亮数据大概率只存在于内存里。想“回头再找”是极端困难的事因为压根没有一个统一的、可搜索的视图。这不是靠自律能解决的问题。人脑的记忆检索本来就依赖上下文当上下文被拆散到五六个工具里检索失败是常态不是例外。所以我决定自己做一个东西把所有不需要二次加工的原始内容统一丢进去让“记录”变成零成本动作让“搜索”成为唯一出口。1.2 为什么“买现成的”不合适自然会有人说这类效率工具不是有很多吗那些在线剪藏笔记、大纲软件、云同步便签不都是干这个的确实它们做得比我的小工具成熟得多但我实际用下来总有几个点让人不舒服。数据总是在云上。哪怕只是几千条文本片段也默认被同步到服务商的服务器本地客户端更像一个“窗口”。对一个只想私下检索个人资料的场景来说这种设计是多余的。离线能力普遍很弱地铁上或者网络抽风时连打开历史记录都会转圈。格式是私有的导入导出永远丢元数据进去容易出来难。插件生态也都是围着别人家的格式转我想加一个“从终端直接丢一段高亮”的功能几乎不可能。还有一个更微妙的问题很多工具的设计重心是“组织”也就是让你手动分类、建文件夹、写标签。但碎片信息的本质是“来不及组织”。我要的东西是把组织成本降到零靠全量存储和全文检索兜底。所以从需求最底层就分道扬镳了——我需要的是一个沉默的、本地优先的抄录员不是另一个等待我精心维护的文件夹系统。1.3 命名由来与边界感rea 这个名字是临时起的。当时想着项目名必须短短到单手能敲完于是就有了 rea。全称 Resource Efficiency Assistant正好对上“资源效率”这个定位。rea 在另一种语言里还能解读成“真实、真正”算是私心加的一点双关真正可检索、真正属于你自己、真正离线可用。这个命名也帮我把项目边界框死了。三个字母的项目野心不能大。rea 从一开始就明确不做四件事不做云端协作不做多人共享不做富文本编辑器不做移动端。它只做三件事收进来、存得下、搜得出。边界一旦划清后面所有技术决策都变得容易很多——凡是超出这三个动作的需求一律砍掉或者推迟到一个叫“以后再说”的清单里。1.4 最小闭环的定义我给自己定义的最小闭环是剪贴板里复制过的文本能被自动记录一两行命令可以把当前终端内容推给 rea再打开一个极简的搜索窗口输入关键词能秒出结果。那时候我意识到只要这三件事通了这个工具就已经比大多数“把文件复制进云盘”的收藏方式更实用了。后面做的所有事情都是在这个闭环上的加固和体验优化。2. 核心架构本地优先的“输入-存储-检索”闭环2.1 三层模型输入管道、存储引擎、检索交互rea 的内部架构听起来很简单但为了保证后面不写乱我在一开始就拆成了三层。输入管道层负责接入各种来源。剪贴板监听、命令行推送、目录监视、浏览器扩展的转发都算这一层。每一个输入源都被抽象成 Producer输出统一格式的事件对象。这样有个明显的好处后续加新来源时不用动存储和检索层只要新写一个 Producer 就行。存储引擎层负责落盘和索引。我选择的是嵌入式数据库配合全文索引。这一层不关心数据是从哪来的只关心写入和查询性能。交互层是用户最终看到的那个搜索窗口。它不直接操作数据库而是通过一个查询接口拿结果。搜索窗口保持得极其薄重要逻辑全在底层这样以后想换界面技术栈也不用伤筋动骨。这个分层的好处是把“记录”和“检索”彻底解耦。记录时不需要等待界面检索时不需要知道数据源头。就算前端完全崩了数据还在换个壳子就能恢复。2.2 存储选型为什么用嵌入式数据库而不是文件目录存储层的选型是 rea 开发早期最需要想清楚的一件事。直觉方案是“一个目录 Markdown 文件”。比如每条记录一个文件文件名带时间戳正文就是原样文本。但这条路径会在数据量上千条之后逐渐难受全文检索要靠人工翻目录每加一个来源就要约定新的目录结构关联关系比如某条记录来自哪个窗口、当时的上下文是什么根本表达不了。这本质上是把“数据库该做的事”外包给了文件系统。所以我直接选了嵌入式数据库。数据全部落在一个单文件里不需要额外起服务进程死了也不怕支持 SQL 查询想按来源过滤、按时间范围过滤都很方便自带全文索引是现成的检索能力备份就是一个文件拷贝简单到不需要写备份工具。这个选择对整个项目影响极大。它意味着 rea 的每次“记录”都天然带上了结构化字段来源类型、原始文本、捕获时间、附加上下文。查“上周的终端日志”和“三个月前的一条剪贴板”在 SQL 层面没有任何差别。2.3 表结构设计一次建表改了三版rea 最早版本的建表语句非常朴素实际用了一阵子后迭代了三次。这里直接放最终版的精简结构CREATE TABLE events ( id INTEGER PRIMARY KEY AUTOINCREMENT, source TEXT NOT NULL DEFAULT clipboard, body TEXT NOT NULL, extra TEXT, created_at INTEGER NOT NULL, updated_at INTEGER ); CREATE TABLE tags ( id INTEGER PRIMARY KEY AUTOINCREMENT, event_id INTEGER NOT NULL REFERENCES events(id) ON DELETE CASCADE, name TEXT NOT NULL ); CREATE INDEX idx_events_created_at ON events(created_at); CREATE INDEX idx_events_source ON events(source);看起来简单但这三张表是踩过不少坑才定的。第一个版本没有 tags 表所有分类信息硬塞在 extra 字段里后来发现“按标签检索”和“按来源检索”是两种完全不同的需求必须拆开。第二个版本没有updated_at导致修改记录时不知道什么时候改的排查数据异常很费劲。第三版才稳定下来目前改了几个月都没动过表结构。原则上rea 不追求设计上的完美只追求“查得到”。把一张表拆成三张换来的是查询语句写起来舒服避免未来数据量上来后靠应用层硬过滤。2.4 本地优先带来的“免费福利”这个架构带来的第一个免费福利是隐私。全部数据都存在本机没有账号、没有同步端点、没有“产品经理在服务器另一端看着你”。第二个福利是速度。SQLite 的单文件读取在本地磁盘上几千条数据做全文检索基本是毫秒级完全不需要网络请求。第三个福利是可控性。数据库文件在哪个目录、要不要备份、要不要被备份软件带走都由我决定。当然本地优先也是有代价的换电脑时数据不会自动跟着走想在多设备间共享得自己设计同步方案。但至少第一版不用背这么重的包袱。工具是拿来解决问题的不是拿来制造新问题的本地优先在 rea 的场景里利远远大于弊。3. 技术选型的心路从 Electron 到 Tauri 的取舍3.1 桌面技术栈的横向对比rea 虽然把逻辑层和数据层独立出来了但总归需要一个桌面壳子。市面上常见的桌面方案我三个都用过或者调研过最后总结成一张对比表。方案打包体积内存占用主要语言生态成熟度适合什么场景WebView 系桌面框架通常 100MB 起步高单进程 200MB 很常见JS/TS最成熟快速出产品、团队协作项目Python 桌面框架中等但依赖地狱中Python数据处理方便原型、内部小工具Rust 后端 系统 WebView10MB 级别低空载约 50MBRust 前端仍在完善期追求体积小、性能高、隐私强的工具纯 Rust 原生 GUI小低Rust生态较窄极简工具、深度偏执玩家rea 的定位是“单人使用、常驻后台、开机自启”这意味着内存占用会直接影响日常体验。一个工具如果开个后台就吃掉几百兆内存即使功能再强也会有一天因为“感觉卡”而被关掉。所以我很早就排除了重壳方案。Python 方案在写脚本时很舒服但真要做常驻托盘程序打包和启动速度都会拖后腿。最终选择了“Rust 后端 系统 WebView”的方向。界面上不需要嵌入很重的框架因为 rea 的交互只有一块搜索框和一张结果列表用原生 Web 技术足够撑起来。而 Rust 后端负责全局快捷键、剪贴板监听、SQLite 封装这些脏活累活。这个组合的体积优势非常明显最终打包出来的安装包只有十几兆后台内存占用也保持在低位。3.2 为什么“壳子越薄越好”一个很反直觉的经验是桌面效率工具的价值不在于界面多好看而在于多快、多不易察觉。rea 的搜索窗口设计成“呼之即来、挥之即去”的形态用户按一个全局快捷键输入关键词回车关闭。整个流程不应该超过三秒。如果界面框架重了启动时有白屏、渲染卡片时掉帧这种体验就是在给用户“做减法”。所以我刻意把那层 WebView 用得像个“终端模拟器”不引入前端路由、不搞状态管理库、不搞组件体系一个静态页面加一个轻量的查询脚本就结束了。事实证明这个决策让首版开发速度快了一倍排查问题时也从来不用纠结“是不是前端的 bug”。3.3 全局快捷键、系统托盘和剪贴板监听的关键姿势桌面应用真正麻烦的不是写 UI而是与操作系统打交道。rea 主要依赖三个系统级能力全局快捷键、系统托盘、剪贴板监听。全局快捷键用系统的全局热键 API 注册难点在于不能和别的应用冲突。rea 的做法是允许用户自己改快捷键默认是 CtrlShiftSpace打开搜索窗CtrlShiftC 用来把当前剪贴板内容直接入库。剪贴板监听是一个典型的两难轮询简单但费 CPU事件监听省电但兼容性差。rea 在 Windows 上走事件订阅在 macOS 和 Linux 上退化为低频率轮询轮询间隔拉到 2000ms兼顾实时性和资源占用。这里还要处理一个很容易被忽略的点剪贴板里不只有我们主动复制的文字还有复制文件、复制图片、复制富文本等场景。rea 只关心纯文本内容所以监听器每次先判断格式如果是图片或文件就直接跳过避免把一堆不可检索的二进制灌进库里。3.4 前端界面“重剑无锋”的原则rea 的搜索界面没有用任何框架一个 HTML 页面加原生脚本就完成了数据请求和渲染。为什么这么做因为 rea 的交互路径太短了打开窗口、输入、回车、关闭。选项多了反而干扰。界面上只有三样东西一个输入框、一个结果列表、一个状态提示。前端逻辑里最重要的事情反而是“高亮命中词”。查询关键词在结果中用高亮标签包裹这样一眼就能看出为什么这条记录被搜出来。这个功能如果在重框架里反而要绕一圈在原生脚本里就是一段正则的事。界面保持简单还有一个好处就算换了个 WebView 内核页面代码基本不用动。越是简单的界面越不容易坏。4. 从零跑通最小版本的完整流程4.1 环境准备与项目初始化如果你也想复刻一个类似的工具我把最小可跑版本的全流程放在这里。首先准备基础环境Rust 编译链、Node.js 运行时、以及对应平台的系统 WebView 依赖。Rust 是后端主力Node 只是用来跑构建脚本后面你会发现真正的逻辑里几乎不需要 JavaScript。初始化命令大致是这样# 安装 Tauri 的命令行工具 cargo install tauri-cli # 创建项目骨架 cargo new rea --lib cd rea # 添加核心依赖 cargo add tauri cargo add sqlite cargo add arboard cargo add tao注意创建的是 lib 类型而不是 bin 类型因为桌面壳子的入口由 Tauri 管理主逻辑做在库文件里将来测试也更好写。这个结构是我试错了两次才确认的一开始用 bin 结构后来发现测试和命令行工具都要单独复用核心模块再改就麻烦了。4.2 剪贴板监听模块的实现最小版本里剪贴板监听是 rea 的“收入来源”。我用了剪贴板操作库它负责跨平台读写系统剪贴板。核心逻辑是一个循环读当前剪贴板文本和上一次快照比较有变化就投喂给存储模块。// rea/src/clipboard.rs // 示意代码rea 的剪贴板监听主循环 fn watch_clipboard(ctx: AppContext) { let mut last String::new(); loop { let current ctx.clipboard.get_text().unwrap_or_default(); if !current.is_empty() current ! last { ctx.ingest(ClipboardEvent { body: current.clone(), captured_at: now(), }); last current; } std::thread::sleep(Duration::from_millis(2000)); } }这段代码短但隐藏了一个细节如果剪贴板里有几 MB 的超长文本每次都要做全量比较和入库既浪费 IO 又污染数据库。我在实际版本里加了长度上限超过一定字符的剪贴板内容只存前一段或在界面上弹提示让用户决定是否存入。否则一条不小心复制了整篇文章的内容会把检索结果噪声拉高很多。4.3 存储模块的封装存储模块把 SQLite 的裸操作包了一层对外只暴露两个方法insert_event和search。insert 负责把事件对象变成数据库记录search 负责跑全文检索并返回带高亮信息的结果。封装的目的只有一个上层代码不要出现任何 SQL 字符串。// rea/src/store.rs // 示意代码存储封装的核心方法 pub fn insert_event(self, ev: Event) - Resulti64 { let conn self.conn.lock()?; conn.execute( INSERT INTO events (source, body, extra, created_at) VALUES (?1, ?2, ?3, ?4), params![ev.source, ev.body, ev.extra, ev.created_at], )?; Ok(conn.last_insert_rowid()) } pub fn search(self, query: str, limit: u32) - ResultVecSearchHit { let conn self.conn.lock()?; let mut stmt conn.prepare( SELECT id, body, source, created_at FROM events WHERE body LIKE ?1 ORDER BY created_at DESC LIMIT ?2, )?; // 展开查询参数映射为 SearchHit }第一版没有用全文索引直接用了 LIKE 查询。数据量在几百条时LIKE 的速度完全够用一天记录一百条一个月也就几千条SQLite 处理这种量级毫无压力。真正要上全文索引是数据量上万条以后的事到时候再把表迁移到 FTS5 也不迟。过早优化是新手最容易犯的错误rea 的原则是先跑通再加固。4.4 搜索窗口和全局快捷键的打通当数据已经能进来剩下的就是怎么把它搜出来。Tauri 提供了系统托盘和全局快捷键的能力。按下预设快捷键时前端窗口显示并聚焦输入查询词后前端通过一个 rust 命令把关键词传给后端后端调用 store.search把结果返回给前端渲染。# 示意代码tauri invoke 调用后端搜索 # 前端 JS 侧 const hits await window.__TAURI__.invoke(search_events, { query: keyword, limit: 50, });这里最需要注意的细节是“焦点管理”。搜索窗口打开后必须立即抢到输入焦点否则快捷键按下去后还要再点一下输入框体验就很断。rea 在窗口 show 事件里直接对输入框调 focus并且在失焦时自动隐藏窗口。这个交互看似微不足道却是效率工具是否“肌肉记忆”的关键。4.5 最小版本的验证清单当时我给自己列了一个验证清单全部通过才算跑通。剪贴板复制一段文字两秒后在数据库里查到终端里运行一条推送命令内容能进库按快捷键弹出搜索窗输入一个词能搜到对应的历史记录系统重启后rea 自动启动数据还在。这四条全过最小闭环就成了。跑完这个最小版本我发现整个流程最花时间的地方根本不是 Rust 或 Tauri 的 API而是“交互细节”。比如托盘的菜单文案怎么写搜索结果的排序怎么满足直觉快捷键冲突怎么提示。这些事看起来小堆起来就是用户体验的全部。5. 实测中踩过的坑性能、跨平台和数据库锁5.1 剪贴板轮询导致 CPU 飙升第一次把 rea 挂在后台跑了一天打开任务管理器吓了一跳一个看似啥也没干的进程CPU 占用在 10% 上下浮动偶尔冲到 30%。用分析工具一看罪魁祸首是剪贴板轮询循环每次循环都做“读剪贴板内容 全量比较字符串”而且根据系统库的文档读剪贴板本身在某些平台会触发全局锁竞争。解决办法是把“读剪贴板”的频率和“比较内容”的频率拆开。先用一个低开销的版本号或内容哈希做快速比对只有在哈希变了才真正读取完整文本。同时把轮询间隔从 500ms 改成了 2000ms。实测 CPU 占用直接降到 2% 以内。这个教训是凡是常驻后台的轮询一定要把“探测”和“处理”分开不要每次都用最重的操作去试探。5.2 剪贴板里没文本只有文件路径时真实环境里用户复制的东西千奇百怪。第一次遇到复制文件后rea 也能采到一条“路径文本”确实存进来了。但第二次复制同一个文件时由于路径一模一样就触发了“内容没变化就不入库”的规则导致后续这个文件相关的操作全部丢失。后来加了事件类型字段把剪贴板里的内容分为“文本输入”和“文件路径”文件路径每次都记录文本则做去重。其实很多坑都不是代码 bug而是把真实世界的多样性想简单了。5.3 SQLite 在 Windows 上频繁报 database is lockedrea 第一版在 Linux 上开发测试一直很安静。换到 Windows 后系统托盘和剪贴板监听模块同时在写库偶尔还会开着搜索窗口查库很快就出现了database is locked异常。这个问题的根源是 SQLite 默认在多个连接并发写时会互相阻塞而我的代码里没有做任何并发控制。修复方式有三个缺一不可。把数据库连接设置为单例通过互斥锁保证同一时刻只有一个写入者开启 WAL 模式让读写可以并行设置合理的 busy_timeout告诉 SQLite“如果别人锁着先等一下而不是立刻报错”。修完之后再也没见到 locked 异常。// 示意代码开启 WAL 模式与 busy_timeout let conn Connection::open_with_flags(path, OpenFlags::SQLITE_OPEN_READ_WRITE)?; conn.pragma_update(None, journal_mode, WAL)?; conn.pragma_update(None, busy_timeout, 5000)?;这个坑提醒我在 Linux 上跑通不等于跨平台跑通。桌面应用的人均使用场景一定包含 Windows所以在设计存储层时就要把并发模型想清楚。尽量不在业务代码里多个地方创建数据库连接统一走一个访问入口是最省心的做法。5.4 全文检索LIKE 的瓶颈和 FTS5 的中文问题数据量到了三万条左右LIKE 查询开始有感觉了尤其查询词碰巧是短字符全表扫描的耗时会上到几百毫秒。于是我把存储层迁到了 SQLite 的 FTS5 全文索引。这个迁移本身很顺但中文分词给了我足够的教训。FTS5 默认的 unicode61 分词器按空格和标点分词对中文句子几乎会切成整句 or 单字两种结果都不可用。比如“资源效率助手”这个查询在默认分词器下可能被拆成“资源效率助手”整串搜不到“效率助手”。我最终用了 trigram 分词器它按三个连续字符滑动切分对中文来说虽然会占用更多索引空间但至少短词也能搜到并且搜“效率助手”能命中“资源效率助手”里的片段。索引体积翻了三倍但换来的是查询体验正常值得。5.5 打包体积的控制与启动速度优化第一次打包出来安装包体积 8MB这个数字让身边用 Electron 做工具的朋友很惊讶。但 rea 的目标还不只是体积小启动速度也必须快。桌面效率工具的生死线是“按快捷键到出现窗口”超过一秒基本就废了。我把启动时间压进 500ms 内方法有两条窗口先显示骨架再异步加载数据避免启动时同步做 SQL 查询数据库连接惰性初始化用户没按快捷键时后端进程不被存储模块拖住。体积和速度其实是同一个哲学不必要的依赖都是慢性毒药。每加一个库都要问问自己它带来了多少价值又让安装包和启动时间付出了多少代价。5.6 一个容易被忽视的问题重复记录和脏数据随着使用时间变长重复记录开始出现。比如同一个网页片段被复制了三次或一份终端日志被推送了两次。rea 在存储层加了相似度检测对短文本做完全去重对长文本计算局部哈希若完全相同就直接跳过。这个机制避免了数据库里出现大量“同义反复”的片段也保证了搜索结果的质量。数据不是越多越好干净的数据才有检索价值。6. 后续路线rea 还能怎么长6.1 输入侧插件终端、浏览器、截图 OCR 一条龙最小版本跑通后最先想补的是输入侧。rea 把每个输入源都做成插件的形态插件只负责把外部内容变成统一事件推送进库。我目前接入了三个插件终端推送命令、浏览器扩展转发高亮文本、目录监视器。截图 OCR 排在下个版本识别出的文字直接入库这样连图片里的信息都能被搜到。插件接口设计得尽量薄一个插件就是一个脚本暴露produce()方法返回事件数组。这种设计让 rea 的扩展点清晰可见想接一个新来源甚至不用改主程序只要按接口写一个小脚本就行。6.2 输出侧插件不只是搜索结果输出侧的插件更有意思。除了搜索窗口rea 可以把符合条件的记录转发出去。比如凌晨把一天新增的碎片汇总成一个 Markdown 报告比如某条带提醒标签的记录到时间后在系统托盘弹通知。输出侧的核心是“按规则发货”把 rea 从被动查询变成主动服务。我实现了一个很轻的规则引擎订阅一个 SQL 查询再定义一个动作比如发送通知或写文件。这个设计让 rea 能胜任“每日回顾”和“定时提醒”两个场景而这一切依然全部在本地完成。6.3 给想复刻的人的三条建议如果有人想照着 rea 的思路做自己的工具我给三条建议。第一先做最小闭环再谈架构不要一开始就设计插件系统、同步方案一个剪贴板记录加一个搜索框就能跑完核心路径先把路径打通。第二把数据层和界面层彻底分开哪怕界面只是临时用的也要通过接口访问数据这样换壳子才不会是重写。第三尽早开启 SQLite 的 WAL 模式并统一写入口并发问题在开发时发现不了一旦常驻后台就会频繁咬人。rea 现在的状态离我理想中的“私人信息中枢”还有距离但核心价值已经出来了所有进去的东西都能出来出来的速度足够快。这种“确定性”是很多商业工具给不了的因为它不依赖网络、不依赖云端、不依赖服务商的良心。它只依赖一个本地文件和一行 SQL 查询。如果只让我留一个心得那就是个人效率工具最重要的不是功能多而是让人敢放心地把东西放进去。只要存储端绝对可靠、检索端绝对快速工具自然会被天天使用。rea 这个名字现在对我来说已经不只代表 Resource Efficiency Assistant更像一种提醒——真正属于自己的信息才谈得上高效。