仅2MB的开源阅读器：10年前的旧笔记本翻页也不卡|reader|安装包|开源阅读器|电脑|笔记本

一、216MB 和 2.07MB 摆在一张表里，差了 104 倍

先看一组能自己核的数字。

Calibre 9.15.0 的 Windows 64 位安装包，文件名是 calibre-64bit-9.15.0.msi，216.1 MB。Thorium Reader 3.5.1 的 Windows x64 安装包，117.8 MB。Readest 0.12.10 的 x64 安装包，58.0 MB。这三个数字都来自各自项目 GitHub Releases 页面的资产清单，谁都能打开核对。

再看另一头。一个叫 Reader 的开源阅读器，最新 x64 版本的 7z 压缩包 0.77 MB，解压之后把里面所有文件加在一起，2.07 MB。

这不是作者宣称的数字，是实际下载解压后量出来的。

软件

Windows 安装包体积

体积口径

相当于 Reader 的

Reader v2.0.0.4 x64

0.77 MB（压缩包）/ 2.07 MB（解压后实测）

官方 7z 资产

1 倍

Readest 0.12.10

58.0 MB

x64-setup.exe

约 28 倍

Thorium Reader 3.5.1

117.8 MB

x64.exe

约 57 倍

Calibre 9.15.0

216.1 MB

calibre-64bit-9.15.0.msi

约 104 倍

先说句公道话：这张表在功能上并不对等。Calibre 是书库管理、格式转换、推送、插件生态一应俱全的全家桶，拿它跟一个纯阅读器比体积，多少有点不讲武德。可问题也正是在这里——绝大多数人打开 Calibre，干的事情就是双击一本 epub，然后翻页。

为了翻页，装了 216 MB。这个 104 倍的落差，值得追问一句：多出来的 214 MB，到底买了什么。

二、2.07MB 是怎么做到的：纯 C、Win32、不装任何运行库

项目地址是 github.com/binbyu/Reader，2018 年 9 月建仓，如今 5104 个 star、655 个 fork。仓库语言栏只写一个字：C。项目描述更省，一句话：A win32 txt file reader。

它小，不是靠删功能删出来的，是靠换掉依赖换出来的。

它的传播数据也很能说明问题：x64 那个包在 Releases 页面被下载了 16.3 万次，win32 包 5.6 万次，随包附带的书源配置文件 3.2 万次。一个没有官网、没有推广、README 只有几段更新日志的软件，靠的全是口口相传。

作者在自己的更新日志里留下了完整线索。v1.9.2.0 那一版为了支持 https 书源引入 openssl，日志原话是「增加ssl后，软件大小膨胀到了2.7MB」。到了 v1.10.0.0，作者做了两处替换：用 miniz 换掉 zlib，用 wolfssl 换掉 openssl，同一个版本带网络功能的 exe 压回到 1.63 MB。也就是说，两个底层库的选择，就值 1 MB。

现在的 v2.0.0.4 提供三个包，实测解压后体积如下：

版本

压缩包

解压后实测

x64

0.77 MB

2.07 MB

不支持 Windows XP 及以下

win32

0.62 MB

1.62 MB

老机器选这个，XP 可跑

无网络版

0.46 MB

1.20 MB

砍掉联网书源，最小

用法没有第四步：下载、解压、双击 Reader.exe、把 txt 拖进窗口。不写注册表，不往系统目录塞 DLL，不在后台常驻服务。整个软件可以放在 U 盘里，插到任何一台 Windows 电脑上就能读。

量体积这条命令可以自己跑一遍，Windows 自带的 tar 就能解开 7z：

mkdir reader && cd readercurl -L -O https://github.com/binbyu/Reader/releases/download/v2.0.0.4/Reader_v2.0.0.4_x64.7zbsdtar -xf Reader_v2.0.0.4_x64.7z && rm Reader_v2.0.0.4_x64.7zfind . -type f -exec ls -l {} \; | awk '{s+=$5} END {printf "%.2f MB\n", s/1024/1024}'

输出是 2.07 MB，Windows 上把 bsdtar 换成系统自带的 tar 即可。你想核别的阅读器，去它的 Releases 页面看资产大小，口径一样。

几个常用的按键也值得一提，它们基本决定了这个软件的体验上限：F12 切无边框，Ctrl+T 窗口置顶，Alt+H 一键隐藏，空格自动翻页，Ctrl+方向键跳章节，Ctrl+G 按百分比跳进度，Ctrl+滚轮调窗口透明度，Alt+滚轮调文字透明度。

三、小到 2MB，代价写在 issue 区里

体积小不是免费午餐，它是一连串取舍的账单。

第一个代价是版本。最新的正式版 v2.0.0.4 发布于 2023 年 8 月 20 日，到今天已经三年没有发新包。有意思的是仓库并没有死——master 分支在 2026 年 9 月 11 日还合并了几个外部 PR，有人贡献了 Web 阅读功能、有人修了新版 Visual Studio 上的编译问题。代码在动，但没人打包发布。对使用者来说，这意味着你拿到的是三年前的二进制，新功能要自己编译。

第二个代价是格式。这个软件的主场是 txt，epub 一直是短板。编号 127 的 issue 标题就叫「2.0对epub书籍的支持问题」，反馈目录显示不正确，从 2022 年挂到现在。如果你手上是 epub 为主，用它大概率会失望。

第三个代价是中文排版。编号 111 的 issue 是仓库里讨论最多的，27 条评论，说的是微软雅黑下 emoji 显示成乱码。一个只做中文小说阅读的软件，卡在字体和字符渲染上，多少有些尴尬。

第四个代价是在线书源。仓库里点赞高的 issue，标题是「分享书源」和「发点目前能用的书源」——能用的书源要靠评论区接力，这件事本身就是答案。第三方站点改版，书源就失效，这不是软件能解决的问题。

还有两个边界要说明白：它只有 Windows 版，macOS 和 Linux 用户可以直接关掉这篇文章。另外，在线书源本质是抓取第三方站点内容，版权风险要读者自己判断，本地 txt 和 epub 才是它正当的用法。

这里还有个更微妙的问题：5104 个 star 和 228 个未关闭 issue 同时存在。人气很高，欠账也很多，而且修 bug 的人多半不是作者本人。开源项目的生命力常常不是靠作者撑着，是靠几个愿意提 PR 的陌生人接着往前推——Reader 现在就处在这个状态。也因此，它不适合放进任何依赖稳定性的工作流。

所以真正该问的不是「它为什么这么小」，而是「我把哪些需求让渡掉了」。让渡掉云同步、批注、书库管理、跨平台、DRM 之后，剩下的就是翻页。而翻页这件事，2 MB 真的够了。

四、什么时候你真的需要这么小的阅读器

四类场景，它目前没有对手。

第一类是老机器。家里那台十年前的笔记本，机械硬盘、2 GB 内存、还在跑 Windows 7 甚至 XP，装主流阅读器光启动就要等半天。选 win32 那个 1.62 MB 的包，解压即跑，翻页跟手。这不是情怀，是唯一选择。

第二类是纯粹的本地阅读。你的书就是一堆 txt 和 epub，不需要跨设备同步，不需要做批注导出，只想打开就看、看完就关。这类需求被主流软件过度服务了很多年。

第三类是需要随身带走的绿色软件。1.2 MB 的无网络版塞进 U 盘，去网吧、去图书馆的电子阅览室、去单位的公用电脑，插上就能接着上次的进度读，不留痕迹。

第四类其实最有价值：想学 Win32 和 C 的人。一个 5104 star、有完整 GUI、有翻页排版算法、有网络模块的真实项目源码，比任何教程都实在。README 里那句「为了支持新增功能，重新编写了翻页算法」，背后是一整套文字排版逻辑。

反过来，如果你要跨平台、要手机电脑同步进度、要读带 DRM 的正版书、要管理上千本的书库，那就别用它，直接装 Calibre，那 216 MB 花得不冤。

五、2MB 的边界，也是软件膨胀的一面镜子

Reader 的意义不在它多好用，而在于它提供了一个基准线：一个能读 txt 和 epub、能翻页、能记住进度、能自定字号配色的完整 GUI 程序，下限是 2.07 MB。

有了这个数字，再看到任何一个动辄几百 MB 的阅读工具，就可以多问一句：多出来的体积，换来了哪些我真正用得上的东西。问得多了，软件的默认体积就不会一路涨下去。

手边那台吃灰的老笔记本，其实离能看书只差一个 1.62 MB 的解压包。