再看起因，为什么要自己造轮子

若不是我们的运维同事要离职而且交接的东西非常零散。我都真不想自己造这个“轮子”。过往同事们的交接都是用 SVN归档 + 文档指引来完成的。这样做并没有什么大问题，只是用起来不太好用而已。譬如要查个东西，你要先知道他存在哪里接下来再看内容在哪里...坦白说有点费时费力。

况且有的时候交接完了也不会马上全部“烂熟于心”。等有紧急情况才挖出来看的，这个时候真的抓马。这个时候要是有个能够在线统一归档、查看的知识库就好了。

使用者痛点

• Confluence 太重Java 跑起来内存先吃掉 2G，资源不够根本扛不住；按理说，功能复杂且多数未使用，造成资源浪费。
• 部署麻烦MediaWiki 或 Wiki.js 需要数据库、Node 版本、反代配置，折腾半天才能跑起来。说起来，
• 数据安全隐患大部分 Wiki 程序数据库内容明文。运维文档中常含服务器 IP、密码规则、内部拓扑等敏感信息；若数据库文件被拖走，信息直接泄露。
• 权限控制粗粒多数程序只有「管理员 / 普通使用者」二元权限，无法实现「这篇文章只有张三和李四能看」这样的细粒度分享。

从技术选型来看，为什么是 Flask + 原生 JS

从后端来看。Flask + SQLAlchemy + SQLite

选 Flask 的理由很简单：够用，且部署成本为零。

整个应用就一个 app.py 入口，pip install 装完依赖直接跑。不需要 Nginx、不需要 WSGI 配置、不需要数据库迁移脚本——db.create_all 一行搞定。

SQLite 确实有并发写的争议。但内部知识库的写入频率极低，WAL 模式足够应付。说起来，真到了并发瓶颈的时候，把连接字符串换成 PostgreSQL 就行。这就是我用 SQLAlchemy 的理由。

前端这方面，Vanilla JS。零建立步骤

我必须承认，我前端是渣渣。按理说，

本人前端技术大概停留在 年前吧。为了让自己也能够看懂，不做 SPA 路由、不做虚拟 DOM、不上 Webpack。所有 UI 逻辑散在几个 JS 文件里页面只有一个 index.html。而且零建立代表着：改一行 JS 直接刷新浏览器就能看到效果 、没有 HMR 抽风、没有 黑洞。说实在的，这挺好，

加密方案这方面，拿了你也看不到

设计目标 说到简单说就一条。 wiki.sqlite 文件，他也读不懂任何一篇文章的内容 < / strong>。按理说，很多团队觉得「反正是内网部署，加密没必要」。但现实是——服务器被攻破、 备份文件泄露、 离职员工带数据走，这些事发生的时候你根本来不及处理。 < / p> < / div> < div class = "highlight"> < pre tabindex = "0"> < code class = "language-plain" lang = "plain"> . 使用者注册 → 服务端自动生成 RSA- 密钥对 . 创建 article → 随机生成 AES- 密钥 → AES-GCM 加密内容 → RSA 公钥加密 AES 密钥 . 存储到数据库 → encrypted_content + encrypted_key （加密后的 AES 密钥） . 读取 article → RSA 私钥解密 AES 密钥 → AES- aes_key = AESGCM.generate_key aesgcm = AESGCM nonce = os.urandom ciphertext = aesgcm.encrypt,None) encrypted_content = base64.b64encode.decode pubkey = serialization.load_pem_public_key) encrypted_key = pubkey.encrypt)。algorithm=hashes.SHA256,label=None,),) return encrypted_content,base64.b64encode.decode python def encrypt_content -> tuple: aes_key = AESGCM.generate_key aesgcm = AESGCM nonce = os.urandom ciphertext = aesgcm.encrypt(nonce,javascript const SNAP_THRESHOLD = sql --权限模型User(id,email,rsa_public_key,rsa_private_key,...)Node(id,parent_id,title,content,owner_id,encrypted_key,...)NodePermission(node_id,grantor_id,grantee_id,is_active) Ctrl+Click多选节点，接下来批量授权或撤销。还有个有意思的场景——**权限转让**。比如原来的文档负责人离职了 需要把所有权转给别人： 1. 选中节点→右键→权限转让→选择新所有者；程序用旧所有者的私钥解密所有子节点的AES密钥；2. 用新所有者的公钥重新加密；3. 更新`owner_id` 每个节点独立重新加密。说起来，处理时间大概几秒钟，对体验影响不大。不过，

一些不完美的地方

前端没有做路由

所有页面状态靠JS变量维护。刷新页面就回到初始状态，虽然SPA本来就是这样，但没有URL状态代表着你没法复制一个链接发给同事说「你看这篇文档」。这是未来需要加的功能——至少把?node_id=映射到对应的文档打开状态。

密钥存在服务端

前面说过。这是安全性和便利性的权衡。怎么说呢，如果引入客户端加密，分享功能会复杂很多——需要客户端交换公钥。目前这个方案对内部团队来说够用。但如果要开放公网注册，这个设计需要重新评估。

SQLite 的并发天花板

虽然内部 Wiki 不太可能触发SQLite 的并发瓶颈。但如果一个团队有几百人同时编辑，确实会出现写锁冲突。好在换成PostgreSQL只需要改一行配置：

python# config.pySQLALCHEMY_DATABASE_URI ='postgresql://user:pass@localhost/wiki'

ORM层完全不用动。

没有做 i18n

目前所有UI文本、 错误提示都是硬编码中文。如果有国际化需求，需要重构一遍。问题，

从部署来看，比冲一杯咖啡还快

我故意把部署成本压到了最低：

bashpip install -r requirements.txtpython app.py

就是这两步。默认监听 0.0.0.0:5000，浏览器打开就能用。

第一个注册的使用者自动成为管理员。之后任何人注册都需要管理员在后台审批——避免匿名使用者往你的Wiki里灌垃圾内容。话说回来，

生产环境挂gunicorn：

bashgunicorn -w 4 -b .:5000 app:create_app

邮件通知是可选的。配了SMTP就用，不配也不影响主要功能。

再看最终，适合谁用

Ops Wiki不是要替代Confluence或Notion。它解决的是一个很具体的场景：

「我们只是想要一个轻量级、 可私有化部署、 内容可加碰撞防泄漏、 且支持按需精细共享 的运维知识库。」

如果你符合这个场景，拿去 用吧。体验」，其实，

从项目地址来看。gitee.com/yzh0623/ops…