浏览器收藏夹塞了几百个链接，真正回头翻的没几个；想找半年前存过的一篇教程，只记得大概内容，死活搜不出来。这种事我遇上太多次了。后来干脆把收藏这件事挪到自托管上——不依赖浏览器同步，也不把我的阅读清单交给某个 SaaS。试了一圈，最后留在 NAS 上常驻的是 Shiori。
它是什么？一个用 Go 写的轻量书签管理器，MIT 协议，GitHub 上 1.1 万多个 star，最近一次提交在 2026 年 7 月，还在活跃维护。作者本意是做一个 Pocket 的开源平替，但用下来你会发现它比”稍后读”更实用：既能当书签库，也能当网页存档器。
为什么不直接用浏览器收藏夹
链接是会死的。行业里有个流传很广的说法：互联网上超过六成的链接最终都会失效。你今天高高兴兴存了一篇配置教程，明年站点改版或者关停，收藏夹里就只剩一个打不开的灰链接。
Shiori 在保存书签时会顺手把网页正文抓下来做离线存档。原站挂了，你本地还有一份可读的快照，全文搜索也能直接命中内容——不只是搜标题和 URL，而是搜”那年我在配置什么服务时踩的坑”这种模糊记忆。
资源占用低到可以忽略
这是我把它留在 NAS 上的主要原因。它是单二进制程序，默认用内嵌的 SQLite，不需要单独起一个数据库服务。官方文档给出的典型内存占用大约 30 MB，有玩家把它跑在树莓派上毫无压力。我的 NAS 上还跑着一堆别的服务，多加一个 Shiori 基本感觉不到存在感。
如果你是多用户场景或者书签量很大，它也支持 PostgreSQL 和 MySQL 作为后端，通过环境变量切换，不用改配置文件。但个人用，SQLite 足够了。
怎么跑起来
最省事的就是 Docker。官方镜像在 GitHub 的容器仓库里，一条 compose 就能起来：
services:
shiori:
image: ghcr.io/go-shiori/shiori:v1.8.0
container_name: shiori
environment:
- SHIORI_DIR=/srv/shiori
- SHIORI_HTTP_SECRET_KEY=换成你自己的随机串
ports:
- "8080:8080"
volumes:
- shiori-data:/srv/shiori
restart: unless-stopped
volumes:
shiori-data:起来之后打开 http://你的设备IP:8080，默认账号是 shiori / gopher。这一步千万记得进去改密码——这个默认凭证是公开的，谁都知道。改完密码，点”+”就能加书签，标题和描述会自动抓取，可读的页面还会顺手存一份离线存档。
除了网页界面，它还有命令行和 REST API。批量导入浏览器导出的 HTML 书签文件很方便，也能写脚本把 RSS 或者某个自动化流程里的内容直接塞进去。Firefox 和 Chrome 也有对应的扩展，一键收藏当前页。
阅读模式和存档模式，差在哪
Shiori 的图书详情页有两种视图。阅读模式是把正文提取成干净排版给你看；存档模式则是把整页 HTML 原样存下来，连样式都在。两者区别看下面这张官方对比图就很直观：
我自己的习惯是：教程类、配置类存存档模式（保命），纯资讯类存阅读模式（省空间）。一千条带存档的书签，文档里给出的存储参考是 1 到 5 GB，不算小，但比起丢内容还是值得的。
几个实际会踩的坑
第一，默认密码必须改。前面说了，shiori/gopher 是公开的，公网暴露前不改密码等于裸奔。
第二，数据目录一定要挂卷。不挂持久化卷，容器一重启书签全没。Docker 里把宿主机目录挂到 /srv/shiori（或你设的 SHIORI_DIR）就行。
第三，存档不是万能的。页面抓取依赖目标站的结构，遇到重度 JS 渲染、需要登录才能看的内容，可能抓不到正文，只会存个链接。重要资料存完最好点开存档确认一下。
第四，扩展质量一般。官方说有浏览器扩展，但实际体验比较基础，稳定添加书签还是网页界面或 API 更靠谱。别对扩展期待太高。
适合谁
如果你和我一样，受够了浏览器收藏夹的混乱、又不想把阅读清单交给某个随时可能涨价的 SaaS，Shiori 是个性价比很高的选择。它不花哨，但该有的都有：全文搜索、离线存档、标签、多用户、API。跑在 NAS 或者一台小机器上，7×24 在线，手机电脑随时访问。
下次再聊怎么用它的 API 把每天看到的好内容自动归档——那才是真正把”收藏”变成”拥有”的一步。