企业官网建设流程全解析

做知识管理这些年，我把市面上的工具基本试了个遍。大而全的知识库平台功能丰富，但部署和运维成本都压在团队身上；在线笔记软件用起来顺手，数据却在别人服务器里；Wiki.js 功能强，但折腾一圈后感觉“知识库”本身的仪式感已经超过了记录这件事。后来我换了一条思路：内容全部用 Markdown 文件保存，展示层选一个足够轻的 Web 应用，整个包用 Docker 容器化部署——这套组合里，核心展示层我选了 Raneto。

Raneto 是一个基于 Node.js 的开源知识库工具，最大的特点是不依赖数据库，一个文件夹里的 Markdown 文件就是全部内容，服务启动后会自动生成带分类、侧边栏和全文搜索的文档站。配合 Docker 使用，环境干净、迁移方便、备份只需要拷贝一个目录。这篇实战记录会把完整的容器化部署过程写出来：从镜像方案选型、目录规划、Dockerfile 编写，到 docker-compose 编排、内容组织方式和日常维护中的坑，适合正在折腾轻量级知识库的个人开发者，也适合想给团队快速搭一套内网文档中心的人。

1. 为什么我用 Docker 部署一个 Markdown 知识库

1.1 Raneto 到底是个什么样的工具

先把这个工具是什么说清楚。Raneto 在技术圈里常被称为“Markdown 知识库”，它做的事情非常简单：指定一个 content 目录，这个目录里的 Markdown 文件夹结构会自动变成网站的栏目和页面结构，访问者打开浏览器就能看到一份组织良好的文档站。它自带全文搜索、多语言界面、简单的主题系统，不需要 MySQL、不需要 Redis、不需要单独的管理后台。

我实践下来的最大感受是：Raneto 把知识管理的复杂度压到了最低。普通团队搭内部知识库，需求往往就是“能写、能读、能搜、能分类、能长期保存”。Raneto 恰好覆盖了这些核心能力，而那些重量级系统里常见的权限矩阵、工作流审批、富文本编辑器，在这里都不是必需品。对你个人来说，它更像一个“把文件夹变成网站”的魔法盒，往里丢 Markdown 文件，网页上就多出一篇排版工整的文章。

1.2 Docker 化给知识管理带来了什么

没有 Docker 的时候部署 Raneto，要在服务器上装 Node.js、克隆源码、跑 npm install、再手动维护进程守护。这套流程放在团队内部还行，放到多台机器上就是灾难：每台机器 Node 版本不一样、某个原生依赖编译失败、进程崩了没人拉起。Docker 把这些问题一次性解决掉了。

具体来说，Docker 化给这个知识库带来三个明显好处。第一是环境锁定，镜像里装的是什么都看得见，运行它的宿主机只需要有 Docker Engine，Node 版本、系统库、依赖关系全部固话在镜像里，不会再出现本地跑得好好的、部署到服务器就报错的情况。第二是数据与程序分离，Raneto 的程序在容器里，内容在挂载出来的目录里，我随时可以把容器删掉重建，只要 content 目录没动，知识库就毫发无损。第三是迁移极方便，整个知识库等于一个镜像加一个数据目录，打包拷到新机器，拉起容器就是原样，这在换服务器、搭演示环境、灾备恢复的时候非常宝贵。

1.3 适用场景与不适合的场景

聊点实在的，Raneto 不是万能的，选型之前你得先分清场景。我推荐的用法是：个人笔记站、小团队内部文档库、产品使用手册、技术团队的运维知识沉淀。这些场景的特点是内容量适中、以阅读为主、作者数量在几个人到十几个人之间，不需要复杂的权限体系。

不适合的场景也很清楚。如果你需要多人同时在线编辑同一篇文档，需要字段级权限审批，需要富文本协同、在线表格、任务看板这些能力，那应该去看 Confluence、语雀这类产品，或者上 Wiki.js 配合数据库，Raneto 的“纯文件”模型支撑不了这种交互。多人协作在 Raneto 上的正确路径是用 Git 管理 content 目录，大家都在自己分支上写，然后合并，而不是像在线文档一样抢同一块画布。把这一条想明白，后面用起来就顺手很多。

2. 部署前准备：环境检查与目录规划

2.1 第一步：确认你的 Docker 环境真的可用

动手之前先花两分钟确认 Docker 环境。在 Linux 服务器上，执行docker --version和docker compose version，有输出且版本不是太老就行。在 Windows 或 macOS 上就是 Docker Desktop，安装时注意 Windows 需要提前打开 WSL2 功能，这个在最后排查章节还会专门讲，因为很多人的第一步就卡在这里。

验证 Docker 是否真正能跑，用一个最基础的办法：

docker run --rm hello-world

能正常打印出 Hello from Docker 的提示，说明容器运行时没问题。如果这一步报错，先别急着往下走，后面第五章有完整的排查思路。我见过不少人 Docker 装好了，但 daemon 没启动，或者虚拟化没开，结果在部署阶段浪费了大量时间。

因为 Raneto 本身是一个 Node 应用，我建议你在服务器上提前确认架构。绝大多数情况下是 amd64，但如果你用的是树莓派这类 ARM 设备，构建镜像时要选对基础镜像的架构，docker build 一般会自动处理，但如果你提前手动拉镜像，注意别拉错平台版本。

2.2 镜像怎么选：用社区镜像还是自己构建

部署 Raneto 时很多人的第一反应是去 Docker Hub 直接搜一个 raneto 镜像拉下来跑。社区确实有这一类镜像，但我的建议是：自己用 Dockerfile 构建，而且理由非常实际。

其一，社区镜像的维护状况参差不齐，有些停留在好几年前的上游版本，有些 entrypoint 脚本写得有问题，配置目录、数据目录的路径跟默认行为不一致，跑起来之后你会花大量时间猜测“容器里的文件到底在哪个路径”。其二，Raneto 部署的难点本来就不在镜像本身，而在于数据目录、配置文件的挂载方式，自己构建镜像反而能让你把这套结构彻底掌握，后面遇到问题不用拍脑袋。

自己构建的本质是“用官方 Node 基础镜像，把 Raneto 源码装进去”。这个过程只需要几行 Dockerfile，可靠、可控、可审计。构建时也能把知识库的版本钉死在一个具体提交上，不至于某天基础依赖一升级，整个站点行为变了。下文第三章就是这一套完整流程。

考虑到部分环境下访问外网拉取源码和依赖不稳定，我的建议是：在拉不动源码时，先在宿主机上把 Raneto 源码 clone 下来，然后 COPY 进镜像，把 Git 操作从构建环节挪到构建前，构建过程会稳定不少。这个技巧我后面也会再提一次。

2.3 目录与端口规划：一次想清楚，后面少折腾

Docker 部署最忌讳边跑边改启动参数，我强烈建议在写第一个命令之前，把宿主机上的目录结构和端口规划好。我自己常用的项目根目录是这样：

/opt/raneto/ ├── content/ # 知识库内容，所有 Markdown 文件放这里 ├── config.js # Raneto 配置文件 ├── docker-compose.yml └── backup/ # 定期备份存放点

content 目录是整个知识库的灵魂，它必须通过 bind mount 方式挂载进容器，因为这个目录里的文件是需要反复修改、备份、纳入 Git 的，不能藏在 Docker 的匿名卷里。配置文件 config.js 也要挂载，虽然 Raneto 有很多配置支持环境变量覆盖，但直接用文件挂载更直观、更好维护。

端口规划方面，Raneto 默认监听容器内的 4000 端口。对外映射多少，取决于你是否要接 Nginx 反向代理。

• 直接暴露场景：8080:4000，用 IP 加 8080 访问
• 有 Nginx 场景：127.0.0.1:4000:4000，只让本机访问，Nginx 通过宿主机端口转发

我们小团队内部一开始直接暴露 8080，后来上了 HTTPS 之后改成只监听 127.0.0.1，这个后面在反向代理小节会讲。

3. 容器化部署实操：从 Dockerfile 到 docker-compose

3.1 用 Dockerfile 把 Raneto 装进镜像

我自己长期使用的 Dockerfile 相当简单：

FROM node:18-alpine WORKDIR /app # 安装 git，用于拉取源码 RUN apk add --no-cache git # 从上游仓库克隆 Raneto，这里建议钉住指定版本或提交 RUN git clone --depth 1 --branch v0.9.2 https://github.com/gilbitron/Raneto.git /app # 安装生产依赖 RUN npm install --production EXPOSE 4000 CMD ["npm", "start"]

解释一下几个关键选择。基础镜像用node:18-alpine，因为 Alpine 版镜像体积很小，实测构建出来的镜像比基于 Ubuntu 的版本小一半以上，对于跑在内网服务器上的知识库来说，少占硬盘、少被扫描漏洞，都是实打实的好处。--depth 1只拉取最新一次提交，避免把整个 Git 历史带进镜像，这一步能把镜像体积再压缩不少。--branch参数用于钉住版本，Raneto 的发布节奏不快，但钉住一个稳定 tag 仍然是负责任的做法。

如果你已经准备好了本地源码目录，也可以改为 COPY 模式：

FROM node:18-alpine WORKDIR /app COPY package.json ./ RUN npm install --production COPY . . EXPOSE 4000 CMD ["npm", "start"]

这种方式的优点是可以利用 Docker 的分层缓存，代码改了重新构建，只要 package.json 没变，npm install那一步就能直接命中缓存，构建速度飞快。缺点是你需要先拿到源码。两种方式没有谁更好，按你获取源码的渠道选择就行。

构建命令很简单：

docker build -t raneto:0.9.2 .

构建完成后可以验证一下镜像里的目录结构：

docker run --rm raneto:0.9.2 ls -la /app

确认/app/config.js、/app/content、/app/themes这些关键目录存在，后面所有容器配置都基于这个路径来写。

3.2 三行命令启动第一个容器并验证访问

镜像构建完成，先在宿主机上创建好内容目录和配置文件：

mkdir -p /opt/raneto/content cd /opt/raneto docker run -d \ --name raneto \ -p 8080:4000 \ -v /opt/raneto/content:/app/content \ -v /opt/raneto/config.js:/app/config.js \ raneto:0.9.2

逐个解释关键参数。-d是后台运行；--name raneto给容器起一个固定名字，后面docker logs raneto、docker restart raneto都不用猜容器 ID；-p 8080:4000把宿主机 8080 端口映射到容器的 4000 端口；-v挂载数据目录和配置文件，这是整个部署里最重要的一步——容器可以随时删除重建，但这两个路径下的文件始终留在宿主机上。

很多人第一次启动后会遇到一个问题：容器起来了，访问 8080 端口却看到默认欢迎页。这是正常的，因为你还没有写任何内容。在 content 目录里新建一个文件作为首页：

--- Title: 首页 Description: 团队知识库首页 Sort: 0 --- # 欢迎使用 Raneto 这里放知识库的概述和引导内容。

保存成content/index.md，然后刷新浏览器，对应页面就会出现在站点中。访问验证也可以用命令行：

curl -I http://localhost:8080

返回 HTTP 200 就说明服务正常。如果新浪微博出来的不是 200，执行docker logs raneto看日志，Node 应用的大部分启动错误都会直接打在这里。

3.3 升级到 docker-compose：多服务场景更好管

单个容器用 docker run 没问题，但只要你有一天想加 Nginx 反代、加自动备份容器、或者把宿主机上的服务统一起来管理，docker run 的裸命令就会变得难以维护。所以我的习惯是：验证完单容器没问题，立刻换成 docker-compose 编排。

项目根目录新建 docker-compose.yml，内容如下：

version: "3.8" services: raneto: image: raneto:0.9.2 container_name: raneto restart: unless-stopped ports: - "8080:4000" volumes: - ./content:/app/content - ./config.js:/app/config.js environment: - TZ=Asia/Shanghai

几个值得注意的点。restart: unless-stopped保证服务器重启后容器自动拉起，也保证偶尔因异常退出时能自动恢复，这比裸 docker run 默认可控多了。volumes用相对路径./content，前提是你必须在这个项目目录下执行命令，所以建议把 compose 文件放在固定项目根目录，别随手到处放。TZ环境变量把容器时区锁定，否则日志时间戳和宿主机对不上，排查问题时容易产生困扰。

启动与日常操作：

docker compose up -d # 启动 docker compose ps # 查看状态 docker compose logs -f raneto # 跟踪日志 docker compose restart raneto # 重启容器

docker compose up -d是幂等操作，改完配置再执行一次，只会重建配置有变动的容器，不会牵连其他无关服务。如果改了 Dockerfile 并想重新构建镜像，用docker compose up -d --build即可。

3.4 接上 Nginx 反向代理，把知识库藏到规范端口后面

绝大多数正式场景下，知识库不会裸奔在 IP:8080 上。接一层 Nginx 反向代理有三个好处：统一 80/443 端口入口、支持 HTTPS 证书、可以在 Nginx 层做访问控制和日志。先用 Docker 把 Nginx 也编排进来，然后写一个简化配置。

Raneto 使用标准的 http 请求，不需要 WebSocket，所以反向代理配置非常简单：

server { listen 80; server_name wiki.example.com; location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } }

关键是proxy_set_header的四个头信息，特别是X-Forwarded-Proto。Raneto 生成页面链接时会参考当前协议，如果少了这个头，你在 HTTPS 页面里可能会看到部分资源仍以 http 方式加载。这是我实战里踩过的坑，当时花了不少时间找原因，最后发现 Nginx 转发时把协议信息丢了。

如果你不想在宿主机上装 Nginx，也可以用 docker-compose 再起一个 nginx 容器，让两个容器共享同一个自定义网络。这样proxy_pass http://raneto:4000;走的是容器内部 DNS 解析，不经过宿主机端口。两种方案都可行，有经验的团队用 compose 方案更干净，个人使用在宿主机装 Nginx 反而少一层维护成本。

4. 把知识库结构化：Markdown 目录与导航规则

4.1 content 目录的文件夹结构决定导航

Raneto 最核心的机制就是“目录即导航”。你往 content 里建一个子目录，侧边栏就多一个分类；目录里的 Markdown 文件就是分类下的页面。这个概念理解透了，知识库的组织方式立刻从“写作任务”变成“文件夹设计任务”。

我的实际目录结构长这样：

content/ ├── index.md ├── docker/ │ ├── install.md │ ├── compose.md │ └── troubleshooting.md ├── devops/ │ ├── git-workflow.md │ └── backup-strategy.md ├── product/ │ ├── roadmap.md │ └── public-version.md └── meeting-notes/ └── weekly.md

页面的 URL 路径就是相对于 content 目录的路径去掉.md后缀。也就是说content/docker/install.md最终访问路径是/docker/install。这个规则意味着文件名最好用英文短横线命名，避免中文文件名在 URL 编码和部分文件系统上出现显示异常。我在早期知识库里用了一批中文文件名，结果侧边栏显示正常，但分享链接打开时经常变成一串百分号编码，体验很差。

目录层级方面，Raneto 对深层嵌套的支持不算特别完美，我的经验是控制在两层以内：第一层目录是栏目分类，第二层是页面或者二级分类。超过两层的需求建议拆成跨分类的独立页面，或者用页内锚点导航解决。强行堆嵌套层级会让侧边栏和面包屑的体验变差，维护时也会头痛。

4.2 Markdown 文件头部的元信息与排序技巧

Raneto 的每个 Markdown 文件都可以在头部写一段 YAML 格式的元信息，相当于页面配置区。我的标准模板：

--- Title: Docker 容器化部署 Raneto 实战 Description: 从镜像构建到 compose 编排的完整记录 Sort: 0 Tags: docker, raneto --- # Docker 容器化部署 Raneto 实战 正文内容...

Title会覆盖侧边栏显示名和浏览器标题，即使文件名是英文，侧边栏也能展示正常中文标题。Description用于页面描述和搜索引擎摘要，内网知识库虽然不依赖 SEO，但在文档列表页看到描述往往比只看到标题更有价值。Sort控制同一目录下页面的排序值，同为 0 时按文件名字母序排列；想置顶就设成负数，想排在后面就设大一些。

写完元信息后，一定要确保它被正确解析。我见过的最常见错误是把三横线写错了位置，或者少了结束的三横线，导致整篇文章被识别为一个纯 Markdown 页面，标题和排序全部失效。保存文件时顺手检查一眼头部，比事后在页面上发现问题再去改要省事得多。

另外提一个细节点：Markdown 正文的标题层级从第二个#开始写。Raneto 渲染正文时，第一级标题可能与页面标题重复，在搜索结果的上下文里显得很冗余。我习惯在正文里直接从##或###开始，这样页面顶部更干净。

4.3 搜索功能与内容索引的重建机制

Raneto 自带的搜索不需要额外服务，这是它作为轻量级方案的重要卖点。实现的原理是：在启动时把 content 目录里的文本加载进内存中的搜索索引，用户搜索时直接查这个内存索引。好处是部署简单、响应快；代价是更新内容后索引不会自动跟着变。

我的经验是：每次新增或大量修改内容后，手动执行docker restart raneto让索引重建一次。官方文档和一些社区教程都提到了这个行为，但很多人在体验时没有意识到“新内容搜不到”不是 bug，而是索引还没来得及重建。如果你希望内容一发布就能被搜到，可以把这个 restart 动作加进内容更新脚本里，或者写个简单的定时任务，每 5 分钟检查一次 content 目录有没有文件变动，有变动就触发重启。对于一个小团队的知识库来说，这个方案已经足够稳。

关于中文搜索，Raneto 内置的分词器对英文非常友好，对中文则表现一般。实测下来，完整的句子或短语可能匹配不理想，但单个关键词和标签一般能命中。如果你团队的知识库大量使用中文，我建议在每篇文档的 Tags 里手动加一两个最能代表内容的英文关键词，不能提升搜索精度，至少能在中文匹配失败时多一个可用的搜索入口。

5. 常见问题与排查技巧实录

5.1 Docker Desktop 启动失败、虚拟化未开启的排查思路

这个问题的出现频率很高，尤其是在 Windows 环境。现象就是打开 Docker Desktop，提示 virtual support not detected 或者 Docker failed to start，容器完全跑不起来。

排查步骤按顺序走：先确认 CPU 虚拟化是否打开。Windows 下打开任务管理器，切到“性能”标签页，看左下角“虚拟化”是不是“已启用”。如果是“已禁用”，进 BIOS 设置找 Intel VT-x 或 AMD-V 的开关（不同主板名称略有差异，一般在 CPU Configuration 或 Advanced 菜单下），打开后保存重启。

如果虚拟化已经是启用状态，检查 Windows 功能里有没有打开“适用于 Linux 的 Windows 子系统”和“虚拟机平台”。在 PowerShell 里以管理员身份执行Get-WindowsOptionalFeature -Online | Where-Object {$_.FeatureName -match "Hyper|Linux"}，看看状态。顺手执行wsl --status确认 WSL2 内核是否存在，Docker Desktop 对 WSL2 的依赖是强制的，内核文件缺失也会报虚拟化相关错误。

还有一种情况是装了 VirtualBox、VMware 这类虚拟机软件，它们与 Hyper-V 在同时启用时可能冲突。技多不压身，但你不用只顾着装更多虚拟机软件，关掉不用的 Hyper-V 相关功能或者改用 WSL2 后端，多半就通了。这些步骤没有什么高深的原理，纯属把环境条件逐一补齐，每台能跑的机器背后都是这么折腾过来的。

5.2 容器起不来、端口冲突、看日志的基本功

Docker 环境正常了，容器跑不起来是下一道坎。我的固定排查流程如下：

docker ps -a # 查看所有容器，包括异常退出的 docker logs raneto # 查看目标容器最后输出的日志 docker inspect raneto # 查看容器的挂载、端口、环境变量配置

日志是重中之重。Raneto 的启动日志如果出现报错，原因集中在三类：Node 依赖没装全（镜像构建阶段出了岔子）、配置文件路径不对导致启动时读取失败、挂载目录权限不足导致无法创建索引缓存。docker inspect里看 Mounts 字段，能确认挂载是否生效、目录是否映射正确，这一步能省下大把猜测时间。

端口冲突也是高频问题。启动时提示port is already allocated就说明宿主机端口被占了，用下面的命令找出来处理：

# Linux ss -lntp | grep 8080 # Windows netstat -ano | findstr 8080

找到占用进程后，要么停掉它，要么修改 compose 里的端口映射换一个。这类问题本身不复杂，重点在于排查顺序要对：先状态、再日志、后网络，别跳步。

权限问题在 Linux 上尤其多见。如果你用非 root 用户操作，挂载的 config.js 或 content 目录如果是从别处拷来的，可能出现 777 之类的奇怪权限。容器里的 node 用户读取时没问题，但写入缓存时会失败。解决办法是给数据目录一个合理的属主：

chown -R 1000:1000 /opt/raneto/content

5.3 中文乱码、搜索不到中文内容，这些问题实际存在

中文知识库最容易踩的坑集中在编码上。Raneto 对 Markdown 文件编码的要求是 UTF-8，这在 Linux 和 macOS 上几乎不是事，但在 Windows 上默认的记事本保存方式可能导致文件带 BOM 头。BOM 头在大多数场景下不会让显示崩溃，但会让 YAML 元信息的解析出现异常，表现就是第一行多了几个不可见字符，侧边栏标题偶尔不生效。

我的应对办法：给团队成员定一个规矩，文本编辑器统一用 VS Code，保存编码固定为 UTF-8。内容较多时直接用脚本做一次编码清洗：

find . -type f -name "*.md" -exec sed -i 's/^\xEF\xBB\xBF//' {} \;

这行命令去掉所有 Markdown 文件开头的 UTF-8 BOM。执行前建议先备份，或者先看看哪些文件真的有 BOM，别上来就全量替换。

中文搜索匹配不佳的问题前面已经提过，这里再补一条实测体验：Raneto 的搜索索引在重建时对每篇文档的内容做全文索引，中文文档实际上是把整段文字切成一个个 token 去匹配，短语查不到往往是因为切词规则没有把多个字组合成一个词。缓解办法有限，但合理设置Sort和Tags之后，至少能保证搜索入口是准确的，用户可以快速定位到相关页面，再在页面内用 Ctrl+F 找到具体位置。

5.4 数据备份与迁移：知识库的保命操作

一个知识库如果丢了内容，工具再轻量也等于零。我这套方案里备份的逻辑非常简单——整个知识库就是 content 目录加上一个 config.js，没有数据库，没有体积巨大的附加状态。备份命令一行搞定：

tar czf raneto-backup-$(date +%F).tar.gz content config.js

备份策略建议做两层：每日一次本地定时备份，每周一次把备份文件同步到另一台机器或对象存储。本地备份直接写到挂载的 backup 目录，同步用rsync或scp都行。这套方案比我之前在 Confluence 上做数据库 dump 轻松太多，恢复流程也完全可预测。

迁移到新机器就更直接了：新机器装 Docker，把 content 和 config.js 拷过去，重新 docker compose up -d，完事。整个过程不需要导出导入乱七八糟的数据文件，也不会遇到数据库版本不兼容的问题。我帮同事迁移过一次知识库，从拉起来到旧内容完整出现在新站点上，前后十分钟，这个体验在传统知识库方案里是不敢想的。

配了 Git 之后，备份还能更进一步：content 目录直接纳入 Git 仓库，每次内容变更都提交一次，等于有了完整的历史版本。这样如果团队写作时出现误删，从 Git 历史里就能捞回来，这比定时文件的备份更精细一层。

6. 进阶玩法与我的实际体会

这套方案跑起来之后，日常维护几乎感觉不到它的存在，但内容更新一直要做，所以我把几个小范围的自动化加了上去。我给 content 目录挂了一个简单的定时任务，每五分钟检查文件有没有变动，有变动就触发docker restart raneto，把搜索索引刷一遍。这样团队同事写完文档推个 Git，webhook 触发更新脚本，知识库过一两分钟就能看到新内容，体验上已经接近现代文档平台了。

还有一个小技巧：把 content 目录直接放进 Git 仓库，团队多人写作时各自 clone 一份，写完 push 到共享仓库，更新脚本在服务器上拉取后重启。这样每个人都有自己的工作区，不用担心两个人同时改一个文件互相覆盖；真改坏了大不了从 Git 历史找回来。我个人的体会是，Raneto 的内容组织方式一旦用顺手，你会因为“所有知识都是本地文件”而感到非常安心，不怕平台关闭、不怕数据锁定、不怕某天打开服务发现全部内容被清空。

如果哪天你觉得默认主题不够好看，可以挂载一个自定义主题目录：-v /opt/raneto/themes:/app/themes，然后把官方默认主题复制出来改样式，改完刷新就能看到效果。Raneto 的主题结构不复杂，稍微会一点 CSS 就能把知识库调成符合团队风格的样子。

最后说点更实际的经验：这套轻量级知识管理方案适合“先跑起来再说”的心态。不要一开始就追求完美的分类、严格的权限、绚丽的主题，把 Markdown 写起来，把 Docker 容器拉起来，让知识开始沉淀，等积累到一定量之后，内容和结构自然会告诉你接下来该怎么调整。Raneto 加上 Docker，是我试过最能让人专注于“写作”而不是“平台维护”的知识库方案。