自托管 Wiki 对比：BookStack、Wiki.js 还是 Outline

应运行哪个自托管 Wiki

自托管 Wiki 会将团队文档集中存放在您控制的服务器上，并提供统一搜索。BookStack、Wiki.js 和 Outline 都能完成这项工作。它们的主要差异在于：首次打开页面前需要组装多少组件，以及允许哪些用户登录。

BookStack 最容易部署，对文档结构的约束也最强。Wiki.js 在同一页面树中提供最丰富的编辑器选择。Outline 的写作体验在三者中最好，但在连接外部身份提供商之前，不允许任何人登录。

以下内容均来自这些项目自己的文档和公开发布的配置文件。这是功能对比，不是基准测试。由于这三个项目都在持续更新，版本号和要求均标注了日期。

结构才是真正的选择

BookStack 固定了内容的层级结构。页面位于书籍中，书籍可以包含章节，书架用于归类书籍。您不能自行创建第五级。这种限制正是产品的价值所在：新作者知道页面应放在哪里，因为页面只有一个合理位置。代价是，不符合该结构的内容也必须被强行纳入其中。

Wiki.js 使用类似磁盘文件夹的路径树。位于 ops/backup/restic 的页面可以放在您指定的任意位置，层级深度也由您决定。系统不会阻止两个人将同一主题归档到两个不同的分支中，因此 Wiki.js 实例需要由一个人负责维护这棵树。

Outline 使用集合，文档可以嵌套在其他文档中。移动文档时，只需用鼠标拖动。三者之中，它的灵活性最高，因此也最容易逐渐失去一致性。

BookStack：最小化安装

BookStack 是一个由 MySQL 支持的 PHP 应用。截至 2026 年 7 月，文档要求 PHP 8.2 或更高版本，以及 MySQL 8.0 或 MariaDB 10.6 或更高版本。如果从源代码安装，还需要 Composer 2.2 或更高版本。当前发布系列为 26.05。

该项目为每个 Ubuntu 版本发布一个安装脚本。24.04 脚本会自动安装 Apache、MySQL 8.0 和 PHP 8.3。

wget https://codeberg.org/bookstack/devops/raw/branch/main/scripts/installation-ubuntu-24.04.sh
chmod a+x installation-ubuntu-24.04.sh
sudo ./installation-ubuntu-24.04.sh

运行脚本前，请先阅读其中的警告。文档说明，该脚本“仅适用于全新的操作系统。它会安装 Apache、MySQL 8.0 和 PHP 8.3，并可能覆盖计算机上现有的 Web 配置”。如果服务器已在 80 端口提供服务，该脚本会占用该端口并重写 Apache 配置。此时应改用容器，或在 Ubuntu 24.04 上基于现有的 LAMP 栈手动安装 BookStack。

容器方案使用 LinuxServer.io 镜像，这是 BookStack 文档推荐的选项。BookStack 需要会话加密密钥。没有该密钥时，它不会提供页面，因此应先生成密钥。

docker run -it --rm --entrypoint /bin/bash lscr.io/linuxserver/bookstack:latest appkey

将输出的值复制到 APP_KEY，然后写入服务配置：

services:
  bookstack:
    image: lscr.io/linuxserver/bookstack:latest
    container_name: bookstack
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Etc/UTC
      - APP_URL=https://wiki.example.com
      - APP_KEY=paste_the_generated_key_here
      - DB_HOST=bookstack_db
      - DB_PORT=3306
      - DB_USERNAME=bookstack
      - DB_PASSWORD=change_me
      - DB_DATABASE=bookstackapp
    volumes:
      - ./config:/config
    ports:
      - 6875:80
    restart: unless-stopped

APP_URL 必须与读者实际输入的地址一致，包括协议和端口。将其设置为 http://localhost，然后通过 HTTPS 提供站点服务。否则，生成的链接和重定向会指向错误的主机，读者会看到不断重定向回自身的登录页面。如果你不熟悉 compose 文件，请先阅读VPS 上的 Docker Compose 基础，再进行本节操作。

启动服务，并确认应用能够响应，而不只是确认容器正在运行：

docker compose up -d
docker compose ps
curl -sI http://127.0.0.1:6875/login

出现 200 OK 表示 PHP 应用已启动并连接到数据库。出现 500 通常表示 APP_KEY 为空，或数据库凭据不匹配；docker compose logs bookstack 会显示具体是哪一种情况。

Wiki.js：一棵目录树，多个编辑器

Wiki.js 是一个 Node.js 应用。官方文档中的 Docker 配置将它与 PostgreSQL 配合使用，但该软件也支持 MySQL、MariaDB、MSSQL 和 SQLite。下面是项目自有 Docker 页面中的 compose 文件：

services:
  db:
    image: postgres:15-alpine
    environment:
      POSTGRES_DB: wiki
      POSTGRES_PASSWORD: wikijsrocks
      POSTGRES_USER: wikijs
    logging:
      driver: none
    restart: unless-stopped
    volumes:
      - db-data:/var/lib/postgresql/data
  wiki:
    image: ghcr.io/requarks/wiki:2
    depends_on:
      - db
    init: true
    environment:
      DB_TYPE: postgres
      DB_HOST: db
      DB_PORT: 5432
      DB_USER: wikijs
      DB_PASS: wikijsrocks
      DB_NAME: wiki
    restart: unless-stopped
    ports:
      - "80:3000"
volumes:
  db-data:

运行前同时修改 POSTGRES_PASSWORD 和 DB_PASS，因为它们共同构成一个凭据，示例值已公开。这里有意将标签固定为 ghcr.io/requarks/wiki:2。文档不建议使用 latest，因为跨越主版本会在运行中的实例上变更数据库架构。

应运行版本 2。以 2026 年 7 月为准，最新的版本 2 发布版本是 2.5.314，于 2026 年 5 月发布。版本 3 已存在，其文档明确写道：“此站点用于 Wiki.js 3.0 的不稳定 beta 版本。您不应在生产环境中安装此版本。”请将 :3 标签视为预览版本。

首次加载时，Wiki.js 会引导您在浏览器中完成设置，并创建管理员账户。在完成设置前，任何能访问该端口的人都会看到此向导。因此，在开放防火墙端口前，应先将服务置于反向代理和 TLS（传输层安全）之后。如果服务器运行的不止这一个服务，可将使用独立主机名的 wiki 放在 多个 Docker 应用前的 Traefik 后面。

编辑器选择是用户选择 Wiki.js 的主要原因。一个实例可以并列存放 Markdown 页面、可视化编辑器页面、原始 HTML 页面和 AsciiDoc 页面。这适合导入不希望转换格式的旧内容。但这样也可能让一个 wiki 同时出现四种内部写作规范。因此，应在第一天确定默认编辑器，并记录这一决定。

概览：最佳编辑器，最重的前置依赖

人们通常所说的“感觉像商业笔记工具”的产品，指的就是 Outline。它是一个 Node.js 应用，截至 2026 年 7 月，当前版本为 1.9.2。其示例环境文件列出了所需组件：通过 DATABASE_URL 使用 PostgreSQL，通过 REDIS_URL 使用 Redis，两个随机密钥，以及一个可从公网访问的 URL。

openssl rand -hex 32
openssl rand -hex 32

运行两次并保留两个值。第一个值用于 SECRET_KEY，第二个值用于 UTILS_SECRET。环境文件的核心部分如下：

NODE_ENV=production
URL=https://docs.example.com
PORT=3000
SECRET_KEY=<first openssl value>
UTILS_SECRET=<second openssl value>
DATABASE_URL=postgres://outline:change_me@postgres:5432/outline
PGSSLMODE=disable
REDIS_URL=redis://redis:6379
FILE_STORAGE=local
FILE_STORAGE_LOCAL_ROOT_DIR=/var/lib/outline/data

只有在数据库位于同一台机器或同一 Docker 网络中时，PGSSLMODE=disable 才是正确的。对于通过网络访问的数据库，请省略该配置，否则连接将以明文传输。附件不再强制要求使用对象存储：FILE_STORAGE=local 会将上传文件写入上述目录。该目录必须是容器可写入的卷，并且必须纳入备份范围。如果希望将这些文件存储在兼容 S3 的存储桶中，请改用 AWS_* 中的 AWS_* 值设置 FILE_STORAGE=s3。

接下来是容易让人意外的部分。Outline 没有内置的用户名和密码登录功能。其示例配置明确要求第三方登录凭据：“要正常安装，以下配置中至少需要一个，否则将没有登录选项”。文档列出的身份提供商包括 Google、Slack、Microsoft Entra、Discord，以及任何兼容 OpenID Connect (OIDC) 的服务器，分别通过 OIDC_CLIENT_ID、OIDC_CLIENT_SECRET、OIDC_AUTH_URI、OIDC_TOKEN_URI 和 OIDC_USERINFO_URI 配置。

因此，Outline 的实际成本是 Outline、PostgreSQL、Redis 和一个身份提供商。如果团队已经使用 Google Workspace 或 Microsoft Entra 登录，最后一项只需花费 10 分钟，Outline 就很有吸引力。如果没有，您还需要自行托管 Keycloak 或 Authentik 之类的服务。这意味着又多了一个需要打补丁和备份的服务。请据此规划内存：Outline 的建议值约为每个 Web 进程 512 MB，由 WEB_CONCURRENCY 设置，此外还要为数据库和 Redis 分配内存。

每种系统如何处理访问权限

BookStack 开箱即用地提供本地电子邮件和密码账户，并支持 LDAP、SAML2 和 OIDC 作为替代方案。权限按角色设置，也可以在单个书架、书籍、章节或页面上覆盖。由于层级结构固定，权限会按层级向下继承，行为可以预期。

Wiki.js 同样提供本地账户，并在管理区域中加入大量可启用的认证策略。其页面规则按路径模式授予或拒绝访问权限。这种方式功能强大，但也容易配置错误，因为为 ops/* 编写的规则会静默覆盖以后归档到该路径下的所有页面。

Outline 完全将这一问题交给外部身份系统处理。成员关系遵循您的身份提供商，您可以在 Outline 中按集合和组控制访问权限。员工离开公司后，不会在 Outline 中遗留本地账户。如果身份提供商本身就是您执行账户停用操作的系统，这是一个明显优势。

各自的搜索机制

搜索功能决定了 wiki 是真正有用的知识库，还是最终变成一个无人整理的文件夹。

BookStack 会搜索数据库，并提供一套读者一分钟内即可学会的查询语言。使用引号括起短语（如 "london meeting"）时，必须匹配完全相同的字符串。方括号用于搜索标签：[location=london] 可按标签名称、标签值或两者进行匹配，支持 !=、>= 和 like 等比较运算。花括号用于按元数据筛选，例如 {created_after:2016-12-30}。任何精确匹配、标签或筛选条件前都可以添加 - 来排除该条件。BookStack 限制单个查询中每种条件的数量，因此过长的查询会被截断，而不会直接执行。

Wiki.js 将搜索作为可插拔模块处理。文档列出的引擎包括基础数据库引擎、PostgreSQL 引擎、Elasticsearch、Algolia、AWS CloudSearch 和 Azure Search。基础引擎适合只有几百个页面的 wiki。如果使用 PostgreSQL，应在管理区域切换到 PostgreSQL 引擎，因为它使用数据库自身的全文索引，而不是简单匹配。只有在 wiki 足够大，并且能够接受运行和维护第二个搜索服务时，才应使用 Elasticsearch。

Outline 使用 PostgreSQL 全文索引进行搜索。它没有可选的搜索引擎，也没有需要调整的参数，同时还会搜索已上传文档中的文本。对于文档数量只有几千份的团队 wiki，Outline 是三者中维护工作最少的方案。如果搜索速度最终不再满足要求，也没有可调整的选项。

选择适合您的方案

如果您希望今天下午就让 wiki 运行起来，并且更愿意讨论内容而不是结构，请选择 BookStack。它涉及的组件最少：一个 PHP 应用和一个 MySQL 数据库。它适合内部运行手册和客户文档，也适合大多数撰稿人不是工程师的团队。三者中，它也是最容易备份的，因为完整状态就是一个数据库转储文件和 uploads 目录。

如果您需要其他方案不提供的特定编辑器或身份验证策略，或者要导入大量现有 Markdown 或 AsciiDoc，并希望保留路径结构，请选择 Wiki.js。您需要接受它运行的是更重的技术栈，并固定 major version 标签。

如果写作质量最重要，wiki 面向团队而不是公众，并且您已经有身份提供商，请选择 Outline。这样的配置可以提供真正易于使用的编辑器。不要将它作为您首个自托管应用。

如果这三个方案都不适合，通常是因为内容类型不匹配。扫描的发票和合同应放在Paperless-ngx 等文档管理系统中，而不是 wiki 中；强行将这类内容放入 wiki，正是许多 wiki 最终无人维护的原因。另一个常见的不匹配是，您需要的其实是工作区而不是 wiki：文档、表格和白板位于同一个画布中。这种情况下，自托管 AFFiNE 工作区比上面的三个方案都更合适。若要了解还有哪些应用值得部署在自己的服务器上，请参阅2026 年自托管应用候选清单。

容量规划与备份

这三种方案都能运行在小型 VPS 上，但实际所需的最低配置取决于各自依赖的组件。BookStack 由一个应用进程和 MySQL 组成。Wiki.js 由一个 Node 进程和 PostgreSQL 组成。Outline 由一个 Node 进程、PostgreSQL 和 Redis 组成，通常还需要配合身份提供商，因此应为它分配更多内存。

同时备份数据库和上传文件，并在依赖该备份之前，先将两者恢复到一次性实例中进行验证。没有经过恢复验证的 wiki 备份只能算是推测。对于 BookStack，这意味着 mysqldump 以及 /config 卷。对于 Wiki.js 和 Outline，这意味着 pg_dump 以及数据卷；对于 Outline，还包括 FILE_STORAGE_LOCAL_ROOT_DIR 中的内容。

FAQ

哪个自托管 Wiki 最容易安装？

BookStack。它是一个单独的 PHP 应用，使用 MySQL 数据库。该项目为 Ubuntu 24.04 提供安装脚本，可一次性配置 Apache、MySQL 8.0 和 PHP 8.3。容器镜像只需要 APP_KEY 和数据库凭据。Wiki.js 还需要 Node 运行时和 PostgreSQL 服务器，Outline 则在此基础上还需要 Redis 和外部身份提供商。

不使用 Google 或其他 SSO 提供商，可以使用 Outline 吗？

不可以。Outline 不提供本地用户名和密码登录。其示例配置明确要求至少配置一个第三方登录提供商，否则完全没有登录方式。您可以使用 Google、Slack、Microsoft Entra、Discord，或使用自托管的 Keycloak、Authentik 等通用 OpenID Connect 服务器。运行该身份提供商也是运行 Outline 的成本之一。

应该安装 Wiki.js 3 还是 Wiki.js 2？

Version 2。截至 2026 年 7 月，最新的 Version 2 版本是 2.5.314，于 2026 年 5 月发布。Version 3 文档明确说明它是不稳定的 beta 版本，不应在生产环境中安装。请将镜像固定为 ghcr.io/requarks/wiki:2，而不是 latest，因为主版本变更会修改运行中实例的数据库架构。

哪个的搜索功能最好？

它们各有所长。BookStack 为读者提供查询语言，支持精确短语、[location=london] 等标签筛选器，以及 {created_after:2016-12-30} 等元数据筛选器；这些条件都可以通过前置 - 取反。Outline 无需配置，并且可以搜索已上传文件中的文本。Wiki.js 的可调节性最高，因为您可以选择搜索引擎；当 Wiki 超过几百个页面后，建议尽快切换到 PostgreSQL 引擎。

以后可以将内容从一个迁移到另一个吗？

可以部分迁移，但应预留手动处理的工作量。三者都支持导出和导入 Markdown，因此页面文本通常可以保留。结构无法完整保留：BookStack 的书籍和章节在 Outline 的嵌套文档中没有对应结构，Wiki.js 的路径也无法映射到 BookStack 的固定层级。附件、权限和页面历史最容易丢失，因此在确定迁移方案前，请先导出一部分内容并检查这些数据。