在语言学习工具里自托管类产品一直有稳定的需求。Lector 是一个 FOSS、self-hosted 的 language reader简单说它把服务器的部署权和数据控制权交还给使用者同时提供 cloud option让不想维护服务器的人也能直接使用这个阅读工具。项目以 Show HN 的形式出现在开发者社区意味着作者愿意把源码开放出来接受使用者的审查和反馈。下面先从 language reader、FOSS、self-hosted 和 cloud option 这几个关键词拆开讲然后用 Docker Compose 完整走一遍自托管部署、数据持久化、阅读验证、故障排查和生产化加固的流程。如果你有语言学习需求又希望自己掌控阅读数据这篇文章可以帮助你从零搭建一套可用的环境也能帮你在自托管和云托管之间做出更合理的判断。适合的读者包括熟悉基本 Linux 命令、了解 Docker 概念、有独立服务器或 NAS、正在寻找自托管学习工具的开发者。即使你还没有服务器也可以先理解文章中的部署结构和排查思路后续再决定采用哪种路线。1. Lector 是什么先把几个关键词拆开看1.1 language reader 到底解决什么问题阅读是语言学习里最稳定的输入途径。直接面对外文材料时学习者经常遇到三个问题查词动作打断阅读节奏查过的生词散落在不同位置下次遇到还是不认识同一篇文章在不同设备上无法续读阅读进度和组织全靠手动。language reader 这类工具把材料管理、阅读展示、词汇查询、生词收集、复习回顾放进同一个界面。阅读时点击某个词释义直接出现在当前页面上不需要切换到词典应用被查询过的词可以加入生词本文章列表、阅读位置和生词数据由服务端保存换设备也能继续。放到语言阅读器这个场景里核心价值就是让输入过程保持连续同时让查询和积累成为阅读的自然副产品。对于德语、法语、日语、英语这类词形变化丰富的语言边读边查边积累的体验会比把阅读和查词完全分离好很多。1.2 FOSS 不是“免费”那么简单FOSS 是 Free and Open Source Software 的缩写。这里的 free 指的是自由不是免费。自由软件强调四件事无论什么目的都可以运行程序可以研究程序如何工作并修改它可以重新分发副本帮助他人可以发布修改后的版本让整个社区受益。对普通自托管用户来说FOSS 带来两个直接好处第一不存在授权锁定服务端和客户端都不需要担心试用期结束或商业授权变化第二源码开放意味着部署、审计和二次修改都可行如果项目某个默认配置不适合自己的使用习惯可以自己调整。同时也需要保持理性预期。开源不代表没有维护成本社区项目的活跃度、文档完整度和版本兼容性都需要实际评估。决定长期依赖一个自托管项目前建议先看它的仓库活跃度、issue 处理情况和最近 release 频率。1.3 self-hosted 与 cloud option 不是互相替代的关系self-hosted 的意思是服务运行在自己控制的服务器、NAS 或个人电脑上数据库和文件都保存在自己的存储里。cloud option 则是由项目运营方提供托管服务用户注册后直接使用不需要处理安装部署和服务器维护。两者不是非此即彼。很多开源项目会同时提供两条路线习惯自己维护、在意数据控制权的用户选择 self-hosted希望开箱即用、不想承担运维成本的用户选择 cloud。选择主要取决于几个变量你对数据隐私的敏感程度、是否愿意承担升级和备份工作、以及你的服务器运维能力。对 Lector 这类 language reader 来说数据本身就是长期积累的包括阅读材料、生词本、学习进度和标注。选 self-hosted 意味着这些数据由自己保管风险是服务器故障或备份缺失导致丢失选 cloud 意味着数据托管在别人的基础设施上风险是服务变更、停止运营或隐私边界变化。这个权衡没有标准答案放到具体使用场景里讨论更合理。维度self-hostedcloud option部署门槛需要服务器、Docker、域名等基础知识注册账号即可数据位置自己服务器或设备项目方基础设施维护成本自己负责升级、备份、排错由运营方负责月度成本主要是服务器费用按订阅或套餐计费定制能力可以改源码和配置通常只能使用公开功能隐私边界数据完全在自己控制内需要信任服务方这张表是一般规律具体到 Lector以项目部署文档和服务条款为准。2. 自托管部署前的环境准备2.1 运行环境与前置依赖自托管 Lector 这类 Web 应用常见的最低环境是一台 Linux 服务器CPU 2 核、内存 2GB 以上磁盘根据阅读材料库大小预留。系统推荐 Debian 或 Ubuntu也可以使用 NAS 设备上的 Docker 环境。Windows 和 macOS 本机能用 Docker Desktop 跑通但长期使用仍然建议放在 Linux 或 NAS 上。软件层面建议先确认已经安装 Docker Engine 20.10 以上版本以及 Docker Compose v2 插件。Docker 不是唯一选择也可以手动安装语言运行时、数据库和反向代理但容器化部署更容易让配置可复现、环境可隔离、升级可回滚。需要强调一点Lector 实际要求什么依赖要查看项目 README 或部署文档。下面的部署示例用于说明自托管 Web 应用的一般结构和参数落地时把镜像、端口和环境变量替换成项目实际值。项目学习环境生产环境建议操作系统Linux/Windows/macOS 本机Linux 服务器或 NASCPU1 核以上2 核以上内存1-2GB2-4GBDocker20.10 以上20.10 以上域名可选建议有备份手动导出定时任务HTTPS可选必须2.2 为什么用 Docker Compose 作为主要编排方式单个容器适合一个进程的场景但语言阅读器通常不止一个服务。除了应用本体还需要数据库保存账号、生词和进度生产环境还可能有反向代理。Docker Compose 在一个 YAML 文件里描述多个服务、网络、数据卷和依赖关系一条命令完成创建和启动。Compose 带来几个实际好处环境变量集中在一个.env文件中管理不会把密码写死在命令历史里数据卷由配置声明删除容器再重建数据仍然存在升级时只改镜像标签重新up -d完成依赖关系比如应用依赖数据库先启动可以通过depends_on声明日志统一走docker compose logs查看。2.3 部署前需要确认的五个检查点第一端口是否被占用。如果打算用宿主机的 8080 端口先执行ss -lntp | grep :8080没有输出说明端口空闲有输出则需要换端口或停掉占用进程。第二磁盘空间。镜像会占用几百 MB数据库和材料库会持续增长。用df -h /opt确认根分区或目标目录有足够空间。第三防火墙和安全组。云服务器通常有两层系统防火墙和云厂商安全组。即使容器启动成功端口没有放行外部仍然无法访问。需要同时检查这两处。第四时区。时区不对会导致学习记录的时间戳偏差建议在环境变量中统一设置TZAsia/Shanghai。第五备份策略。自托管最怕的不是部署失败而是数据丢失。部署前就应该想好数据卷和数据库导出任务放在哪里这部分内容在第 4 节展开。3. 用 Docker Compose 部署最小可用实例3.1 创建项目目录与 .env 文件假设项目部署在/opt/lectorsudo mkdir -p /opt/lector cd /opt/lector sudo touch docker-compose.yml sudo touch .env.env文件用于保存环境变量内容类似APP_PORT8080 POSTGRES_DBlector POSTGRES_USERlector POSTGRES_PASSWORDchange-me SECRET_KEYchange-me TZAsia/Shanghai其中SECRET_KEY用于应用对会话或 token 签名生产环境必须改成随机值。生成随机值可以使用openssl rand -base64 48注意.env文件包含敏感信息不要提交到 Git 仓库。如果项目目录使用 Git需要在.gitignore中加入.env。3.2 docker-compose.yml 逐段解读下面是一个通用的 Compose 编排示例目的是展示语言阅读器自托管时的服务结构和参数关系。实际部署时image要换成 Lector 正式发布的镜像地址如果项目只提供源码则需要先根据官方构建流程构建镜像。services: lector: image: your-registry/lector:latest container_name: lector restart: unless-stopped ports: - ${APP_PORT}:8080 environment: APP_PORT: 8080 DB_HOST: db DB_PORT: 5432 DB_USER: ${POSTGRES_USER} DB_PASSWORD: ${POSTGRES_PASSWORD} DB_NAME: ${POSTGRES_DB} SECRET_KEY: ${SECRET_KEY} TZ: ${TZ} volumes: - lector_data:/app/data depends_on: db: condition: service_healthy db: image: postgres:16-alpine container_name: lector-db restart: unless-stopped environment: POSTGRES_DB: ${POSTGRES_DB} POSTGRES_USER: ${POSTGRES_USER} POSTGRES_PASSWORD: ${POSTGRES_PASSWORD} TZ: ${TZ} volumes: - pg_data:/var/lib/postgresql/data healthcheck: test: [CMD-SHELL, pg_isready -U ${POSTGRES_USER} -d ${POSTGRES_DB}] interval: 10s timeout: 5s retries: 5 volumes: lector_data: pg_data:关键点如下。lector服务通过${APP_PORT}读取.env中的端口把宿主机的 8080 映射到容器内部端口。容器内部端口是否必须是 8080取决于项目镜像暴露的端口需要看项目的 Dockerfile 或镜像说明。DB_HOST: db表示应用通过 Compose 内部 DNS 访问数据库服务Compose 会为所有服务创建一个默认网络服务名就是主机名。不要把这里的db改成localhost因为应用在容器里localhost指向容器自身而不是数据库容器。restart: unless-stopped让服务在服务器重启或容器异常退出后自动拉起这是自托管常用策略。depends_on加condition: service_healthy表示数据库健康检查通过后应用容器才会启动避免应用启动时数据库还没就绪减少一类连接失败问题。volumes中lector_data和pg_data都是命名数据卷分别保存应用文件数据和 PostgreSQL 数据文件。删除容器不会删除数据卷这是数据持久化的关键。Compose 参数作用修改时注意ports宿主机端口和容器端口映射容器侧端口必须匹配镜像暴露端口environment容器内环境变量改后要重新创建容器才生效volumes数据持久化挂载不要随意换卷名否则数据会“消失”restart故障重启策略生产通常使用 unless-stoppeddepends_on服务启动顺序和健康检查配合更好3.3 启动、停止和查看日志配置文件写好后先做语法和变量校验docker compose config这个命令会解析docker-compose.yml和.env输出渲染后的完整配置。如果环境变量引用错误或 YAML 语法有问题会在这里暴露。确认无误后启动docker compose up -d-d表示后台运行。启动完成后查看状态docker compose ps查看应用日志docker compose logs -f lector日志里如果出现数据库连接成功、HTTP 服务监听端口等提示说明应用启动阶段正常。-f是持续跟踪退出时按 CtrlC。3.4 首次访问与健康检查浏览器访问http://服务器IP:8080应能看到 Lector 的界面或初始化页面。如果页面无法打开按这个顺序排查宿主机本机访问curl http://127.0.0.1:8080能通说明服务进程正常问题是外部网络。检查云安全组是否放行 8080。检查系统防火墙sudo ufw status或firewall-cmd --list-all。检查容器状态docker compose ps是否显示Up。注意不要只验证页面能打开还要验证登录、数据写入和重启后数据是否还在。页面能打开只说明 Web 服务正常不代表数据库和持久化都配置正确。4. 数据持久化与备份迁移4.1 数据卷的类型与选择Compose 里常用的两种数据持久化方式命名数据卷和 bind mount。命名数据卷由 Docker 管理位置在/var/lib/docker/volumes/下通过卷名引用配置简洁跨环境迁移时不容易出现路径问题适合数据库文件和应用数据。bind mount 把宿主机的某个目录直接挂进容器例如./data:/app/data好处是文件可以直接在宿主机查看和修改坏处是权限管理更容易出错。对于自托管场景推荐数据库使用命名数据卷应用上传的文件或材料库同理。bind mount 一般只用于需要频繁在宿主机侧查看日志或配置的场景。4.2 数据库备份与恢复命令先看数据库容器是否能执行 pg_dumpdocker compose exec db pg_dump -U lector lector lector_backup_$(date %F).sql这条命令在 db 容器里执行 PostgreSQL 自带的导出工具备份文件输出到宿主机当前目录。文件名带日期方便轮转旧备份。恢复时先把备份文件导入容器docker compose exec -T db psql -U lector -d lector lector_backup_2024-08-01.sql注意exec -T表示不分配伪终端让标准输入可以重定向。除了数据库应用本身如果有文件数据还需要备份对应的命名数据卷。数据卷备份的常见方式是临时启动一个容器挂载该卷并打包docker run --rm \ -v lector_lector_data:/data \ -v $(pwd):/backup \ alpine tar czf /backup/lector_data_$(date %F).tar.gz -C /data .这里lector_lector_data是 Compose 项目创建的实际卷名实际名称可以用docker volume ls查看。打包结果在宿主机当前目录。4.3 迁移到另一台服务器迁移需要串联三个部分应用配置、数据库数据、应用文件数据。推荐流程是在新服务器上安装同样版本的 Docker Engine 和 Compose 插件。复制docker-compose.yml和.env到新服务器。先在空环境启动一次让数据卷创建出来。停止服务。恢复数据库备份。恢复应用文件数据卷。重新启动做验证。迁移时最容易出错的是环境变量不一致比如数据库密码不同、端口不同。恢复后要确认.env里的连接参数和实际恢复的数据一致。5. 一次完整的阅读学习流程验证5.1 导入材料的常见方式在语言阅读器里材料来源通常有几类粘贴纯文本、导入 EPUB/TXT 等文件、通过浏览器扩展保存网页内容。具体到 Lector 支持哪些格式以项目文档为准。不管哪种导入方式验证时都应该确认三件事材料是否进入持久化存储导入后能否在文章列表看到文章内容、标题和作者等元信息是否正确。如果在界面导入后看不见优先检查 Lector自托管指南：Docker Compose部署语言阅读器与数据持久化
在语言学习工具里自托管类产品一直有稳定的需求。Lector 是一个 FOSS、self-hosted 的 language reader简单说它把服务器的部署权和数据控制权交还给使用者同时提供 cloud option让不想维护服务器的人也能直接使用这个阅读工具。项目以 Show HN 的形式出现在开发者社区意味着作者愿意把源码开放出来接受使用者的审查和反馈。下面先从 language reader、FOSS、self-hosted 和 cloud option 这几个关键词拆开讲然后用 Docker Compose 完整走一遍自托管部署、数据持久化、阅读验证、故障排查和生产化加固的流程。如果你有语言学习需求又希望自己掌控阅读数据这篇文章可以帮助你从零搭建一套可用的环境也能帮你在自托管和云托管之间做出更合理的判断。适合的读者包括熟悉基本 Linux 命令、了解 Docker 概念、有独立服务器或 NAS、正在寻找自托管学习工具的开发者。即使你还没有服务器也可以先理解文章中的部署结构和排查思路后续再决定采用哪种路线。1. Lector 是什么先把几个关键词拆开看1.1 language reader 到底解决什么问题阅读是语言学习里最稳定的输入途径。直接面对外文材料时学习者经常遇到三个问题查词动作打断阅读节奏查过的生词散落在不同位置下次遇到还是不认识同一篇文章在不同设备上无法续读阅读进度和组织全靠手动。language reader 这类工具把材料管理、阅读展示、词汇查询、生词收集、复习回顾放进同一个界面。阅读时点击某个词释义直接出现在当前页面上不需要切换到词典应用被查询过的词可以加入生词本文章列表、阅读位置和生词数据由服务端保存换设备也能继续。放到语言阅读器这个场景里核心价值就是让输入过程保持连续同时让查询和积累成为阅读的自然副产品。对于德语、法语、日语、英语这类词形变化丰富的语言边读边查边积累的体验会比把阅读和查词完全分离好很多。1.2 FOSS 不是“免费”那么简单FOSS 是 Free and Open Source Software 的缩写。这里的 free 指的是自由不是免费。自由软件强调四件事无论什么目的都可以运行程序可以研究程序如何工作并修改它可以重新分发副本帮助他人可以发布修改后的版本让整个社区受益。对普通自托管用户来说FOSS 带来两个直接好处第一不存在授权锁定服务端和客户端都不需要担心试用期结束或商业授权变化第二源码开放意味着部署、审计和二次修改都可行如果项目某个默认配置不适合自己的使用习惯可以自己调整。同时也需要保持理性预期。开源不代表没有维护成本社区项目的活跃度、文档完整度和版本兼容性都需要实际评估。决定长期依赖一个自托管项目前建议先看它的仓库活跃度、issue 处理情况和最近 release 频率。1.3 self-hosted 与 cloud option 不是互相替代的关系self-hosted 的意思是服务运行在自己控制的服务器、NAS 或个人电脑上数据库和文件都保存在自己的存储里。cloud option 则是由项目运营方提供托管服务用户注册后直接使用不需要处理安装部署和服务器维护。两者不是非此即彼。很多开源项目会同时提供两条路线习惯自己维护、在意数据控制权的用户选择 self-hosted希望开箱即用、不想承担运维成本的用户选择 cloud。选择主要取决于几个变量你对数据隐私的敏感程度、是否愿意承担升级和备份工作、以及你的服务器运维能力。对 Lector 这类 language reader 来说数据本身就是长期积累的包括阅读材料、生词本、学习进度和标注。选 self-hosted 意味着这些数据由自己保管风险是服务器故障或备份缺失导致丢失选 cloud 意味着数据托管在别人的基础设施上风险是服务变更、停止运营或隐私边界变化。这个权衡没有标准答案放到具体使用场景里讨论更合理。维度self-hostedcloud option部署门槛需要服务器、Docker、域名等基础知识注册账号即可数据位置自己服务器或设备项目方基础设施维护成本自己负责升级、备份、排错由运营方负责月度成本主要是服务器费用按订阅或套餐计费定制能力可以改源码和配置通常只能使用公开功能隐私边界数据完全在自己控制内需要信任服务方这张表是一般规律具体到 Lector以项目部署文档和服务条款为准。2. 自托管部署前的环境准备2.1 运行环境与前置依赖自托管 Lector 这类 Web 应用常见的最低环境是一台 Linux 服务器CPU 2 核、内存 2GB 以上磁盘根据阅读材料库大小预留。系统推荐 Debian 或 Ubuntu也可以使用 NAS 设备上的 Docker 环境。Windows 和 macOS 本机能用 Docker Desktop 跑通但长期使用仍然建议放在 Linux 或 NAS 上。软件层面建议先确认已经安装 Docker Engine 20.10 以上版本以及 Docker Compose v2 插件。Docker 不是唯一选择也可以手动安装语言运行时、数据库和反向代理但容器化部署更容易让配置可复现、环境可隔离、升级可回滚。需要强调一点Lector 实际要求什么依赖要查看项目 README 或部署文档。下面的部署示例用于说明自托管 Web 应用的一般结构和参数落地时把镜像、端口和环境变量替换成项目实际值。项目学习环境生产环境建议操作系统Linux/Windows/macOS 本机Linux 服务器或 NASCPU1 核以上2 核以上内存1-2GB2-4GBDocker20.10 以上20.10 以上域名可选建议有备份手动导出定时任务HTTPS可选必须2.2 为什么用 Docker Compose 作为主要编排方式单个容器适合一个进程的场景但语言阅读器通常不止一个服务。除了应用本体还需要数据库保存账号、生词和进度生产环境还可能有反向代理。Docker Compose 在一个 YAML 文件里描述多个服务、网络、数据卷和依赖关系一条命令完成创建和启动。Compose 带来几个实际好处环境变量集中在一个.env文件中管理不会把密码写死在命令历史里数据卷由配置声明删除容器再重建数据仍然存在升级时只改镜像标签重新up -d完成依赖关系比如应用依赖数据库先启动可以通过depends_on声明日志统一走docker compose logs查看。2.3 部署前需要确认的五个检查点第一端口是否被占用。如果打算用宿主机的 8080 端口先执行ss -lntp | grep :8080没有输出说明端口空闲有输出则需要换端口或停掉占用进程。第二磁盘空间。镜像会占用几百 MB数据库和材料库会持续增长。用df -h /opt确认根分区或目标目录有足够空间。第三防火墙和安全组。云服务器通常有两层系统防火墙和云厂商安全组。即使容器启动成功端口没有放行外部仍然无法访问。需要同时检查这两处。第四时区。时区不对会导致学习记录的时间戳偏差建议在环境变量中统一设置TZAsia/Shanghai。第五备份策略。自托管最怕的不是部署失败而是数据丢失。部署前就应该想好数据卷和数据库导出任务放在哪里这部分内容在第 4 节展开。3. 用 Docker Compose 部署最小可用实例3.1 创建项目目录与 .env 文件假设项目部署在/opt/lectorsudo mkdir -p /opt/lector cd /opt/lector sudo touch docker-compose.yml sudo touch .env.env文件用于保存环境变量内容类似APP_PORT8080 POSTGRES_DBlector POSTGRES_USERlector POSTGRES_PASSWORDchange-me SECRET_KEYchange-me TZAsia/Shanghai其中SECRET_KEY用于应用对会话或 token 签名生产环境必须改成随机值。生成随机值可以使用openssl rand -base64 48注意.env文件包含敏感信息不要提交到 Git 仓库。如果项目目录使用 Git需要在.gitignore中加入.env。3.2 docker-compose.yml 逐段解读下面是一个通用的 Compose 编排示例目的是展示语言阅读器自托管时的服务结构和参数关系。实际部署时image要换成 Lector 正式发布的镜像地址如果项目只提供源码则需要先根据官方构建流程构建镜像。services: lector: image: your-registry/lector:latest container_name: lector restart: unless-stopped ports: - ${APP_PORT}:8080 environment: APP_PORT: 8080 DB_HOST: db DB_PORT: 5432 DB_USER: ${POSTGRES_USER} DB_PASSWORD: ${POSTGRES_PASSWORD} DB_NAME: ${POSTGRES_DB} SECRET_KEY: ${SECRET_KEY} TZ: ${TZ} volumes: - lector_data:/app/data depends_on: db: condition: service_healthy db: image: postgres:16-alpine container_name: lector-db restart: unless-stopped environment: POSTGRES_DB: ${POSTGRES_DB} POSTGRES_USER: ${POSTGRES_USER} POSTGRES_PASSWORD: ${POSTGRES_PASSWORD} TZ: ${TZ} volumes: - pg_data:/var/lib/postgresql/data healthcheck: test: [CMD-SHELL, pg_isready -U ${POSTGRES_USER} -d ${POSTGRES_DB}] interval: 10s timeout: 5s retries: 5 volumes: lector_data: pg_data:关键点如下。lector服务通过${APP_PORT}读取.env中的端口把宿主机的 8080 映射到容器内部端口。容器内部端口是否必须是 8080取决于项目镜像暴露的端口需要看项目的 Dockerfile 或镜像说明。DB_HOST: db表示应用通过 Compose 内部 DNS 访问数据库服务Compose 会为所有服务创建一个默认网络服务名就是主机名。不要把这里的db改成localhost因为应用在容器里localhost指向容器自身而不是数据库容器。restart: unless-stopped让服务在服务器重启或容器异常退出后自动拉起这是自托管常用策略。depends_on加condition: service_healthy表示数据库健康检查通过后应用容器才会启动避免应用启动时数据库还没就绪减少一类连接失败问题。volumes中lector_data和pg_data都是命名数据卷分别保存应用文件数据和 PostgreSQL 数据文件。删除容器不会删除数据卷这是数据持久化的关键。Compose 参数作用修改时注意ports宿主机端口和容器端口映射容器侧端口必须匹配镜像暴露端口environment容器内环境变量改后要重新创建容器才生效volumes数据持久化挂载不要随意换卷名否则数据会“消失”restart故障重启策略生产通常使用 unless-stoppeddepends_on服务启动顺序和健康检查配合更好3.3 启动、停止和查看日志配置文件写好后先做语法和变量校验docker compose config这个命令会解析docker-compose.yml和.env输出渲染后的完整配置。如果环境变量引用错误或 YAML 语法有问题会在这里暴露。确认无误后启动docker compose up -d-d表示后台运行。启动完成后查看状态docker compose ps查看应用日志docker compose logs -f lector日志里如果出现数据库连接成功、HTTP 服务监听端口等提示说明应用启动阶段正常。-f是持续跟踪退出时按 CtrlC。3.4 首次访问与健康检查浏览器访问http://服务器IP:8080应能看到 Lector 的界面或初始化页面。如果页面无法打开按这个顺序排查宿主机本机访问curl http://127.0.0.1:8080能通说明服务进程正常问题是外部网络。检查云安全组是否放行 8080。检查系统防火墙sudo ufw status或firewall-cmd --list-all。检查容器状态docker compose ps是否显示Up。注意不要只验证页面能打开还要验证登录、数据写入和重启后数据是否还在。页面能打开只说明 Web 服务正常不代表数据库和持久化都配置正确。4. 数据持久化与备份迁移4.1 数据卷的类型与选择Compose 里常用的两种数据持久化方式命名数据卷和 bind mount。命名数据卷由 Docker 管理位置在/var/lib/docker/volumes/下通过卷名引用配置简洁跨环境迁移时不容易出现路径问题适合数据库文件和应用数据。bind mount 把宿主机的某个目录直接挂进容器例如./data:/app/data好处是文件可以直接在宿主机查看和修改坏处是权限管理更容易出错。对于自托管场景推荐数据库使用命名数据卷应用上传的文件或材料库同理。bind mount 一般只用于需要频繁在宿主机侧查看日志或配置的场景。4.2 数据库备份与恢复命令先看数据库容器是否能执行 pg_dumpdocker compose exec db pg_dump -U lector lector lector_backup_$(date %F).sql这条命令在 db 容器里执行 PostgreSQL 自带的导出工具备份文件输出到宿主机当前目录。文件名带日期方便轮转旧备份。恢复时先把备份文件导入容器docker compose exec -T db psql -U lector -d lector lector_backup_2024-08-01.sql注意exec -T表示不分配伪终端让标准输入可以重定向。除了数据库应用本身如果有文件数据还需要备份对应的命名数据卷。数据卷备份的常见方式是临时启动一个容器挂载该卷并打包docker run --rm \ -v lector_lector_data:/data \ -v $(pwd):/backup \ alpine tar czf /backup/lector_data_$(date %F).tar.gz -C /data .这里lector_lector_data是 Compose 项目创建的实际卷名实际名称可以用docker volume ls查看。打包结果在宿主机当前目录。4.3 迁移到另一台服务器迁移需要串联三个部分应用配置、数据库数据、应用文件数据。推荐流程是在新服务器上安装同样版本的 Docker Engine 和 Compose 插件。复制docker-compose.yml和.env到新服务器。先在空环境启动一次让数据卷创建出来。停止服务。恢复数据库备份。恢复应用文件数据卷。重新启动做验证。迁移时最容易出错的是环境变量不一致比如数据库密码不同、端口不同。恢复后要确认.env里的连接参数和实际恢复的数据一致。5. 一次完整的阅读学习流程验证5.1 导入材料的常见方式在语言阅读器里材料来源通常有几类粘贴纯文本、导入 EPUB/TXT 等文件、通过浏览器扩展保存网页内容。具体到 Lector 支持哪些格式以项目文档为准。不管哪种导入方式验证时都应该确认三件事材料是否进入持久化存储导入后能否在文章列表看到文章内容、标题和作者等元信息是否正确。如果在界面导入后看不见优先检查