Kavita 漫画电子书服务器：单文件 226.9MB，CBZ/PDF 在线看

本地攒了几百个漫画压缩包，想躺在沙发上用手机翻，这件事比看起来难做。NAS 上拷一份，手机得装个看图软件，翻到一半网速一卡，页序全乱；想看进度记在哪，换台设备就断了。

Kavita 就是解决这件事的：一个跑在自己机器上的漫画与电子书服务器，把 CBZ、CBR、PDF 这些散落的压缩包扫进书库，自动读封面、按卷分册、记住每个人看到哪一页，然后在浏览器里翻页看。它自带 .NET 运行时，Windows 侧就是一个约 117MB 的压缩包，解开双击 Kavita.exe 就能跑，不用装运行库、不用配数据库。实测冷启动（含首次数据迁移）18.3 秒，二次启动 5 到 6 秒；手机端 390 宽下整站能正常翻页。

我把 Windows 11 和 Linux（WSL2）两侧都跑了一遍：Win 侧建库扫描出 1 个系列、2 卷、10 页，Linux 侧 5.2 到 6.4 秒完成启动、首页 200、登录接口 200。下面把过程和数据都摆出来。先说结论：手上有成堆漫画压缩包、想一个人用或者一家人共用的人，它很合适；只有零星几个 EPUB、又想要商业书城的排版和词典的，它不是你该找的东西。

它是什么 / 和普通看图软件差在哪

Kavita 是一个自托管的阅读服务器，核心是三件事：

• 扫描：把落在某个目录里的漫画、电子书扫进书库，按文件夹层级拆成系列、卷、章节，页序从压缩包内部的文件名推断。
• 阅读：在浏览器里逐页翻，支持单页、双页、条漫式的纵向滚动，也支持单张宽页自动铺满。
• 记录：每个账号各自记阅读进度，换设备直接续上，还带阅读列表、收藏和评分。

它和你手机上的看漫画 App 最大的差别在「组织」这一层。看图软件只认文件，Kavita 认系列和卷，会把同一部漫画的不同卷归到一起，给一个统一的入口和封面。它和网盘也不一样：网盘只是存文件，翻页、进度、书签都得靠客户端自己想办法，而 Kavita 一并接管了。

它也不是万能的。界面上没有书城推荐，没有社交，没有版权内容，内容全靠你自己往里放；它默认只用 SQLite，一个用户小规模阅读没有问题，几百人同时在线读就不是它的设计目标。

我的测试环境

• Windows 11 家庭中文版，64 位，用的是包里的 Windows 版程序。
• Linux 侧是 WSL2 里的 Ubuntu，用的是包里的 Linux 版程序，与 Windows 侧同一版本号。
• 漫画测试集：一个 2 卷、每卷 5 页的 CBZ，共 10 页，专门用来验证「扫描能不能识别压缩包」和「列表能不能按卷展开」。
• 计时口径：从进程启动到首页返回 200 之间的时间，含冷启动，每次都新起进程。

安装：Windows

解压后进入程序目录，双击 Kavita.exe。第一次启动会先看到一串初始化日志，里面夹着几行长得像报错的迁移记录，日志自己标了「This is not an error」，别被吓到。等它稳定下来，浏览器访问本机端口：

本机地址  localhost:5000

第一屏就是注册管理员账号的页面，填完用户名和密码就能进去。之后每次启动都是 5 到 6 秒，不再有迁移。

想换端口或者让局域网里别的设备访问，改程序目录里 config 下的 appsettings.json，找到端口那一段改掉再重启即可。默认监听所有网卡，所以手机连同一个 Wi-Fi 直接敲电脑的局域网 IP 就能打开。

安装：Linux

Linux 版是同一套程序，解压后给主程序加执行权限再跑：

chmod +x Kavita/Kavita
./Kavita/Kavita

首次启动同样要等初始化日志刷完，之后 curl 探一下：

curl -sS -o /dev/null -w '%{http_code} %{time_total}s\n' http://127.0.0.1:5000/

我在 WSL2 里量到的是 5.2 到 6.4 秒返回 200，首页返回 30.7KB，耗时 21 毫秒。服务本身还会开一个健康检查接口，返回 Ok 就说明数据库与后台任务都起来了。

建库：四步

第一步，注册完管理员账号，进「服务器设置」里的库管理，新建一个库。这一步有个容易被忽略的地方：类型必须把「漫画、轻小说、书、图片」几类名称都选上，只选其中一种的话，扫描器不会把 CBZ 当成可识别格式，扫完就是空的。

第二步，填一个你想要的书库名字，再添加一个文件夹——指向你放漫画的目录。目录可以加多个，扫描器会分别去读。

第三步，保存后触发扫描。扫描进度会显示当前处理到哪个文件，页数与卷数是边扫边涨的，中途不要急着刷新。

第四步，回到首页就能看到书库卡片了。点进去是系列列表，每个系列显示封面、卷数和阅读进度。

建库也可以走接口，登录拿到令牌后往库接口里提交库名与文件夹列表，类型字段同样要带上几种。用脚本批量建库的人注意这一条，否则会出现「接口返回成功但一本也扫不到」。

实测数据

下面这些数字全部来自本轮实际运行：

• Windows 侧程序包：117.5MB，解压约 1.2 秒，产出约 1890 个文件。
• Windows 侧首次启动：含数据迁移，18.3 秒后首页 200。
• Windows 侧二次启动：5 到 6 秒。
• 首页大小：30.7KB；接口注册与登录都返回 200，拿到的是一枚 JWT。
• 建库扫描结果：1 个系列、2 卷、10 页——测试集就是一卷 5 页的两卷 CBZ。
• Linux 侧程序包：117.7MB，解压约 1.5 秒，条目数比 Windows 侧少一个（只有对应平台的二进制）。
• Linux 侧启动：5.2 到 6.4 秒后首页 200，21 毫秒响应。
• Linux 侧接口：登录 200，扫描出 1 个系列、10 页，健康检查 Ok。
• 截图：桌面 1400 宽整页 4 张、手机 390 宽 2 倍图 2 张，浏览过程 0 个 4xx/5xx、0 个脚本报错。

要说明的是，这些耗时都是空库启动，程序主要花在读配置和校验数据库上；书库有几万页的时候，首次扫描时间取决于你的磁盘和 CPU，这两个数字不能直接类比。

界面长什么样

首页顶部是搜索和账号入口，下面是书库卡片，和我自己画的一样朴素，没有广告位也没有推荐流。

进书库之后是系列列表，封面上叠着已读进度。这一屏决定了我用不用它——封面自动从压缩包里抓，不用自己传图。

系列详情页把 2 卷分开列出来，右上是「继续阅读」和阅读设置，翻页模式在这里切。

手机端首页把书库卡片收成一列，导航折成汉堡菜单。

手机上进到系列页，卷列表和阅读按钮都在拇指够得到的位置。

另外第一张是登录页：

一个真实的坑

第一次建库，我照着别的阅读器的心智选了「漫画」这一个类型，把 CBZ 目录加进去，扫完提示完成，结果书库是空的，一本都没有。

翻日志才明白原因不在压缩包，而在类型。它把每个库的类型看成「这个库里允许出现什么格式」，只勾漫画时，压缩包虽然被遍历到了，却不满足任何被允许的解析规则，于是被静默跳过。把四种类型都选上之后，同一个目录立刻扫出 2 卷 10 页。

这件事给我两条经验。其一，扫完是空的先看库的类型，再看文件夹权限，最后才怀疑文件名。其二，它不会为被跳过的文件报错，只会安静地当作不存在，所以扫描之后一定要核对系列数与卷数，别只看到「扫描完成」就收工。

上线：让它在局域网长期跑

家用最省事的做法是把它挂在 NAS 或一台常开的小主机上，用系统服务托管，顺带配上反向代理和证书，手机上就不必再输端口号。

Windows 侧用任务计划程序即可，触发器选开机，程序填 Kavita.exe 的完整路径，工作目录设成程序所在目录——它把数据目录放在程序旁边，工作目录不对会另起一套空库。

Linux 侧写一个 systemd 单元最稳，注意两点：工作目录指向程序目录，用户要对该目录有读写权，因为它要在旁边建数据与配置目录。

挂反代的时候记得打开 websocket 转发，阅读页的进度同步走的是长连接，只配普通反向代理会表现为「能翻页但进度不保存」。

这几类人适合，这几类不适合

适合：

• 手上有一大堆 CBZ、CBR 压缩包，想把它们统一管起来的人。
• 家里几台设备都想看、希望进度各记各的人。
• 有自己的一台小主机或 NAS，愿意折腾一次后就长期用的人。
• 只想要阅读、不想要书城与社交的人。

不适合：

• 只有一个阅读软件、偶尔看两本的人，为这个单独开一台服务不划算。
• 需要在线书城、词典查词、生词本这类功能的人，它不提供。
• 想几百人同时在线读的小站长，SQLite 加单进程不适合这个量级。

常见问题

源码获取

解压后按上面的步骤就能跑起来，建议先转存到自己网盘，防止分享链接失效后找不回文件。