企业官网建设流程全解析

如果你现在被安排去维护一套政务站群，十有八九会遇到这样一个场景：站群里的各个站点都发布了大量PDF文件，有政策文件、办事指南、规划文本、验收报告，每一份都是几十上百页。文件放在那里，搜索引擎只能把它们当作整体索引，站内检索也只能命中文件名或者偶尔被爬虫抓到的摘要。想按章节定位一个小标题，根本做不到。

这篇文章就围绕一个真实需求来讲：政务站群如何配置WordPress，实现PDF目录的结构化提取。这里说的"目录结构化提取"，不是简单地把PDF转成Word，而是把PDF内部的章节结构（一级标题、二级标题、页码）解析成树状的层级数据，存进站群的数据库里，最终在前端形成一个可点击跳转的目录树，并支撑标题级检索。我以自己实际搭建的一套方案为例，把环境配置、解析原理、入库逻辑和排错经验一次讲清楚。

1. 方案拆解：政务站群与PDF提取到底要解决什么

1.1 政务站群的形态

政务站群通常不是单个网站，而是一个主站加若干子站组成的集合。比如一个市级主站下面，挂着各个委办局、直属单位的子站点，这些站点在后台管理、用户体系、视觉风格上需要统一，但在内容发布上又各自独立。

用WordPress搭建这种形态，最合适的底座是多站点网络（Multisite）。它允许你用一套WordPress内核，管理多个虚拟站点，每个站点拥有独立的文章、分类、菜单和媒体库，但插件和主题可以统一部署。

相比搭多个独立WordPress，多站点网络的好处很明显：升级内核只操作一次，插件安全补丁只需更新一套，各子站的主题样式可以共用父主题加子主题的方式做差异化。对政务场景来说，这还意味着审计和权限的统一入口，所有子站由一套用户系统管控，后台管理员角色可以按站点分配。

1.2 PDF目录结构化提取的价值

政务站群里的PDF，往往是扫描件或打印排版文件，内容非常重要，但检索体验一直很差。用户想知道某份规划里"第三章第二节"讲了什么，只能下载几十页PDF慢慢翻。

如果能把PDF的目录抽出来，变成结构化数据，就有三个直接价值：

第一，前端可以做"文档内导航"。用户打开PDF详情页，侧边栏直接出现章节目录，点一下跳到对应页码或对应段落，阅读体验大幅提升。

第二，站内搜索可以精确到标题。搜索引擎站内检索按标题和内容段落命中，而不是只靠文件名，查全率和查准率都会提高。

第三，内容治理更方便。政务站群通常要定期盘点文件，目录结构化后能快速统计"已发布文件包含哪些章节""哪些文件缺乏层级标注"，方便做内容合规梳理和归档。

1.3 整体技术选型的逻辑

我最终采用的方案是：WordPress多站点网络作为站群底座，用Python独立脚本做PDF解析，解析结果通过WordPress REST API导入各子站。为什么不用WordPress插件直接解析PDF？

最主要的原因是想把"下载PDF"和"解析PDF"两个动作解耦。PHP生态里解析PDF的工具链虽然不缺，但遇到扫描版PDF要调OCR、遇到畸形目录要反复调参，这些工作放在脚本里做更灵活。而WordPress端只负责接收结构化数据并展示，职责单一，不容易拖垮站群性能。

整个链路是：PDF文件统一存放 → Python脚本遍历文件并提取目录 → 生成树形JSON → 调用REST API写入对应子站 → 前端目录树渲染。

2. 第一步：把WordPress站群环境搭稳

2.1 服务器环境与依赖

我先交代一下实验环境的参考配置：一台2核4G的云主机，系统用的Ubuntu 22.04 LTS，Nginx + PHP 8.1 + MySQL 8.0。如果你用的是宝塔面板或者小皮面板这类集成环境，思路一样，只是图形界面操作路径不同。

WordPress站群的性能瓶颈往往不在解析PDF，而在数据库和PHP进程。政务站群即便单站内容量不大，一旦上了多站点网络，数据库表数量会明显增加，建议MySQL内存参数适当调高。

PHP方面需要确认开启了以下扩展：

• mysqli或mysqlnd：数据库连接
• curl：REST API通信
• mbstring：处理多字节字符，后面导入中文目录时一定要开
• gd或imagick：PDF缩略图生成时用

注意：政务场景下服务器一般都有更严格的安全基线，这里只说共性的软件要求。实际部署前记得把用户权限、目录写权限、管理后台访问控制按本单位的规范收紧。

2.2 启用WordPress多站点网络

WordPress默认是单站点模式，启用多站点需要改配置文件。

第一步，在wp-config.php中，把WP_ALLOW_MULTISITE设为true：

define('WP_ALLOW_MULTISITE', true);

保存后进入后台，在"工具 → 网络设置"里选择子目录模式还是子域名模式。政务站群我建议用子目录模式，比如主站是www.example.gov，子站是www.example.gov/dept1、www.example.gov/dept2，这样SSL证书和泛解析都不需要额外处理。

配置完成后，WordPress会提示你在wp-config.php和Nginx配置里加入两段网络规则。其中wp-config.php需要增加：

define('MULTISITE', true); define('SUBDOMAIN_INSTALL', false); define('DOMAIN_CURRENT_SITE', 'www.example.gov'); define('PATH_CURRENT_SITE', '/'); define('SITE_ID_CURRENT_SITE', 1); define('BLOG_ID_CURRENT_SITE', 1);

Nginx下的伪静态规则和单站点不同，需要把请求都交给index.php处理，大致是这样：

rewrite ^/([_0-9a-zA-Z-]+/)?wp-admin$ /$1wp-admin/index.php last; rewrite ^(/[_0-9a-zA-Z-]+/)?files/(.+) /wp-includes/ms-files.php?file=$2 last; if (!-e $request_filename) { rewrite ^(/[_0-9a-zA-Z-]+/)?(.*)$ /index.php?q=$2 last; }

配置完成后，在"我的站点 → 管理网络"里就能创建子站。我建议创建子站时就把路径规划好，用部门或业务名称做目录名，不要事后改。

2.3 主题、插件与目录规划

在站群上预装主题时，不要给每个子站一套独立主题，而是做一个基础父主题，各子站通过子主题覆盖配色和首页模块。PDF目录树组件可以做成父主题里的一个模板区块，这样所有子站自动继承。

插件方面，政务站群我会保守选择，尽量少装，一般保留这几类：

• 安全类：登录限制、双因子认证
• 性能类：页面缓存、数据库优化
• 功能类：自定义文章类型管理、REST API增强工具

这里特别提醒：多站点网络下，插件可以选择"网络启用"（所有子站生效），也可以只在特定子站启用。PDF结构化目录相关插件建议只在需要用到的子站启用，避免无关站点出现多余的数据表和菜单项。

3. PDF目录结构化提取的两种实现路径

3.1 路径A：利用PDF自带书签（大纲）提取

我处理的第一批PDF是排版规范的文件，带书签。这种PDF在Adobe Reader里左侧会显示"书签"，其实就是PDF文档大纲（Outline）。

Python里用PyMuPDF（fitz）提取最方便，一行代码就能拿到所有书签：

import fitz doc = fitz.open("example.pdf") toc = doc.get_toc() print(toc)

输出是一个二维列表，每条包含三个字段：[层级, 标题, 页码]。比如：

[ [1, "第一章 总则", 1], [2, "1.1 目的依据", 1], [2, "1.2 适用范围", 2], [1, "第二章 组织机制", 5], [2, "2.1 职责分工", 5], ]

这个结构已经接近最终要入库的树形数据了，只需要按层级缩进关系，转成父子嵌套结构。

但这里有个坑：PDF书签中的页码是"物理页码"，也就是PDF文档从第1页开始连续编号的页码，而不是文件内印刷的"逻辑页码"。很多文件封面占1页、目录占2页，正文却从第9页才开始印"1"。如果你直接拿书签页码跳转，用户点"第一章"会跳错位置。最稳妥的办法是建立"物理页码→逻辑页码"的偏移映射，或者干脆在前端跳转时用物理页码定位。

3.2 路径B：目录页文本识别与结构重建

大部分政务PDF没有那么规范，要么没有书签，要么书签层级混乱。这时只能退而求其次：从PDF目录页提取文本，再用规则匹配重建目录。

目录页的特征是集中在前几页，每行由标题和页码组成，标题和页码之间通常有点线连接符（点、下划线或空格）。用pdfplumber抽取目录页文本：

import pdfplumber with pdfplumber.open("example.pdf") as pdf: # 找目录通常在正文前几页，取前10页遍历 for page in pdf.pages[:10]: text = page.extract_text() print(text)

拿到文本后，用正则匹配典型模式。政务文件目录常见的格式有两类：

• 中文规范式："第一章 总则 1""一、背景与意义 3"
• 数字编号式："1.1 目的依据 5""2.2.1 审核流程 12"

核心正则示例：

import re pattern = re.compile( r'^\s*(?P<title>' r'第[一二三四五六七八九十百]+[章节部分篇]|\d+(\.\d+)+|[一二三四五六七八九十]+、' r'.*?)\s*[.．·\s]*\s*(?P<page>\d{1,3})\s*$' ) for line in text.splitlines(): m = pattern.match(line) if m: print(m.group("title"), m.group("page"))

规则匹配最大的问题是容错。PDF提取出来的中文，标题和页码之间的点线经常被拆成奇怪的空白或点字符，正则要把各种分隔符都考虑进去。我见过目录行长这样："第一章 总则 ......... 1"，也见过"1.1 目的依据5"（没有分隔符），还有"规划和计划制定12"（页码和正文之间只有一个空格甚至没有空格）。没有一套正则通吃所有文件，所以脚本必须保留一个"未匹配行"的输出日志，方便人工复核。

3.3 提取结果如何组织成树形数据

无论走哪条路径，最终都要转成树形JSON。比如：

{ "title": "第一章 总则", "page": 1, "children": [ { "title": "1.1 目的依据", "page": 1, "children": [] } ] }

转换逻辑并不复杂：遍历扁平的书签列表，用栈记录当前层级，遇到更高层级就入栈，遇到更低层级就出栈。代码大致类似：

def build_tree(toc): root = [] stack = [(0, root)] for level, title, page in toc: node = {"title": title, "page": page, "children": []} while stack[-1][0] >= level: stack.pop() stack[-1][1].append(node) stack.append((level, node["children"])) return root

关键是要先对toc做一次清洗：去重、修正明显错位的页码、过滤广告页和封面页的无意义书签。

4. 把结构化目录写回WordPress并展示

4.1 设计自定义文章类型与字段

结构化目录不能塞进WordPress默认的文章表里，需要做一套自定义文章类型。我在主题的functions.php里注册了一个名为gov_pdf的文章类型，用于承载PDF文件的元数据和目录树。

自定义字段设计如下：

REST API写入时，toc_json字段默认不会被暴露。需要显式注册：

register_post_meta('gov_pdf', 'toc_json', [ 'type' => 'string', 'single' => true, 'show_in_rest' => true, ]);

4.2 批量入库：脚本调用REST API

入库我推荐用REST API，而不是直接连数据库。数据库直插初始效率高，但后面一旦调整字段、涉及多站点权限会非常痛苦。REST API虽然慢一些，但走的是WordPress标准流程，会自动生成文章ID、处理权限校验、触发钩子。

步骤如下：

第一步，在多站点后台为脚本创建专用用户，并生成"应用程序密码"。这个密码专门给脚本用，可以随时吊销，避免用管理员主密码。

第二步，Python脚本里用requests库，逐个解析好的JSON数据推送到指定子站：

import requests api_base = "https://www.example.gov/dept1/wp-json/wp/v2/gov_pdf" headers = { "Authorization": "Basic <base64(用户名:应用密码)>", "Content-Type": "application/json" } data = { "title": "某市政务公开目录.pdf", "status": "publish", "meta": { "pdf_url": "https://www.example.gov/wp-content/uploads/2026/01/example.pdf", "toc_json": json.dumps(tree_data, ensure_ascii=False) } } resp = requests.post(api_base, headers=headers, json=data, timeout=60)

注意ensure_ascii=False不能省，否则中文章节标题全部变成\uXXXX转义，虽然也能解析，但排查问题时会多一层障碍。

第三步，检查返回状态码，凡是200之外的结果都要记录下来。实际批量导入时，经常遇到超时、字段名写错、权限不足三种情况，所以脚本里要加重试机制。

提示：政务站群上线前，先拿两份典型PDF做全链路测试，一份带书签的、一份纯扫描的，确认导入、展示、搜索都正常，再放开全量任务。

4.3 前端目录树与检索联动

文章类型有了，目录树JSON也存进去了，前端要考虑的是怎么打开PDF详情页时，把目录树渲染成可点击侧边栏。

最简单的实现，是前端请求REST API拿到当前文章的toc_json字段，递归渲染成嵌套列表。点击某个目录项时，可以把GET参数传给一个独立的PDF阅读页，让阅读器直接跳转到指定物理页码。

展示效果类似：

第一章 总则 1.1 目的依据 1.2 适用范围 第二章 组织机制 2.1 职责分工 2.2 监督方式

目录树组件要注意加载顺序：先渲染文章标题和元信息，再异步加载目录树，避免整个详情页因为目录树解析阻塞。对大文件（几百个节点），递归渲染后用CSS控制折叠，不要一次性展开所有层级。

检索联动方面，政务站群的搜索通常要跨子站。这一步我建议把目录树索引到Elasticsearch或者站群的统一搜索模块里，索引字段包括：文章标题、章节标题、章节页码。用户搜索"职责分工"，返回结果可以附带"来自《某市政务公开目录.pdf》 2.1 职责分工 第5页"，点击后直接跳到对应章节。

5. 政务站群场景中的问题与排错实录

5.1 扫描版PDF没有文本层

政务场景里扫描件占比不低。老文件、上级转发的红头文件、有盖章的复印件，经常是纯图片PDF。

这类文件没有文本层，pdfplumber提取出来全是空白。我的处理方案是内置两条路：

路径一，优先用OCR引擎（如Tesseract）识别前几页目录页，把识别结果当作目录文本源。OCR中文效果受字体和扫描清晰度影响，需要准备字体训练或选择合适的中文识别模型。

路径二，实在识别不出来，就退回人工录入。做法是把PDF的目录页导出成图片，由人工对照图片维护一份"目录对照表"，再导入脚本生成结构化JSON。虽然不如全自动理想，但执行起来效率很高，几百页文件通常十几分钟就能录完一份。

OCR处理有一个容易忽略的细节：页面方向。扫描件经常是歪的，OCR前要先用图像处理库做倾斜校正。不校正的话，识别出来的标题文字会混杂中英文和标点，正则匹配会非常抓狂。

5.2 乱码与字体问题

PDF文本提取乱码的根源，大部分是字体编码映射异常。PDF里有两种常见情况：

• 字体没有嵌入，或者使用自定义编码（如CID），pdfplumber提取时拿到的是字形索引而不是Unicode
• PDF由WPS、老版Word生成时，字符映射表不完整，提取出来出现大量"口"或乱码

排查思路是：先用pdfplumber提取任意一页文本，肉眼判断乱码比例。如果乱码集中在个别文件，优先换PyMuPDF试试，两个库的底层解析器不同，很多时候PyMuPDF能正常提取中文，pdfplumber却不行。

如果两种库都乱码，就得考虑先转PDF。将PDF逐页渲染成图片，再走OCR。这个方案能解绝大多数乱码问题，代价是耗时增加，但政务站群文件更新频率不高，后台慢慢跑完全可以接受。

5.3 目录层级错乱

正则匹配出来的目录，经常出现层级归属错误。比如"2.1 职责分工"没有匹配到二级，掉到了一级；或者"第三章"下面混入了"3.2.1"这种更深的层级。

我的建议是：不要在正则上追求完美的层级推断。正则只负责判断这一行是不是目录项，并提取标题和页码；层级归属靠与PDF自带书签比对，或者靠字体字号信息辅助判断。

如果文件里有书签，直接以书签层级为准。如果没有书签，尝试从PDF字体信息中识别：同一套目录页，一级标题通常是二号或三号字，二级是小三或四号字，通过字号聚类可以推断层级。

当字号信息也无法区分时，就保留"扁平结构"，把所有标题放在同一层。前端展示时通过缩进和序号本身来体现层级，虽然不够精致，但至少不会出现"子标题挂错父节点"的错误。

5.4 站群同步与权限避坑

多站点网络有一个隐蔽问题：attachment媒体文件属于上传它的站点，而gov_pdf文章如果也在同一个子站，直接引用媒体URL没问题。但如果想跨子站统一展示PDF，就需要把PDF文件放在共享目录，或者复用主站的媒体库。

另外，REST API写入多站点时，每个站点的API路径不同，权限用户必须是在对应子站有编辑权限的用户。一个网络管理员虽然有全局权限，但Application Password的生效范围可能受插件和权限策略影响，排查时要先简单请求/wp-json/wp/v2/users/me确认身份。

数据导入后如果发现某个子站文章数量异常，别先怀疑脚本，先看是不是API写入时重复执行了。脚本必须做幂等控制，比如用PDF文件名加文件MD5作为唯一键，重复推送时更新已有文章而不是新建。

我把这套方案落地之后，最明显的感受是：PDF目录结构化提取这个事，技术难度不是最高的，真正考验人的是文件本身的多样性。同一个站群里的PDF，可能是规范排版、可能是扫描件、可能是老系统导出的畸形文件，每一类都要有对应的兜底策略。如果你刚开始做，我建议不要急着写全自动脚本，先拿十份典型文件跑一遍，把异常类型摸清楚，再逐步自动化。政务站群最重要的是稳定和可控，宁可慢一点，不要上线后批量出错。