企业官网建设流程全解析

简介：这是一套旨在模仿百度百科的百科建站系统，核心目标是提供与百度百科相近的在线知识创建、编辑与查阅体验。资源面向需要搭建个人或团队知识库的站长、PHP开发者及百科类产品研究者，可解决从零开发百科系统时的选型、部署和内容管理难题。资源包为zip格式，大小约1.95MB，压缩包内文件总数为0，但从资源描述看，内容围绕hdwiki这一基于PHP的开源百科建站系统展开，并包含安装说明与document文档目录，涉及环境配置、数据库设置、Web服务器部署及二次开发资料。目前已有384人学习下载。通过这套资料，可掌握百科网站的词条分类、内容审核、用户权限管理等核心逻辑，借助HDWiki快速搭建具备搜索、浏览、贡献功能的互动知识平台。资料尤其适合希望快速上线百科类网站的团队，也适合作为PHP项目实战学习材料，能显著缩短建站周期。 去年下半年，我接到一个“百度百科系统”的开发需求：做一个内部知识库，产品同学的原话是“超级模仿百度”。我一开始以为这就是个常规的增删改查项目，真动手之后才发现，百科类网站最麻烦的地方根本不在 CRUD，而在“搜得准、看得顺、改不乱”。这篇文章把从 0 到 1 的实现思路和踩坑记录写下来，给正在做知识库、文档站、百科站的同学一个参考。

1. 先定义“模仿边界”：超级模仿百度到底模仿什么

“超级模仿百度”这个名字其实挺误导人的。如果把它理解成把百度首页、搜索框、明星热搜、左侧导航全部照搬一遍，那项目大概率会死。百度百科对用户的价值从来不是那套视觉界面，而是“任何一个词条，谁都能看、谁都能改、谁都能查到改动痕迹”这套产品逻辑。

所以我拿到需求后做的第一件事，不是画页面，而是把“百度百科系统”拆成了三个闭环：

• 搜索闭环：搜索框、联想词、结果列表、无结果引导；
• 内容闭环：词条创建、编辑、历史版本、一键回滚；
• 组织闭环：分类聚合、别名跳转、相关词条。

这样拆完，页面反而变简单了。真正花时间的是搜索词条命中的加权规则，以及历史版本怎么保存才算完整。界面上只要做到“远看像百科、用起来顺手”，项目目标就达了八成。

1.1 技术选型：先够用，再考虑架构弹性

我最终选的是一套非常常规的组合：

这套方案不是唯一答案。你用 Flask + Vue，或者 Node + React，核心逻辑都一样。重点是别在第一版就引入微服务、搜索引擎、消息队列这些重型组件。百科系统的瓶颈几乎永远在内容质量和数据关系上，不在并发量上。真要等到词条量过百万再上 Elasticsearch，那时候数据结构已经稳了，迁移成本反而可控。

2. 数据表先于页面：词条、历史、别名决定系统能走多远

百科系统里最核心的数据不是某个字段，而是“词条”这个概念。页面排版可以换，但表结构一旦设计错，后面改起来非常痛苦。

2.1 词条主表：别把所有属性都做成一列

我第一版设计词条表时，差点把“中文名”“外文名”“别称”“属性值”这些全做成字段。后来想明白一个道理：百度百科里每个分类的信息栏字段都不一样，动物有门纲目科属，软件有开发者、语言、平台。如果把属性做成固定列，系统第一周就会死。

我最终只保留了词条最通用的字段：

CREATE TABLE `entry` ( `id` BIGINT PRIMARY KEY AUTO_INCREMENT, `title` VARCHAR(100) NOT NULL, `title_key` VARCHAR(100) NOT NULL, `summary` VARCHAR(500) NOT NULL DEFAULT '', `content` MEDIUMTEXT, `status` TINYINT NOT NULL DEFAULT 0, `view_count` INT NOT NULL DEFAULT 0, `created_by` BIGINT NOT NULL, `updated_by` BIGINT, `extra_json` JSON, `created_at` DATETIME NOT NULL, `updated_at` DATETIME, UNIQUE KEY `uk_title_key` (`title_key`), KEY `idx_updated_at` (`updated_at`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

几个值得说的点：

• summary必须单独存。列表页、搜索摘要、关键词描述全都要用它，直接从正文里截取的话性能差，而且截出来往往不成句。
• title_key是唯一约束，不是title。大小写、空格、全半角符号统一处理之后再落这个字段，后面细说。
• extra_json用来存不同分类的自定义属性。比如“银杏”词条信息栏里的“拉丁学名”“科”“属”，都放 JSON，而不是建表。

2.2 编辑历史表：每条词条都要能“反悔”

百科类系统必须有历史版本，否则没有人敢编辑词条。需求里那句“超级模仿百度”，其实模仿得最用力的是这里：每个词条的每次修改都存快照，谁在什么时候改了什么，全部留痕。

CREATE TABLE `entry_history` ( `id` BIGINT PRIMARY KEY AUTO_INCREMENT, `entry_id` BIGINT NOT NULL, `version` INT NOT NULL, `content` MEDIUMTEXT NOT NULL, `editor_id` BIGINT NOT NULL, `edit_reason` VARCHAR(200) NOT NULL DEFAULT '', `created_at` DATETIME NOT NULL, UNIQUE KEY `uk_entry_version` (`entry_id`, `version`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

历史表只存“变了什么”，不存标题和分类这些元信息。这样词条页展示历史列表时，只需要按entry_id倒序查；回滚某个版本时，把对应content复制回主表，再插一条新历史，逻辑非常清晰。

2.3 别忽略别名表和分类关联

新用户搜索时经常不记得确切词条名，比如想查“西红柿”却搜“番茄”。如果每次都由运营去改词条标题，项目会被累死。我加了一张很薄的entry_alias表，字段就是alias和entry_id，搜索命不中标题时再查别名表。分类则用标准的category+entry_category多对多关联，一个词条可以同时归入“植物”和“传统食物”，页面端按分类聚合时才灵活。

3. 把“百科味”做出来的搜索与联想

百科系统的搜索和一般后台搜索不一样，它讲究的是一种“即时反馈感”：输入关键词，下面要出联想；回车之后，结果要尽量把最相关的词条放在最上面。这一块是最能体现“超级模仿百度”价值的地方。

3.1 第一版搜索：MySQL 全文索引就够了

不少教程上来就让你用LIKE '%关键字%'，词条少的时候没问题，一旦词条量上万，全表扫描速度立刻露馅。MySQL 8.0 自带的ngram全文索引分词器，处理中文搜索够用。

建索引：

ALTER TABLE entry ADD FULLTEXT INDEX ft_entry_title_summary (title, summary) WITH PARSER ngram;

搜索查询：

SELECT id, title, summary FROM entry WHERE status = 1 AND MATCH(title, summary) AGAINST (#{kw} IN NATURAL LANGUAGE MODE) ORDER BY view_count DESC LIMIT 20;

注意ngram默认的ngram_token_size是 2，也就是单个汉字搜不中，而且对“C++”“.NET”这类符号型关键词不友好。我实际处理的办法是：如果关键词长度 <= 2，或者带特殊符号，就走title LIKE兜底；正常中文词条走全文索引。

3.2 联想词和热搜榜：一个 Redis 就能搞定

用户在搜索框输入“Pyt”时，前端调用/api/wiki/suggest?keyword=Pyt，后端查词条标题前缀，再去匹配别名表：

SELECT e.id, e.title, e.summary FROM entry e LEFT JOIN entry_alias a ON a.entry_id = e.id WHERE e.status = 1 AND (e.title LIKE CONCAT(#{kw}, '%') OR a.alias LIKE CONCAT(#{kw}, '%')) ORDER BY e.view_count DESC LIMIT 8;

热搜榜不用单独建表，用 Redis 的 Sorted Set 记录搜索次数，每次搜索执行：

ZINCRBY hot:keywords 1 关键词

展示时：

ZREVRANGE hot:keywords 0 7 WITHSCORES

这一套方案的好处是代码量极小，效果却和百度百科的“大家都在搜”非常接近。前提是搜索关键词必须做去重和过滤，空字符串和超长垃圾关键词直接丢弃，不然三天后热榜就废了。

3.3 搜索结果排序：我用的是一段不太“高级”但好用的三段式查询

经验越多的用户，越看中“第一个结果是不是我要的词条”。所以我没一上来搞评分公式，而是用 UNION 把结果分成三档：

SELECT 10 AS score, id, title, summary FROM entry WHERE status = 1 AND title = #{kw} UNION ALL SELECT 5 AS score, id, title, summary FROM entry WHERE status = 1 AND title LIKE CONCAT(#{kw}, '%') AND title <> #{kw} UNION ALL SELECT 1 AS score, id, title, summary FROM entry WHERE status = 1 AND MATCH(title, summary) AGAINST (#{kw} IN NATURAL LANGUAGE MODE) AND title NOT LIKE CONCAT(#{kw}, '%') ORDER BY score DESC, view_count DESC LIMIT 20;

这一段逻辑很简单，但已经很接近真实百科的搜索体验：标题完全命中的永远排最前，前缀命中次之，正文模糊匹配靠后。等以后数据量大到需要个性化排序时，再换 Elasticsearch 也来得及。

4. 词条页和编辑器：先把内容写“干净”，再谈花哨

百度百科的编辑页是很多人不敢模仿的地方，因为它真的太复杂了：参考资料、角标、信息栏模板、目录导航、图片注释，每一个都是独立系统。

4.1 我放弃了“所见即所得”

第一版我尝试过 UEditor，结果发现保存进来的 HTML 非常脏，各种style、class、嵌套标签，版本对比时根本看不出来改了什么。后来我换成了 Markdown 存储，前端用编辑器 + 渲染器处理。

技术选型层面的取舍得说清楚：百科类内容的价值在于“长期维护”，Markdown 的纯文本本质决定了它在历史版本、差异对比、批量迁移这三件事上都比 HTML 省力得多。至于非技术用户不会 Markdown，我给编辑器加了一排按钮：加粗、标题、列表、图片，绝大多数人日常编辑根本不会手动写符号。

4.2 信息栏用键值对 JSON，而不是硬编码字段

前面提到的extra_json就是信息栏的数据来源，比如“银杏”词条：

{ "中文名": "银杏", "拉丁学名": "Ginkgo biloba L.", "植物界": "银杏门", "属": "银杏属" }

前端拿到这个对象后，渲染成两列的描述列表。不同分类想展示不同字段，只需要再存一个category_template，规定每个分类显示哪些 key 的排序。这样做的最大价值是：运营可以自己定义新分类，不用每次改表。

4.3 XSS 过滤这条，我不希望你踩了才看

用 Markdown 不等于绝对安全，因为渲染出来的 HTML 最终还是要插入页面。我在前端渲染时统一过了一遍 DOMPurify：

import { marked } from 'marked'; import DOMPurify from 'dompurify'; const html = DOMPurify.sanitize(marked.parse(content), { ALLOWED_TAGS: ['h1', 'h2', 'p', 'ul', 'ol', 'li', 'a', 'img', 'strong', 'em', 'pre', 'code', 'blockquote', 'table', 'thead', 'tbody', 'tr', 'th', 'td'], ALLOWED_ATTR: ['href', 'title', 'src', 'alt'] });

如果后台编辑允许直接提交 HTML，那后端必须再做一次过滤，Java 项目我用的 Jsoup 白名单机制。规则很简单：只放行常用标签，其余一律剥离。这步不做，等到有人往词条里塞一段恶意脚本，再回头找人麻烦就晚了。

5. 权限与历史版本：可编辑系统最怕“改完找不回”

百科类系统的“可编辑”是一把双刃剑。开放编辑会带来内容增长，也会带来误操作和垃圾信息。我在这个项目里把权限和历史版本的关系理成了三个原则，后面所有设计都是围绕它们来的。

5.1 编辑保存：先插历史，再更新主表

保存词条时，很多人会直接 UPDATE 主表，再插一条历史，顺序拿反之后，万一中间程序报错，内容就丢了。我的 Service 层是这样的伪代码：

@Transactional public void saveEntry(EditRequest dto) { Entry entry = entryMapper.selectByIdForUpdate(dto.getEntryId()); int newVersion = entry.getVersion() + 1; entryHistoryMapper.insert(EntryHistory.builder() .entryId(entry.getId()) .version(newVersion) .content(dto.getContent()) .editorId(CurrentUser.getId()) .editReason(dto.getEditReason()) .build()); entryMapper.updateContentVersion( entry.getId(), dto.getContent(), newVersion); }

注意版本号不是自增主键，而是从主表读出来加一，并用SELECT ... FOR UPDATE锁住当前词条，避免两个人同时编辑导致版本号重复。回滚操作也简单：找到要回滚的历史版本，拿它的内容再次走一遍保存流程，生成一个新版本。这样“回滚”本身也会留痕，不会出现历史记录断档。

5.2 状态机：别把“审核状态”和“发布状态”混在一起

主表里的status我定义得很克制：0 草稿、1 已发布、2 已锁定。草稿只有创建者和管理员能看；已发布是所有人都能看；已锁定是管理员对某些争议词条做的保护，锁定期间不能编辑。

但如果你做的是一个开放型百科，需要审核才能上线，千万不要在主status上再加一个“待审核”状态。一旦一个词条已经发布，用户又提交了新的修改，这个词条到底是继续展示旧内容还是下线？我建议单独加一个audit_status字段，和主status解耦。已发布的词条即使有修改在审核中，也继续展示当前版本，不打断阅读体验。

5.3 编辑理由和操作日志必须留

我在保存接口里强制要求edit_reason非空，理由是用户每次编辑时多写一句话，能让后来的人在版本列表里快速判断该看哪个版本。同时后台再单独记录一份操作日志，包括操作人、动作、时间、对象词条 ID，不存正文，只存元信息。这样定位问题的速度会快很多。

6. 复刻百度百科时我踩过的三个不算技术但很疼的坑

最后分享三个项目后期才暴露的问题，每一个都不是高深难懂的 Bug，但只要没提前处理，都会让运营人员多花很多时间。

6.1 “Python”和“python”是同一个词条

词条标题的唯一性比想象中难维护。英文大小写、前后空格、中文全角符号，都会导致同一个词条被创建两次。我的处理是在写入时统一生成title_key：转小写、去首尾空格、半角转全角再转回半角。创建和更新接口都走同一套归一化逻辑，数据库唯一索引加在title_key上，而不是title上。这样“Python”和“python”会同时命中同一个词条，而不是变成两个孤立页面。

6.2 图片别用 base64 塞进数据库

第一版编辑器插入图片时，前端直接把图片转成 base64 存进了 Markdown 里。体验确实爽，但数据库体积膨胀得飞快，一个词条塞三五张图，记录就几十 MB。后来全部改成先调/api/file/upload上传，接口返回一个相对路径，编辑器只把路径写进 Markdown。本地存储的话，在 Nginx 里把/uploads/映射到磁盘目录即可。数据库里永远只存字符串，不存图片字节。

6.3 空搜索结果的引导很重要

搜索一个不存在的词条时，如果页面只显示“未找到”，用户大概率直接走了。我在搜索接口里加了一个兜底逻辑：没有结果时，后端返回热门词条列表，同时前端在页面上展示一个“创建该词条”的按钮。实操下来，这个按钮带来的新词条创建量，比在导航栏放“我要创建词条”高出好几倍。百科类产品的内容增长，很多时候靠的就是用户搜索无果后顺手创建的行动。

这个项目做完之后，我对“超级模仿百度”这句话有了新的理解。真正值得模仿的不是某个像素级页面，而是它把内容组织、用户编辑、历史追溯串成一条链路的方法。如果你也在做类似系统，先把词条表、历史表、搜索与回滚这条主链路跑通，其他的交互细节都是锦上添花。

本文还有配套的精品资源，点击获取