企业官网建设流程全解析

1. 项目概述：为什么要搭建团队 Wiki 而不是继续用文件夹传文档

先说点实际的。我相信每个稍微有点规模的团队都经历过同一个噩梦：新同事入职，光交接文档就翻了十几个文件夹，版本混乱、内容过期、代码示例和实际接口对不上。这不是人的问题，是工具的问题。传统网盘和聊天软件只能解决“存”的问题，解决不了“找”和“维护”的问题。知识是需要沉淀、索引和权限管理的，而这些正是 Wiki 系统的核心价值。

MM-Wiki 是一款基于 Go 语言开发的轻量级开源 Wiki 系统，主打私有化部署、Markdown 编辑、权限控制，同时内置了后台管理界面。整个系统由开源社区的开发者们共同维护，代码托管在代码托管平台上，采用相对宽松的开源许可，可以免费用于企业内部知识库搭建。它默认使用 SQLite 作为数据库存储，SQLite 在轻量级场景下性能表现不错，免去了单独维护数据库服务的负担；当然它也支持外部数据库，后面我会详细说。

这个工具适合谁来用？三类人：

• 中小型开发团队、技术部门，需要一个内部技术文档中心；
• 产品、运营、人事这些非技术部门，需要一个操作门槛低、支持可视化编辑的团队知识库；
• 个人开发者或者极客玩家，想自建一个轻量笔记系统，不想背着厚重的 Electron 应用到处跑。

我前后帮三家公司搭过 Wiki 系统，用过不少同类产品。先说一个结论：如果你的核心诉求是“轻量、速度快、内网部署、不折腾”，MM-Wiki 基本就是最优解。它整个安装包只有几十兆，跑起来占用内存不到 100MB，一个最低配的 1 核 1G 云服务器就能轻松带起来。对比那些动不动就要 4G 内存起步的商业 Wiki 产品，这个资源占用几乎可以忽略不计。

下面我把完整的搭建过程、踩坑记录和使用心得一次讲清楚，照着操作，半小时内你也能拥有一个自己的团队知识库。

2. 安装前的思路拆解：一步到位做对选择，少走弯路

2.1 为什么选择 MM-Wiki 而不是其他 Wiki 工具

在选型这件事上，我很有发言权。当时其他几个团队见到我们搭好 MM-Wiki 后也来问方案，我总结了市面上主流的开源 Wiki 工具的实际情况。某系统确实功能强大，生态也成熟，但它是基于 Java 系技术栈的，环境要求较高，对服务器配置有一定要求，带来的问题是资源占用和运维成本在中小团队里根本划不来。另一个系统偏重个人笔记场景，权限体系不如 MM-Wiki 完善，多人协作时不方便分配空间权限。

当时也有同事提议直接用带数据库的在线协作文档产品，说 word 编辑习惯不用改，连内网都能打通，云盘也支持团队空间。但云服务在数据可控性上终究隔了一层，而且按人头订阅的license费用对团队来说也是一笔不小的开支。

综合下来，MM-Wiki 恰好踩在了所有关键需求点上：

• 纯二进制发布，无运行时依赖，复制到任意目录就能跑；
• 支持多空间隔离，不同部门的知识可以互相独立管理；
• 权限粒度够用，系统管理员、空间管理员、读写、只读层级清晰；
• Markdown 编辑器带即时预览，对技术团队极其友好；
• 内置用户管理和注册审批，不需要对外部系统有过多依赖。

2.2 部署形态选择：内网私有化是核心前提

部署之前，一定要先想清楚你的 Wiki 是给谁用的、部署在什么网络环境下。我帮第二家公司搭的时候，他们的需求是全员都能访问，包括分公司没有内网权限的员工。当时方案就变成了“公网服务器部署 + 域名绑定 + 注册审批”，这样既可以对外提供访问，又通过审批机制挡住非授权用户。

但对多数团队来说，我还是推荐内网服务器部署。知识库里的内容往往涉及内部项目细节、账号信息、接口文档，暴露在公网上多少有点风险。内网部署还有一个好处：速度快。内网环境下页面几乎是秒开，体验差距非常明显。

如果你所在企业已经有内网穿透或远程办公的方案，做好访问控制后部署在公网也可以。需要强调的是，一定要关闭开放注册或开启邮箱验证去重，否则很容易出现垃圾账号。这个细节我在后面权限管理的章节里详讲。

3. 环境准备与下载安装：从零到跑通的完整实录

3.1 环境要求与推荐配置

先看一眼这台服务器的最低需求。因为我手头正好有一台临时用的小机器，就拿它做了演示：

• 操作系统：Ubuntu 20.04（CentOS 7/8、Debian 10/11 也都兼容）
• CPU：1 核（足够）
• 内存：1GB（实际运行占用约 60~80MB）
• 磁盘：10GB（纯粹放程序和数据的话，2GB 都够）
• 数据库：默认 SQLite（零配置）；如果日活超过 200 人，建议上外部数据库

为什么 Go 语言写的程序能做到这么省资源？这里简单说一点原理。Go 编译出来的是纯机器码，运行时不需要依赖虚拟机或者解释器，内存管理、垃圾回收都是 Go 运行时自带的，所以单个二进制文件就包含了所有功能。对部署者来说，最大的好处就是一个mm-wiki主体程序文件 + 一个配置 + 一个数据目录就能跑起整个服务。

3.2 下载安装包与目录规划

MM-Wiki 的安装包可以在它的代码托管仓库 Release 页面找到，选对应操作系统和架构的压缩包即可。通常文件名类似mm-wiki-linux-amd64.tar.gz。下载完先别急着解压，我先规划一下目录结构，这是第一次部署时容易忽略的事。

我的目录规划习惯是这样的：

/opt/mm-wiki ├── conf │ └── mm-wiki.conf # 主配置文件 ├── data │ ├── mm-wiki.db # SQLite 数据库文件 │ ├── logs # 运行日志目录 │ └── files # 附件上传目录 ├── mm-wiki # 主程序二进制 ├── static # 静态资源（内嵌在二进制里，也可自行覆盖） └── templates # 模板文件（内嵌，一般不需要动）

这种规划的好处是：升级时只需要替换mm-wiki主程序，conf、data目录保持不动，配置和数据都不会丢失。我见过有人把所有文件解压到 root 目录然后整个目录当附件一顿乱传，后期升级和备份时直接崩溃。

下载并解压的命令如下：

cd /opt wget https://github.com/.../mm-wiki-linux-amd64.tar.gz tar -zxvf mm-wiki-linux-amd64.tar.gz mv mm-wiki-linux-amd64 mm-wiki cd mm-wiki chmod +x mm-wiki

注意，wget的下载地址以官方 Release 页面实际为准，我这里省略了详细路径，大家在页面里找到对应的.tar.gz文件复制链接即可。

3.3 配置文件详解：端口、数据库、日志一个都不能少

解压后先别急着启动，conf目录下会有一个mm-wiki.conf示例文件，复制成真正生效的文件再改：

cp conf/mm-wiki.conf.example conf/mm-wiki.conf

下面是核心配置项的解释，我把自己日常使用的配置贴出来，每个字段都标注了作用：

# 服务监听地址，0.0.0.0 表示监听所有网卡，内外网都可访问 http_ip=0.0.0.0 # 服务端口，按团队习惯选一个不冲突的即可 http_port=8090 # 站点名称，显示在浏览器标签页和登录页标题上 app_name=团队知识库 # 数据目录，存放数据库文件、附件、日志 data_dir=./data # 默认数据库驱动，支持 sqlite，也支持外部数据库 db_driver=sqlite # sqlite 数据文件路径 db_db_file=./data/mm-wiki.db # 日志级别，开发时 debug，生产环境 info log_level=info # 秘密密钥，用于 session 加密，建议改成随机的长字符串 http_key=请改成一段足够长的随机字符串

data_dir就是刚才规划的./data目录，程序启动时会自动创建，不用手动 mkdir。http_key这个字段很多人会忽略，它关系着登录 session 的加密强度，如果保持默认值，别人拿到配置就能伪造登录态。我习惯用openssl rand -hex 32生成一段随机值填进去。

3.4 初始化安装与创建管理员账号

第一次启动时有三种方式：直接执行二进制、用nohup挂后台、或者写 systemd 服务。为了后续好维护，我建议直接上 systemd，这是 Linux 下的标准服务管理方式，可以设置开机自启、自动重启、日志管理，省去很多手工操作。

vim /etc/systemd/system/mm-wiki.service

写入以下内容：

[Unit] Description=MM-Wiki Service After=network.target [Service] Type=simple WorkingDirectory=/opt/mm-wiki ExecStart=/opt/mm-wiki/mm-wiki --conf conf/mm-wiki.conf Restart=on-failure RestartSec=5s [Install] WantedBy=multi-user.target

然后执行：

systemctl daemon-reload systemctl start mm-wiki systemctl enable mm-wiki

启动后先确认一下状态：

systemctl status mm-wiki

看到active (running)就说明服务已经起来了。第一次通过浏览器访问http://服务器IP:8090时，会进入一个初始化引导页，要求设置管理员账号和密码。这里提醒一句：管理员账号和普通成员账号要分开管理，密码别用公司统一弱口令，这个账号能管理所有空间和用户，权限级别是最高的。

初始化之后，系统会默认创建一个名为“系统管理”的空间，并引导你创建第一个页面。到这里，一个空壳 Wiki 就已经跑起来了。

4. 核心功能使用心得与常见问题排查：真正能提效的细节都在这里

4.1 空间、权限与人员管理的正确打开方式

MM-Wiki 的权限模型以“空间”为核心。一个空间就是一个知识库，可以对应一个部门或者一个项目。每个空间可以独立设置访问权限和成员角色。我强烈建议第一批空间不要贪多，按实际业务线先建三四个，跑顺了再扩展。

权限层级从高到低是：

一个容易踩坑的地方：文档里写的“所有成员可见”并不等于“所有登录用户可见”。如果你不想让非空间成员的同事在全局搜索里看到某个空间的页面，一定要在空间设置里把“允许非成员浏览”关掉。之前有同事把薪酬制度模板放在共享空间里忘了关浏览权限，导致全员都能在搜索结果里看到标题名称，场面一度非常尴尬。

另外，用户注册这块建议开启“人工审批”。在“系统管理 → 用户管理 → 注册配置”里改成管理员审核制，新用户注册后需要管理员在后台激活才能登录。这个功能在公网部署时尤其重要，可以挡住绝大多数垃圾注册。

4.2 Markdown 编辑与页面管理：从空白页到体系化文档

MM-Wiki 的编辑器同时支持 Markdown 源文本和可视化编辑，顶部工具栏把常用格式都做成了按钮，非技术背景的同事也能上手。工具栏里最有用的三个功能是：附件上传、代码块插入、表格插入。

附件上传会默认存入data/files目录，支持图片、压缩包、PDF 等格式，插入图片时会自动生成页面内引用路径。代码块支持多种语言高亮，写技术文档时体验接近专业编辑器。

页面之间支持层级结构，类似文件夹嵌套。这个功能我强烈建议用起来：先按部门建一个“根页面”，然后在其下创建子页面，归纳具体模块。比如：

• 某业务系统
  • 需求文档
  • 技术设计
    • 数据库设计
    • 接口文档
  • 运维手册

页面命名要短、语义化，因为系统内的自动生成链接是用页面名拼出来的，命名太随意会导致后期链接变得很长且难以维护。比如财务报销流程就比报销那些事儿更能让人一眼看懂。

4.3 常见安装配置问题排查：这五个问题出现概率最高

我在给不同环境部署时，几乎每次都会遇到下面几个问题，逐个记下来供参考。

问题一：启动报address already in use

端口被占用。优先换一个端口，或者找出占用进程：

lsof -i :8090 kill -9 进程PID

换端口时改http_port然后重启服务即可。

问题二：页面能打开但静态资源（CSS/JS）加载不出来

大概率是http_ip配成了127.0.0.1，而浏览器是通过内网 IP 访问的，静态资源请求全部落到本机回环地址，自然加载不到。生产环境改成0.0.0.0或者填具体网卡 IP。

问题三：附件上传一直失败，看日志发现磁盘满了

这是磁盘配额的问题。MM-Wiki 上传附件不会限制单文件大小，但底层写入失败就是磁盘满了。事先规划好data目录所在分区的空间，建议至少 20GB。大附件可以通过外链形式引用，减轻服务器压力。

问题四：忘记管理员密码

直接操作数据库重置，SQLite 场景下用命令行操作：

sqlite3 data/mm-wiki.db UPDATE user SET password = '新密码的哈希值' WHERE user_id = 1;

具体哈希算法和字段名以当前版本为依据，如果不熟悉数据库操作，最稳妥的方式是直接删除数据库文件重新初始化一次——但这会把所有页面清空，实在没办法才用。

问题五：日志里出现大量dial tcp: i/o timeout

如果配置了外部数据库，这表示数据库连接不稳定。检查网络连通性和数据库的max_connections配置，同时确认连接串的字符编码和时区设置是正确的。

4.4 数据备份与迁移：别等服务器挂了才想起来

很多团队在跑 Wiki 时最容易忽略的就是备份。我自己吃过亏：帮一个团队搭好后，三个月的文档因为一块系统盘损坏全部丢失，当时还没有任何备份策略。从那以后，凡是经我手部署的 Wiki，备份方案我一定会同步落实。

备份只需要考虑三个目录/文件：data/mm-wiki.db（数据库）、data/files（附件）、conf/mm-wiki.conf（配置）。一个简单的定时任务脚本：

#!/bin/bash BACKUP_DIR=/backup/mm-wiki DATE=$(date +%Y%m%d%H%M) mkdir -p $BACKUP_DIR cp /opt/mm-wiki/data/mm-wiki.db $BACKUP_DIR/mm-wiki-$DATE.db cp -r /opt/mm-wiki/data/files $BACKUP_DIR/files-$DATE cp /opt/mm-wiki/conf/mm-wiki.conf $BACKUP_DIR/mm-wiki.conf-$DATE # 可选：删除 7 天前的备份 find $BACKUP_DIR -type f -mtime +7 -exec rm -f {} \;

加入 crontab，每天凌晨执行一次：

0 3 * * * /root/backup_mm-wiki.sh

恢复时，只需要把备份文件复制回原目录、修正权限、重启服务即可。因为整个系统就没有外部依赖，迁移到新服务器非常轻松——装好程序，把data和conf目录原样拷过去，启动就是完整的新环境。

5. 从“能用”到“好用”：二次定制与体验优化

5.1 自定义域名与反向代理配置

如果只是内网访问，直接用 IP 加端口也够用，但为了后续接入企业邮箱登录或者对外提供服务，我建议配置一个域名，并加一层 Nginx 反向代理。这样做的好处是：统一走 80/443 端口，可以不对外暴露 8090，还能由 Nginx 统一管理与证书加密。

Nginx 配置节选：

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

需要注意修改配置后要执行nginx -t检查语法，然后重启 Nginx。代理后如果上传大附件出现超时，还要在location里调大proxy_read_timeout和client_max_body_size。

5.2 页面模板与 CSS 小改：让知识库更像公司内部系统

MM-Wiki 页面结构是固定的，但可以通过自定义 CSS 做一些轻量美化。这套系统本身自带管理后台，很贴心地提供了自定义 CSS 和 JS 的入口，你可以在后台的“系统设置”里加入少量自定义样式，比如调整顶部导航颜色、隐藏默认的“XX 技术”字样等，不用改代码就能有品牌感。注意改之前备份原始样式，避免版本升级后样式失效。

5.3 信息架构设计：从 Wiki 到团队知识中台的演进

搭好之后，维护才是真正的工作。我个人的体会是：一个 Wiki 能否长期活下来，关键不是功能多还是少，而是有没有人持续更新它、有没有一套组织内容的规则。建议团队里设一个文档负责人，每周定期巡检过期内容，老旧文档打上“需更新”标签，废弃的页面直接删除或归档。嵌入业务核心流程的文档，比如接口文档、发布流程、故障排查手册，要和实际操作强绑定——每次改代码就顺手更新文档，这样 Wiki 的信息才有可信度。

团队用好一段之后，可以把日常高频问题沉淀成 FAQ 页面、把新人入职手册做成必读清单、把项目复盘做成模板。做到这一步，MM-Wiki 就不再是一个简单的工具，而成了团队的知识中枢，新的成员进来翻一翻历史文档，很多问题都能自己解决，重复答疑的成本能省下不少。

6. 使用经验总结：这套系统稳定的秘密，以及我踩过最深的一个坑

最后聊一点实在的体会。

MM-Wiki 的稳定性，我实测下来相当不错。它用 Go 语言编写，运行时很少崩溃、启动也很快，性能好，资源占用少，可以说是整套方案里最让人放心的一环。但有一个坑我必须单独说一下——升级的时候千万别直接覆盖数据库文件。

有次我图省事，直接用线上版本替换了新版本二进制，没有备份数据库。结果新版本启动后用旧数据打开页面，编辑器报了个数据格式错误，整个知识库的页面打不开了。当时修复花了整整一下午，最后只能从备份里恢复部分数据。所以强烈建议：升级前务必备份data目录并滚动更新，先在一台测试机上验证数据兼容性，再动线上的数据库文件。

另一个体会是关于容量规划的。很多团队一开始觉得数据量不大，随便跑跑就行，半年后发现附件目录接近 30GB，磁盘告急才开始处理。建议第一天就在监控里加上磁盘空间告警，同时定期清理历史附件，对超过 100MB 的单个文件引导大家用对象存储或者网盘，而不是直接塞进 Wiki。

如果你也想在公司内部搭一套知识库，不要犹豫，直接按这篇文章的步骤走一遍。半小时能跑通的事，花上一整天反复研究反而没有意义。等真正用起来，你就会发现团队的新人上手速度快了不少，重复说明的对话少了很多，沉淀下来的积累，才是这个时代团队真正宝贵的东西。

按照我的经验，一个轻量工具的核心价值不在于功能列表有多长，而在于它能否持续被使用、能否真正沉淀知识。MM-Wiki 恰好把这件事做得恰到好处——简单、可控、稳定，值得一试。