eSearch：把”截屏、离线 OCR、翻译、录屏”塞进一个托盘工具

截屏工具的天花板曾经很高——Snipaste 的贴图、Flameshot 的标注、系统自带截图的取色器，各有各的绝活，但没有一个同时把”截屏后立刻识别文字、翻译、搜图、录屏”做全。eSearch（GitHub 仓库 xushengfeng/eSearch，GPL-3.0）就是奔着”一个托盘图标解决所有屏幕操作”去的：作者受锤子手机”大爆炸”与小米”传送门”启发，想在桌面端实现”框选即搜索”。默认快捷键 Alt+C 唤起，支持 Windows、Linux、macOS。

一、背景：作者自己的两个未被满足的需求

README 里作者写得很直白：一是 2019 年他从 Windows 换到 Linux，Snipaste 当时不支持 Linux，Flameshot 又没有直观取色器；二是他怀念手机上那种”框住一段文字立刻搜/翻译”的即时信息操作，桌面端找不到替代品。于是他先用 Python+PyQt 写了个 Information-portal，又因为不熟悉 PyQt 转战 Electron，重写成了今天的 eSearch。这个出身决定了它的基因：以截屏为入口，向后挂接一长串”对这块屏幕内容做什么”的动作。

二、功能全景：一张”屏幕操作”清单

官方列出的功能矩阵相当长，核心可分为四类：

三、技术机制：为什么安装包这么大

作者在 FAQ 里专门解释了体积问题，这个解释本身很有信息量——除了 Electron 运行时，安装包里还塞了：

• ONNX 运行库：用于跑本地 AI 模型；
• 离线 OCR 模型：PaddleOCR 导出的识别权重，多语言模型需在设置里额外下载；
• 录屏人像识别模型：用于虚拟背景；
• 物体移除模型：用于截图”抹除并修补”；
• FFmpeg：录屏格式转换（Linux 用系统库所以不附带）。

也就是说，eSearch 把”离线可用”放在第一位：OCR、虚拟背景、物体擦除都不依赖云端。代价是安装包体积远超普通截图工具。作者对此的取舍是明确的——“几十行 JS 脚本的增加不多，带来的功能却显著可感知”，他选择用体积换功能密度。

关于为什么选 Electron 而不是 Qt/Flutter，作者的回答同样坦率：Qt 依赖 C++ 学习成本高、Flutter 桌面版当时不成熟、自己更擅长 JS，且截屏必须依赖本地系统 API，浏览器做不到——最终在 JS 系跨平台方案里选了最成熟的 Electron。

四、客观分析：优势与局限

优势：

1. 功能密度在开源截屏工具里几乎无出其右：截图、取色、标注、OCR、翻译、贴图、录屏、滚动截屏一肩挑；
2. 离线 OCR 开箱即用，涉密屏幕内容不必上传云端；
3. 高度可定制：自定义框选后动作、自定义翻译引擎、自定义多模态大模型接口、CSS 滤镜贴图；
4. 安装渠道现代：winget install esearch、AUR e-search，跨三平台。

局限（口径偏差需注意）：

1. “离线 OCR 开箱即用”有水分：多语言（韩文、泰卢固文、阿拉伯字母等）与生僻字 v5 模型需要在设置里额外下载，不是装完就有；
2. 不再支持 Win7/Win8（Electron 官方放弃），老系统用户只能自行编译且部分功能不可用；
3. Electron 应用常驻内存与启动体积偏大；GNOME 桌面需另装 appindicator 插件才能用托盘；macOS 首次打开会提示”文件已损坏”需手动放行；
4. OCR 准确率高度依赖 PaddleOCR 模型本身，对复杂排版、手写体、低分辨率截图的识别效果官方并未给出评测数字，使用时仍需人工校对（官方也提供了选区同步到编辑区的校对流程）；
5. 仓库 open issues 约 70 个，功能多意味着维护面大，边缘 bug 的响应节奏需要自行观察。

五、适合谁

• 需要在 Linux 上体验类 Snipaste + 类”传送门”即时搜索的用户；
• 经常要截图识别屏幕外文、做屏幕翻译（看视频/玩游戏）的学习者；
• 对隐私敏感、不愿把截图传给云端 OCR 服务的人；
• 想在一个工具里同时完成”截图+录屏+贴图”的内容创作者。

如果你只需要最轻量的截图+标注，Flameshot/Snipaste 更省资源；eSearch 的价值要在你真的用到 OCR、翻译、录屏组合拳时才体现出来。

参考来源

• GitHub 仓库：xushengfeng/eSearch
• eSearch 官方下载站
• Koala 项目库条目：eSearch