收藏夹里最难处理的，往往不是链接太多，而是不知道当时为什么收藏。一个叫“参考”的文件夹里，服务器配置、采购页面和已经失效的教程放在一起。linkding 适合把这些链接搬到独立的书签库，用标题、描述、标签和搜索整理，电脑换了也能继续使用同一套收藏。
它主要管理书签，不应当被直接当作所有网页的永久镜像。原页面关闭、需要登录或改变内容之后，保存的 URL 仍可能打不开。需要留下关键信息时，把版本、条件和自己的短说明写进描述；原始资料是否另存，还要按自己的用途决定。
部署前先确认 VPS 的磁盘、内存和公网访问条件，也可以查看雨云云服务器；注册时填写优惠码 KuZhuJi。
先从一个账号、一份浏览器导出开始
不要首次启动就导入几万条历史链接。先从浏览器导出一小份书签，包含中文标题、重复链接和几个层级目录，用它验证导入规则。迁移完成后保留原始导出文件，等核对完再清理浏览器里的旧收藏。
官方界面示例可以看到标题、描述、标签和筛选入口。实际使用时，描述里写“Ubuntu 上配置反向代理，注意 WebSocket”会比统一写“很好用”更有助于以后找回内容。
选择工具前也想一下收藏的对象。技术链接适合给出系统、软件和主题标签；采购链接还要记录地区、规格和活动时间。链接中的内容可能变化，一段当时的购买条件比仅保存标题更有价值，但不要在普通书签里填写银行卡或密码。
用一个持久目录保存 SQLite 数据
示例使用项目维护的 sissbruecker/linkding:latest。它默认使用 SQLite，把数据保存到 /etc/linkding/data。已有 Docker Compose 的 Linux VPS 可以从以下目录开始：
mkdir -p ~/services/linkding/data
cd ~/services/linkding
保存 compose.yaml：
services:
linkding:
image: sissbruecker/linkding:latest
ports:
- "127.0.0.1:9090:9090"
volumes:
- ./data:/etc/linkding/data
restart: unless-stopped
默认镜像和其他变体的用途不同，初次部署不要为了减少几十兆下载量就换成自己不熟悉的实验标签。这里的 latest 方便首次安装；在正式使用前记录镜像版本或摘要，后续升级先做备份和验收。
docker compose config --quiet
docker compose up -d
docker compose logs --tail=80 linkding
官方镜像不提供一个可直接登录的默认用户。使用交互命令创建自己的账号：
docker compose exec linkding python manage.py createsuperuser --username=reader --email=reader@example.com
把用户名和邮箱改成实际值，按提示输入密码。交互输入可以避免把密码直接留在终端命令历史里。这个初始账号拥有管理权限，多人使用时再创建独立账号，不共享它。
先通过 SSH 登录，再配置正式域名
ssh -L 19090:127.0.0.1:9090 user@your-server
本机访问 http://127.0.0.1:19090，登录并保存一个测试链接。只绑定回环地址，适合先确认功能。打算通过域名访问时，反向代理转发到宿主机 9090，并保留正确的 Host 信息。
如果正式域名为 https://links.example.com，在服务里配置可信来源：
services:
linkding:
image: sissbruecker/linkding:latest
environment:
LD_CSRF_TRUSTED_ORIGINS: https://links.example.com
ports:
- "127.0.0.1:9090:9090"
volumes:
- ./data:/etc/linkding/data
restart: unless-stopped
它用于跨请求来源校验，不负责创建域名和证书。配置后重建容器，用正式域名登录、添加和编辑书签。若登录页面正常而提交提示 CSRF 错误，先对照外部 URL、可信来源和代理头，不要直接关闭相关检查。
浏览器导出用于搬进书签库，HTML 导出用于带走链接，完整数据副本用于恢复实例。三者的范围不同，迁移时分别保存，不能只保留一个导出文件就认为账号和设置也已经备份。
准备独立实例时，可在雨云选择适合的云服务器配置，优惠码 KuZhuJi。配置按实际任务选择，数据库和附件另做备份。
导入以后先找三类容易出错的记录
第一类是中文标题和目录层级。浏览器导出文件的格式、文件夹组织和 linkding 导入规则并不完全相同，导入后检查标签与原文件夹的对应情况。第二类是重复 URL，不同收藏时间可能有不同描述，不要为了去重先把有用说明清空。第三类是带参数的链接，参数可能表示文章位置，也可能含个人令牌，需要逐条判断。
首次导入只做小批次，对照导入前后的数量和几条代表记录。然后用常用关键词搜索，确认能找回；再编辑描述和标签，刷新页面检查修改是否保存。如果采用浏览器扩展或其他客户端，确认它连接的是自己的实例，并使用该实例生成的个人 API 凭据。
API 令牌有访问能力，不是普通分享链接。插件需要配置令牌时，避免把设置页截图公开。更换电脑、丢失设备或停止使用某个插件后，检查并撤销旧凭据，必要时重新生成。多人实例中每人使用自己的账号和令牌。
标签围绕检索场景，而不是目录数量
可以先保留项目名、软件名、用途几个维度。遇到一篇同时涉及 Caddy 和 Docker 的文章，多个标签比必须塞进唯一文件夹更方便。标签仍要统一名称，例如不要同时用“Postgres”“postgresql”和“PG”表示同一主题而没有明确区别。
描述适合保留判断依据：文章适用于哪个版本、自己需要哪一节、是否需要权限或付费账号。原页面的自动标题只是起点，含糊的标题可以改成更好理解的名字。归档暂时不用的链接，也比反复删除和重新收藏更容易保留上下文。
每次整理先解决真正影响查找的条目。不需要为了建立一套完整分类，给所有记录补十几个标签。几个固定搜索和明确描述就能承担很多用途；大量看似精细、实际不用的标签只会增加维护工作。
需要增加服务器时，可以打开雨云选购页面，填写优惠码 KuZhuJi；迁移前保留数据与原有部署配置。
私人书签库不能默认开放给所有人
查看自己的书签是否被标为共享，以及共享页在退出登录后的实际表现。私人链接也可能从描述、截图或第三方插件设置中漏出去。多人部署时测试一个普通用户能看到哪些记录，管理员权限只交给维护者。
服务器收到异常抓取或登录请求时，查看应用日志及代理日志。日志可能包含访问地址或其他个人信息，保存多久、谁能读都要确定。不要为了追踪一次报错把完整日志直接贴到公开论坛，先去掉令牌和私人链接。
HTML 导出方便迁移，完整目录负责恢复
定期导出书签 HTML，适合重新导入浏览器或其他工具。检查导出结果是否保留自己需要的标签和描述，而不是只看文件已经下载。实例级数据包含更多内容，需要另做完整副本。
mkdir -p backups
docker compose stop linkding
tar -czf "backups/linkding-$(date +%F-%H%M%S).tar.gz" data compose.yaml
docker compose start linkding
将备份转移到其他存储，限制访问。若后来切换成 PostgreSQL，挂载目录并不包含外部数据库，改用相应数据库导出，并保存附件或归档等实际使用的数据路径。
恢复时用独立目录和端口，先确认用户能登录，随后搜索刚才导入的一条中文书签，查看描述、标签和共享状态，最后再导出一份 HTML。这样可以同时验证实例可恢复和链接可迁移，而不是只确认容器还能启动。