MediaWiki 扩展推荐：我的个人知识库是怎么搭起来的

搭 MediaWiki 这件事，门槛其实不低。

装好 MediaWiki 本身只是个起点。原生的可读性一般，编辑器上手有成本，数据管理基本靠手写模板，高级功能一个没有。我自己用了三个月才明白一件事：MediaWiki 的上限在哪里，取决于你装了哪些扩展。

本文适配 MediaWiki 1.46（以及向下兼容 1.41 以上版本）。扩展分支和版本号尽量对齐官方最新稳定版，遇到需要 composer 安装的会单独说明。

这篇文章把我这些年实际用过的扩展整理了一遍。不追求全，只追求有用。按用途分成几个类别，重点是知识管理相关的扩展——那是让 Wiki 从”放文章的文件夹”变成”活的个人知识库”的关键。

编辑体验：先把写作门槛降下来

VisualEditor：不用学 WikiText 也能写

原生 MediaWiki 用的是 WikiText 标记语言，星号是列表、双括号是链接、中括号语法一堆，新用户上手不容易。

VisualEditor 把这个门槛拆了。它是一个基于 Parsoid 的可视化编辑器，界面和 Google Docs 类似，选中文字就能加粗、插链接、插入表格，不用记任何标记。

# 安装（以 MediaWiki 1.46 为例）
cd extensions
# VisualEditor 本体
git clone -b REL1_41 https://gerrit.wikimedia.org/r/mediawiki/extensions/VisualEditor.git
# Parsoid 解析服务
wget https://github.com/wikimedia/parsoid/releases/download/v0.12.0/parsoid.tar.gz
tar -xzf parsoid.tar.gz

// LocalSettings.php 配置
wfLoadExtension( 'VisualEditor' );
$wgDefaultUserOptions['visualeditor-enable'] = 1;
$wgHiddenPrefs[] = 'visualeditor-enable';

// Parsoid 服务地址（需单独启动）
$wgVisualEditorConfig['restbaseURL'] = 'http://localhost:8000';

Parsoid 需要单独部署，用 node server.js 启动，默认监听 8000 端口。

我后来把它设成了默认编辑器，新用户进来不用培训就能直接写东西。降低协作门槛的效果很明显。

一个现实问题：如果在内网环境或者资源有限的服务上跑，Parsoid 的额外运维成本要考虑。如果 Wiki 只有你自己用，或者两三个人用，WikiEditor 其实也够了。

WikiEditor / CodeEditor：WikiText 用户的增强工具

如果团队里有人熟悉 WikiText，WikiEditor 是个不错的增强。它在原生编辑器上加了工具栏，可以快速插入模板、表格、分类，不需要记快捷键。

CodeEditor 则给代码块加了语法高亮，支持数十种语言，同时保留 WikiText 的编辑能力。

wfLoadExtension( 'WikiEditor' );
$wgWikiEditorFeatures = [
    'toolbar' => true,
    'preview' => true,
    'publish' => true,
];

先用 VisualEditor，如果团队里 WikiText 玩家多，再装 WikiEditor 当辅助。两个都装不冲突。

知识管理：让 Wiki 真正成为知识库

这是重点。原生的内容管理能力比较基础——有一堆文章，互相之间靠手写链接关联，分类靠标签，没有结构化查询能力。

装上下面这几个之后，整个 Wiki 的性质就变了。

Cargo：轻量级语义数据存储

Cargo 是我在个人 Wiki 里用得最多的一个扩展，没有之一。

它做的事情很简单：让你在模板里埋数据字段，这些字段自动存入数据库表，可以被查询、被筛选、被展示。

举个例子。我有一堆读书笔记，每篇笔记的结构差不多：书名、作者、阅读日期、评分、个人评价。以前这些东西散在正文里，想找”所有评分 8 分以上的书”只能靠记忆。

装了 Cargo 之后，读书笔记模板加几行声明：

{{#cargo_store:
 table = books
 | BookName = {{{BookName|}}}
 | Author = {{{Author|}}}
 | Rating = {{{Rating|}}}
 | ReadDate = {{{ReadDate|}}}
}}

然后就可以直接调出所有高分书籍：

{{#cargo_query:
 table = books
 | fields = BookName, Author, Rating
 | where = Rating >= 8
 | order by = Rating DESC
}}

查询结果在任意页面展示，自动更新，不用手动维护。

Cargo 比 Semantic MediaWiki 简单很多，没有复杂的属性声明，不需要建整个 schema，上手门槛低很多。适合那种”我想给文章加结构，但不想花太多时间配置”的场景。

我自己的 Wiki 里几乎所有内容类型都用了 Cargo：读书笔记、工具评测、游戏攻略、项目记录。每加一种新类型，大概花半小时写模板和表单，后续录入和维护效率提升非常明显。

Semantic MediaWiki：重型的知识图谱引擎

和 Cargo 定位有重叠，但 Semantic MediaWiki（SMW）的能力要深得多。

SMW 把整个 Wiki 变成知识图谱引擎。每个页面可以有语义属性——带类型的、可推理的数据，不只是文本字段。可以声明”这部电影的导演是[[导演::张三]]“，系统自动知道张三这个属性指向一个页面，类型是人物，可以用来做关联查询。

[[导演::张三]]
[[上映年份::2024]]
[[类型::科幻]]

然后就可以问：“找出所有张三导演的科幻片”，或者”哪些页面引用了这部电影”。这已经是关系型知识图谱的范畴了。

SMW 的问题是配置门槛高。属性声明、类型定义、查询语言都需要学习成本，维护一个 SMW 驱动的 Wiki 要花时间理解和维护 schema。

适合高度关联的、结构化的知识，比如人物关系、时间线、学科概念网络。不适合：只是想给文章加几个分类字段，用 Cargo 就够了。

Cargo 和 SMW 不要一起装。两者在底层数据存储上有冲突，官方建议二选一。我的建议是从 Cargo 开始，体验语义化存储能做什么，等 Cargo 明显不够用的时候再迁移到 SMW。

PageForms：表单驱动的内容录入

Cargo 和 SMW 的黄金搭档。

PageForms 让你能为每种内容类型创建专门的录入表单，用户填写表单，系统自动生成带 Cargo 字段的页面，不用手动写模板语法。

装了它之后，我的读书笔记录入流程变成了：点”新建读书笔记”，填写表单（书名、作者、评分、日期、感想），自动生成排好版的页面，字段直接存入数据库。全程不需要接触任何 WikiText。

wfLoadExtension( 'PageForms' );

# 表单定义写在 Wiki 页面上，用表单定义页（Form:xxx）

表单定义写在 Wiki 页面上，用一种相对直观的语法，不需要写代码。普通用户经过简单培训也能创建新表单。

强烈建议把 Cargo + PageForms 作为一个组合来装。这是让 MediaWiki 从”技术人员的工具”变成”任何人都能用”的关键一步。

Semantic BreadcrumbLinks：语义导航

这个扩展比较小众，但在我自己的 Wiki 里用得很舒服。

它根据页面的语义属性自动生成面包屑导航，而不只是靠 URL 结构生成。在知识库场景里，语义导航比传统分类导航直观得多——你知道自己在整个知识网络里处于哪个位置。

配合 Cargo 或 SMW 使用效果最好，单独装价值有限。

内容可读性：让人愿意读

Cite：脚注与参考文献

原生 MediaWiki 支持脚注，Cite 扩展把它做得更完善，支持重复引用、同页参考文献列表、引用编号自动排序。

wfLoadExtension( 'Cite' );

用法是在正文里加 <ref>引用内容</ref>，在页面底部加 <references /> 渲染参考文献列表。适合需要严谨引用的知识库内容，比如读书笔记、项目文档。

SimpleMathJax：数学公式渲染

如果 Wiki 要放理工科内容，数学公式是刚需。SimpleMathJax 用 MathJax 渲染 LaTeX 公式，比传统 <math> 标签的输出好看得多。

wfLoadExtension( 'SimpleMathJax' );

支持行内公式（$...$）和独立公式块（$$...$$），渲染效果和 LaTeX 文档一致。我自己偶尔放点博弈论和概率的内容，这个是必需品。

FancyBoxThumbs：图片灯箱

点击图片直接在页面弹出灯箱，而不是跳转到图片页面，体验好很多。

wfLoadExtension( 'FancyBoxThumbs' );

装上就行，几乎零配置。我见过太多 Wiki 放截图，点开跳出一个只有图片的空白页，用户体验直接断掉。

安全与维护：挡住垃圾，守住数据

ConfirmEdit：验证码

开放注册的 Wiki 基本都会被机器人盯上。ConfirmEdit 是官方提供的验证码解决方案，支持多种验证方式：SimpleCaptcha（默认）、ReCaptcha（Google）、QuestyCaptcha（自定义问答）。

wfLoadExtension( 'ConfirmEdit' );
$wgCaptchaClass = 'SimpleCaptcha';

内网 Wiki，SimpleCaptcha 够用。对外开放的话，建议用 ReCaptcha，或者自定义几个只有真人能答上的问题（比如”中国首都在哪里”），问答验证对中文环境来说效果不错，用户体验也比图形验证码好。

SpamRegex + AbuseFilter：反垃圾规则

ConfirmEdit 挡住机器注册，但拦不住真人注册后发垃圾内容。SpamRegex 用正则表达式屏蔽包含特定内容的编辑，比如明显的广告链接。

wfLoadExtension( 'SpamRegex' );
$wgSpamRegex = '/\b(spam word|advertisement|buy now)\b/i';

AbuseFilter 更强大，可以定义复杂规则检测可疑编辑行为：同一账号短时间内大量创建页面、新账号创建页面长度极短包含外链等。一旦匹配，自动拦截或标记待审核。

wfLoadExtension( 'AbuseFilter' );

对内容质量有要求的 Wiki，这两个基本是标配。

Nuke：批量删除页面

垃圾内容一旦进来，一页页删太慢了。Nuke 允许管理员从 Special 页面批量删除指定用户创建的页面，或者按页面大小、链接数量等条件筛选后批量删除。

wfLoadExtension( 'Nuke' );

装了这个之后，清理一次垃圾内容从半小时缩短到两分钟。

互动与社区：让 Wiki 活起来

Comments：页面级评论

如果希望 Wiki 页面可以有讨论区，而不是都堆在讨论页，Comments 扩展提供了一种更轻量的方式。用户可以在文章底部发表评论，不需要进入原生的讨论页机制。

wfLoadExtension( 'Comments' );

评论可以按评分排序，有嵌入式评论和传统嵌套两种模式。面向读者的 Wiki 比较有用，比如教程站或者读书笔记站点。纯做知识沉淀不需要评论的话，跳过这个。

Vote / Poll：页面评分

有时候不需要完整评论系统，只需要知道读者对一篇文章的评价。Vote 给页面加一个五星评分，简单直接。

wfLoadExtension( 'Vote' );

我的读书笔记页面装了 Vote，每本书的评分直接显示在页面顶部。评分数据可以查询，帮助我快速定位哪些内容质量高、哪些需要回头重写。

组合推荐

说了这么多，实际推荐几套组合，按需求分。

个人知识库（最实用）

Cargo + PageForms + VisualEditor + Cite + FancyBoxThumbs。这五件套覆盖了结构化存储、便捷录入、可视化编辑、脚注引用和图片展示。安装工作量不大，维护成本低，对知识管理效率提升最明显。

小型团队协作

在上一个组合基础上加 ConfirmEdit + SpamRegex + AbuseFilter + Nuke。开放注册的话验证码必备，编辑审核规则按需调整，团队大了之后 AbuseFilter 能省很多人工审核的精力。

面向读者的内容站

加 Comments + Vote。如果 Wiki 的定位是发布内容而不是协作编辑，互动功能可以让读者多看几篇。

重度知识图谱

Cargo 换成 Semantic MediaWiki，再加上 Semantic BreadcrumbLinks。适合学科知识库、人物关系库这类需要强关联查询的场景。上限最高，下限也最低，配置和维护都需要投入。

最后说一句

扩展这个东西，装得多不如装得准。

见过有人装了二十多个扩展，Wiki 打开慢得要死，功能之间互相冲突，每次升级 MediaWiki 都要折腾兼容性。

我的原则是：没有明确需求不装扩展。每加一个扩展都意味着额外维护成本和潜在冲突风险。只装真正用到的，用透它。

Cargo 那个扩展我折腾了一个周末才配好表单定义，但装好之后录入效率提升十倍不止。这个时间投入是值得的。

先把核心功能配好，跑起来，看到瓶颈再按需扩展。比一开始就追求”全”要靠谱得多。