从裸机到浏览器——开源阅读器的技术栈全景

前两篇文章聊了 FreeInk 的全栈设计和开源阅读器的硬件/软件路线之争。今天换个角度，从技术栈切入，看看这些项目的开发者们分别选择了什么工具来造轮子。

作为一个写了十几年代码的人，我有个习惯：看到一个开源项目，第一反应不是「这玩意儿能干啥」，而是「它怎么写的」。技术栈的选择往往暴露了一个项目的核心哲学——你选什么语言、什么框架、什么构建工具，背后都藏着你在乎什么、不在乎什么。

这篇就带你在开源阅读器的技术栈里走一圈。

FreeInk：C++17 的嵌入式浪漫

选 C++17 + PlatformIO + ESP-IDF + Arduino 框架，这个组合说明了一件事：FreeInk 团队不在乎开发效率，在乎的是能不能把硬件榨干。

ESP32-C3 是一个 RISC-V 单核芯片，主频 160MHz，400KB SRAM，外挂 2MB PSRAM。在这种资源限制下，你要一个 EPUB 排版引擎流畅跑起来，C++ 几乎是唯一现实的选择。Garbage Collection 的语言不行（GC pause 不可控），解释型语言也不行（性能不够），Python 更不用说（MicroPython 的生态不够）。C 当然也可以，但 C++17 的 constexpr、模板元编程、RAII 能让嵌入式代码写得更安全、更优雅。

FreeInk 的代码风格也很有味道。它不是 Arduino 库那种「一个 .ino 文件塞满全局变量」的写法，而是正经的 C++ 工程组织：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

namespace freeink {
namespace book {

class ChapterLayout {
public:
  static BookStatus layout(
    BookSource& source,
    const ZipArchive& zip,
    const ZipEntry& entry,
    const std::string& href,
    const LayoutParams& params,
    Arena& scratch,
    PageCacheWriter& writer,
    ProgressCallback* progress,
    uint32_t* outTotalChars
  );
};

有命名空间、有 RAII、有显式的内存管理（Arena 分配器）。这在嵌入式 C++ 世界里算是「讲究」的那一档。

代价？ 开发速度慢。一个排版 bug 改完要重新编译、烧录、跑测试，循环好几分钟。没有热更新，没有 Chrome DevTools。你对着一个串口输出 printf 调试。这不是所有人能接受的节奏。

KOReader：Lua 的十年坚守

KOReader 的选择很有意思：内核层用 C，逻辑层用 Lua。

Lua 是一个被很多人低估的语言。它极其轻量（完整运行时 200KB 不到），嵌入友好，而且有一个杀手级特性：热更新。KOReader 可以在运行中加载新的 Lua 脚本，这意味着你可以改一个翻页动画然后立即看到效果——在电子墨水屏设备上，这简直是天赐的开发体验。不用重编译、不用刷机、不用漫长的等待。

Lua 的另一面是，它太灵活了。没有强类型系统，没有模块化的工程约束，一个大项目写久了容易变成一盘意大利面。KOReader 能撑十年不乱，说明核心维护者的架构能力很强。

有意思的细节： KOReader 的 C 层封装了 MuPDF（PDF/DJVU 渲染引擎）、CRe（Cool Reader Engine，EPUB/FB2 引擎）和 KOPT（页面优化库）。这些底层引擎负责最吃性能的渲染，Lua 层则负责 UI、交互逻辑和配置管理。各司其职，分工清晰。

这个技术栈也解释了为什么 KOReader 的生态如此丰富——你不需要会 C 就能写 KOReader 的插件，Lua 脚本的编写门槛低太多了。

Readest：Flutter 的跨平台豪赌

Readest 是 2025-2026 年增长最快的开源阅读器，22k+ star。技术栈选择了 Flutter + Dart。

选择 Flutter 的逻辑很清楚：你需要一个 iOS、Android、Windows、macOS、Linux 五端一致的体验，而 Flutter 是目前综合来看做这件事最好的框架。它有自己的渲染引擎（Skia/Impeller），不依赖平台原生控件，所以 UI 一致性极好。Dart 的 AOT 编译性能也够用，启动速度和交互响应都接近原生。

Flutter 的阅读器体验确实好。翻页动画丝滑、字体渲染漂亮、双指缩放流畅。这些在 Flutter 里是天然优势，因为它的渲染管线允许你精确控制每一帧。

代价？ Flutter 的包体积偏大（一个空 App 就要 20MB），Dart 的生态相比 TypeScript 还是小一圈。而且 Flutter 的桌面端支持虽然这两年进步很大，但和 Electron/Tauri 方案比，一些系统级集成还是麻烦（比如系统托盘、全局快捷键）。

unobox：纯前端的「以退为进」

自家的孩子，我知道技术栈选择的争议性。

React 19 + TypeScript + Vite + Epub.js。一个纯粹的 Web 技术栈。

如果你拿 FreeInk 的标准来看——没有本地存储、没有离线缓存、依赖浏览器——这简直不是一个阅读器。但如果你换个角度想：为什么阅读器一定需要安装？

unobox 的回答是：读书这个动作的核心价值在内容本身，而不是在「打开一个 App」这件事上。你打开浏览器就拿到了一整个阅读器，读完关掉标签页就走。没有安装、没有登录、没有数据同步、没有任何附加条件。

这个选择能成立，靠的是三个技术条件：

1. Vite + React 19 的构建效率——开发体验极好，HMR 毫秒级热更新
2. Epub.js 成熟的 EPUB 渲染能力——纯 JavaScript 的排版引擎，虽然性能不如 C++，但对 EPUB 格式的支持足够好
3. 浏览器能力的成熟——File API、IndexedDB、Web Worker、Service Worker，这些十年前还是纸上谈兵的东西，现在已经足够支撑一个完整的阅读器

代价很明显： 做不到离线体验，做不到极致的性能优化。浏览器沙箱限制了很多底层操作（比如自定义字体渲染引擎、不同刷新率的屏幕适配）。这是一个「做减法」的技术栈——放弃了一部分能力，换来了零门槛的访问体验。

其他有意思的选手

Foliate：GNOME 的纯粹

Foliate 是一个 GTK4 + JavaScript（GJS）的桌面阅读器。它是我见过最漂亮的 Linux 原生阅读器。GTK 的渲染质量在桌面端是一流的，尤其字体排版。它的翻页动画用的是 GTK 的 OpenGL 支持，效果不输给 Flutter。

Koodo Reader：Electron 时代的遗产

Koodo Reader 用 Electron + React，27k star。Electron 在 2026 年已经被很多人吐槽太重了（一个阅读器打包 200MB），但 Koodo 的功能确实丰富——阅读统计、云同步、多标签、书摘导出。它代表了「功能优先，重量不是问题」的思路。

Alexandria：Tauri 新势力

Alexandria 是 Tauri + React + Epub.js 的组合。和 Koodo Reader 功能相似，但体积小 10 倍（Tauri 的后端是 Rust 写的系统 WebView，不捆绑 Chromium）。如果你喜欢 Koodo 的体验但受不了它的体积，Alexandria 是个好选择。

Lector：Qt 的怀旧

Lector 用 Qt + Python。纯粹、简单、直接。打开即用，没有花哨的动画，排版质量稳定。适合那些想要一个「像旧时代软件一样好用」的阅读器的用户。

一张技术栈对照表

如果上面的内容记不住，下面这张表可以帮你快速对照：

选技术栈就是选价值观

写这篇文章的时候，我一直在想一个问题：这些技术栈的选择，真的是技术原因决定的吗？

回头看了一遍，我觉得不是。

FreeInk 选 C++，不是因为 Lua 或 JavaScript 做不了嵌入式——Espruino 就是 JavaScript 跑在 ESP32 上的。但 FreeInk 要的是对硬件完全控制，要的是能写出极致的性能。这背后是一种控制欲——对代码控制到比特级的欲望。

Readest 选 Flutter，不是因为 React Native 做不了跨平台——实际上 Readest 放弃了一致性之外的几乎所有东西。这背后是一种统一欲——五端一致，不分彼此。

unobox 选择纯前端，不是因为 Electron/Tauri 做不出好体验——只是不想让用户多花那三秒钟去安装什么东西。这背后是一种减法的意志——主动放弃能力来换更纯粹的价值。

技术栈从来不只是技术栈。它是一群人关于「什么东西最重要」的共识。

下一篇文章是这个系列的最后一篇，聊聊阅读器的未来——离线 AI、交互式内容和开源生态还能走多远。

📚 上一篇：硬件开源 vs 软件开源 → | 下一篇：阅读器的下一站 →