为什么还有第二批
上一批挑了照片、书签、密码、监控这些「人人用得上」的项目。这一批偏「解决具体麻烦」：纸质文档、PDF、笔记、音乐、 RSS。它们的共同点是——用上了就回不去，但刚开始容易被资源占用和配置细节劝退。
数据都取自 2026 年 10 月 23 日的仓库页。
七个项目，一句话定位
| 项目 | Star | 许可证 | 解决什么 |
|---|---|---|---|
| Paperless-ngx | 47,010 | GPL-3.0 | 纸质文档扫描、OCR、全文检索 |
| Stirling PDF | 94,772 | — | 本地 PDF 工具箱，合并、拆分、转换、OCR |
| Memos | 64,007 | MIT | 轻量级碎片笔记，Markdown + 标签 |
| Navidrome | 24,306 | GPL-3.0 | 自建音乐流媒体，兼容 Subsonic 客户端 |
| FreshRSS | 16,396 | AGPL-3.0 | RSS 阅读器，多用户、规则过滤 |
| Miniflux | 9,816 | Apache-2.0 | 极简 RSS 阅读器，单二进制 |
| Linkding | 11,330 | MIT | 自建书签，带全文搜索与浏览器插件 |
Paperless-ngx：OCR 的 CPU 账
它把扫描件变成可搜索的 PDF，靠的是 Tesseract。麻烦在于 OCR 很吃 CPU：一页 A4 大约一秒到数秒，一次导入几百页能把小主机的负载拉满。
配置上有两个关键点：一是 PAPERLESS_OCR_LANGUAGE 要设成你实际需要的语言（默认只装英文）；二是扫描仪输出的 PDF 如果已经带文字层，关掉 OCR 能省一大截时间。
它依赖 Postgres 和 Redis，内存建议 2GB 起。文档原件、缩略图、搜索索引都在数据目录里，备份时别只备数据库。
Stirling PDF：功能多，内存也实在
九十多 k star 的项目，功能覆盖合并、拆分、旋转、水印、格式转换、OCR、签名。它是 Java 应用，空载也要几百 MB，处理大文件时 1GB 以上很常见。
它默认不开登录，直接暴露到公网等于把「任意 PDF 处理」送给所有人。要么放在内网，要么套一层认证——它自己支持简单登录，但更适合交给反向代理的认证层。
Memos：轻，但别指望它当知识库
单二进制、SQLite、Markdown，起来只要一条命令。适合记录碎片想法、待办、摘录。搜索是关键词匹配，不是语义检索；要构建结构化知识库，它不合适。
它的价值在于「记下来不费劲」。很多人搭了复杂的笔记系统，最后输给了打开就要三秒的工具。
Navidrome：曲库质量决定体验
它只负责串流和索引，不负责整理。标签（ID3）乱、专辑封面缺失、同名专辑混在一起，界面上就会很难看。上手前先用 MusicBrainz Picard 之类的工具把标签洗一遍，比调 Navidrome 的参数有用。
转码是 CPU 开销大头。局域网内建议关掉转码直接传原文件，出门在外再按需开。
FreshRSS 与 Miniflux：两种 RSS 哲学
FreshRSS 是 PHP 应用，功能全：多用户、规则过滤、全文抓取、插件。代价是要跑 PHP-FPM 和数据库，配置项多。
Miniflux 是 Go 单二进制，界面极简，只做「订阅、阅读、标记」。它强制要求 Postgres，没有插件体系，但维护成本极低。
如果你只自己用、想要「装完就忘」，选 Miniflux；如果要给几个人共用、需要复杂过滤，选 FreshRSS。
Linkding：书签的尽头是搜索
浏览器书签的问题从来不是「存不下」，是「找不回」。Linkding 的价值在于自动抓取标题与描述、支持标签与全文搜索，还有官方浏览器扩展。
它很轻，SQLite 就够。唯一要留意的是抓取网页元数据时会访问外网，内网环境下要配代理或关掉自动抓取。
我的判断
这一批项目的共同陷阱是「为了用而用」：装一个 PDF 工具，结果一年没打开过；搭一个 RSS 阅读器，订阅了 200 个源，最后只看三个。
选之前先问自己：这件事我现在用什么解决？如果答案是「一个我每天打开的东西」，那值得自建；如果答案是「一个我三个月没打开的东西」，装完也还是不会打开。
暂无评论内容