企业官网建设流程全解析

在学校的网站维护工作中，有一个特别容易让人头疼的交接场景：教务处老师发来一批Word文档，里面有教案、有试卷分析、还有各类通知，希望能挂到新做的校务系统网站里。光看正文还好，麻烦的是文档里那些图片——截图、扫描图、公式、示意图，到了WordPress后台要么显示不出来，要么位置全部错乱，要么干脆上传失败。这个问题在教育行业特别普遍，因为Word文档几乎是学校行政和教学的核心文件格式，而WordPress作为CMS系统，对Word文档里的图片处理逻辑完全是另一套体系。本文就围绕这个场景，拆解Word图片格式兼容问题的根源、可行的处理路线、以及我在实际项目中踩过的坑和最终采用的方案，给正在做校务系统、校园网站、教师内容管理平台的同行一个参考。

1. 问题根源：教育行业的内容生产习惯与Web端图片机制的冲突

1.1 老师们的Word文档到底长什么样

教育行业的Word文档，跟互联网公司里的Markdown文档、飞书文档完全是两个物种。如果抽样检查学校电脑里的文档，你会看到大量这样的文件：教案、教学设计、教学反思、试卷分析、家长会发言稿、课题申报书、论文、各类总结报告。这些文档的共同特点是：排版靠手动空格和回车，图片靠截图粘贴，格式靠Word自带的样式库，公式有时用MathType，有时用Word自带的公式编辑器，偶尔还嵌套着老旧的文本框和艺术字。

图片来源更是五花八门。最常见的三种：第一种是直接截图，老师用微信截图、QQ截图、或者键盘PrintScreen键，把课件、试卷、网页内容截下来粘贴进文档，这类图片大多是PNG格式；第二种是从其他文档或网页里复制内容，连图带文一起粘进来，图片可能带链接、带边框、甚至带一堆内联样式；第三种是扫描件和拍照件，用于试卷、手写教案、通知红头文件，这类通常是JPG，但清晰度参差不齐。

这些图片在Word里显示的"没问题"，跟它们在WordPress里的"能否正常显示"是两回事。很多老师眼里"这就是一张图"，而实际上在Word文档内部，图片可能是嵌入对象、浮动框架、链接文件、OLE对象、甚至是Word自己的绘图画布。这些差异直接决定了上传到WordPress后能不能正常展示。

1.2 WordPress"不认识"的图片类型清单

WordPress的媒体库和图片处理管线，从设计之初就是围绕Web图片格式做的。媒体库默认允许上传的图片类型是jpg、jpeg、png、gif、webp，可能还包括ico、bmp，但有一个前提：服务器的GD库或者Imagick扩展要支持处理这些格式。问题恰恰出在Word文档里的其他"图片形态"上。

我见过不少朋友在校务系统上线初期遇到诡异现象：图片传上去是空白、传上去显示"文件包含损坏的内容"、或者干脆上传按钮直接报错。最后排查下来，源头十有八九是WMF和EMF这两个格式。这两个是Windows下的矢量图元文件格式，老版Word、剪贴板复制图表、MathType公式、以及一些从老教材配套光盘里复制来的图片，都会以这种格式潜伏在docx里。但WordPress的安全策略和PHP的上传白名单里通常没有这两个扩展名，即使强行改了后缀传上去，Web浏览器也不认。

再说BMP，虽然WordPress在某些配置下允许上传，但一张几MB的BMP会直接拖垮网页加载速度，还会在生成缩略图时消耗大量服务器资源。教育系统里经常有老教师用Word 2003时代流传下来的文档，里面插着BMP图片的情况非常常见。

1.3 常见误区：以为只是"重新上传一遍"就行

这里必须先打破一个幻觉：很多人以为Word图片兼容问题，就是把Word里的图片一张张另存出来，再传进WordPress媒体库，然后手动插回文章。这个思路理论上没错，但实际操作时你会发现几个残酷的现实。

第一，Word里的图片不是"一张图"那么简单。你从Word里右键另存图片，得到的可能是裁剪后的部分、可能是被压缩过的低清版本、也可能根本不是原图而是OLE对象的预览图。第二，图片在Word中的位置是相对于段落和页面的，另存出来再手动插回Web编辑器，原来的图文关系全部失效，重新排列的工作量堪比重新排版。第三，批量处理的时候，一个老师的电脑里可能有几百份历史文档，每份有十几张图，手动处理完全不现实。

所以，处理Word图片格式兼容，核心不是在WordPress端做图片管理，而是要在"Word文档迁移到Web"的路径上做一次系统性的格式转换和图片提取。理解了这个前提，后面的技术方案才有讨论的意义。

2. 先搞懂Word图片的"格式家族"，兼容问题才好解

2.1 位图：JPG、PNG、GIF、BMP，问题相对小

位图是纯洁的平面像素图，也是WordPress最喜欢的"正常图片"。JPG用于照片和扫描件，PNG用于截图和透明底图，GIF用于简单动画，BMP是老古董。

这一类图片只要从Word里提取出来，经过压缩和格式转换，上传到WordPress基本没有兼容问题。唯一的坑在于：Word本身会对插入的图片做压缩，如果老师插入原图时勾选了"压缩图片"选项，或者文档保存时选择了"Web/屏幕"输出，那么文档里嵌入的已经是低分辨率版本，你再怎么提取，也拿不回原始高清图。这一点在教学设计大赛投稿、试卷扫描存档这类场景里特别要命，因为图片的清晰度直接决定评委或者家长能不能看清内容。

另外，从Word里复制内容时，剪贴板里的图片经常是PNG格式，但分辨率会跟随Word的显示缩放，导致导出的PNG宽度可能只有几百像素。处理这类图片要提前设置好目标宽度，不能盲目放大。

2.2 矢量与元文件：WMF、EMF，WordPress的默认黑名单

WMF（Windows Metafile）是Windows早期的16位矢量图元文件，EMF是它的32位升级版。这两个格式在很多老Word文档里非常常见，尤其是从旧版Office、老教材配套光盘、化学结构绘图软件、MathType公式编辑器里带出来的内容。

为什么WordPress处理不了这两类？一是PHP的getimagesize函数和GD库对WMF/EMF支持不佳，无法读取宽高信息，媒体库会直接判定为无效图片；二是浏览器端根本不渲染这两种格式，即使上传成功，访客看到的也是破图；三是这类文件可能包含可执行指针代码，存在安全风险，WordPress社区和各大安全插件都会把这些格式列入黑名单。

处理WMF/EMF的正确姿势，是在服务器端用LibreOffice或ImageMagick转成PNG，再导入媒体库。转出来的PNG是按Word中的实际显示尺寸和DPI渲染的，清晰度一般够用。但要注意，转出来的PNG背景可能是黑色或透明，这取决于原图是否带背景填充，实际操作时需要加白底处理。

2.3 隐形图片：OLE对象、公式、文本框、链接图片

这一部分是最容易忽略的"隐形图片"。OLE对象是Windows的复合文档技术，Word里的嵌入Excel表格、嵌入PPT页、嵌入Visio图、MathType公式，本质都是OLE对象。Word在界面里显示的是对象的外观快照，但那不是真正的图片文件。

处理OLE对象，常见的办法有两种：一种是用目标软件打开OLE对象，再导出为图片，比如MathType公式可以用MathType自带的导出功能转成PNG或LaTeX；另一种是用Pandoc这类工具在转换文档格式时，将部分OLE对象转换成图片或MathML/LaTeX。实际操作里，教育文档最常见的OLE对象就是公式，我放在后面单独说。

文本框是另一个高频隐性问题。Word里的文本框在docx文件结构里是独立的绘图元素，文本框里可以放文字、图片、表格。有些老师喜欢用文本框做标题、做卡片式排版，但Web端的图片渲染完全没有"文本框"这个容器概念，直接用编辑器转换时，文本框里的图片会脱离容器，变成飘在页面上的孤岛，位置全乱。

链接图片（Linked Image）相对少见，通常出现在"复制--粘贴--选择性粘贴--链接"这种操作之后，docx文件里只存了图片路径，并没有图片本体。一旦把Word文件拷贝到另一台电脑，图片路径失效，文档里就剩一个空框。处理时要把链接图片在源机器上解除链接，再重新嵌入。

2.4 用实际手段查验一个docx文件里的图片真相

在决定用什么方案处理之前，我强烈建议先做一次"病理检查"，把一个docx文件当zip包拆开，看看里面的图片到底是什么货色。操作方法很简单，把docx后缀改成zip，解压后看word/media文件夹，所有嵌入的图片都在这里。

这个文件夹能告诉你很多信息：文件后缀是否混杂着emf、wmf、bin后缀；图片的命名是否是image1.png这样按顺序排列；media文件夹整体大小和图片个数是否异常；有经验的还能通过查看word/document.xml文件，了解每张图片的引用方式、裁剪参数和实际尺寸。

我的习惯是先在测试环境里跑一段脚本，把目标目录下所有docx文件解压，统计media文件夹内的图片格式分布占比。如果emf和wmf占比超过5%，说明这批文档需要专门的矢量化转换流程；如果全是png，说明主要压力在压缩和批量导入；如果连bin后缀都有，说明里面嵌了OLE对象，需要逐个打开验证。这个前置检查能帮你避免在验证阶段才被按个击破的窘境。

3. 三条迁移路线：选错路线=后面疯狂返工

3.1 路线一：编辑器直接复制粘贴或插件导入

这是最省事、也最容易出问题的路线。把Word文档内容从Word里Ctrl+C、Ctrl+V，粘贴到WordPress古腾堡编辑器里，Gutenberg会自动做一次"Word格式转HTML"的转换，图片会以Base64或远端地址的形式塞进HTML。

这样做会出现三种情况：一是小图、单图能正常显示，但位置和样式靠内联CSS硬撑，后期维护极其困难；二是WMF/EMF图片直接变成碎图或者空框；三是大文件粘贴后编辑器卡死，因为浏览器内存里需要同时维护Word格式和HTML格式。虽然市面上有Word导入类的插件，比如FileCat、WP Word Import，它们支持上传docx并提取内容，但本质上仍是依赖WordPress内置的docx转HTML逻辑，对复杂格式的支持参差不齐。

教育场景下，这个路线只适合已经做完格式清洗、图片全部转成PNG/JPG且是常规排版的文档。一旦涉及公式、文本框、复杂目录，这条路基本走不通。不过它有一个优点：PHPWord和大部分导入插件不会执行Word文档内的宏代码，安全性可控，适合内网系统快速发布。

3.2 路线二：文档转换，用中间工具统一处理

这是我在实际项目中主力采用的路线。思路是把Word文档作为源文件，先通过中间工具转换为更适合Web的内容结构，再进行发布。常用的中间格式是HTML或Markdown，中间工具首选Pandoc，其次LibreOffice命令行，再次是Word另存为网页功能。

Pandoc可以读取docx里的段落、标题、图片说明、表格和公式，并自动提取图片到指定文件夹，同时把图片引用路径改写成相对路径。这样你不用逐张手动保存图片，转换一次就能得到一份相对干净的HTML/Markdown文件和配套图片文件夹。LibreOffice命令行的作用是弱化版Pandoc，它可以无头模式运行，适用于批量处理老版.doc，也能完成docx转HTML。

这条路线适合批量生产流程：老师把Word文档交给系统管理员，管理员跑一次Pandoc脚本，一份文档生成一个文件夹，里面是HTML和图片，再在WordPress后台把这套内容导入，或者通过脚本自动生成文章。优点是可扩展、可批处理、可控性强；缺点是需要写脚本和维护转换规则，有一定技术门槛。

3.3 路线三：结构化重构，把内容当作数据来治理

这条路线的核心思想是"不转换格式，转换生产流程"。也就是说，不再追求把已有Word文档变成网页，而是要求老师在建站初期就往WordPress后台直接录入内容，或统一做一个带格式预设的投稿模板，让内容在Word里写好、在后台用块编辑器重新排版。

这样做的好处是：图片一开始就以Web格式和相对布局存在，不存在兼容问题；内容具备结构化语义，方便多年沉淀和检索；网站的移动端适配、无障碍访问、SEO优化全部受益。缺点是：对老师的要求极高，老教师习惯了Word的二维排版，让他理解Gutenberg的块模型需要培训成本，且历史存量文档还是要靠路线一或路线二清一次。

教育行业里，新建校务系统的存量文档一般不多，但新建内容的速度极快。我见过很多学校耗费人力做了一次性转换，解决了存量问题，但新内容全部绕开后台直接发Word共享群，半年之后网站内容又变成"半瘫痪"状态。所以路线三本质上不是技术方案，而是一项管理规范，只有跟学校的信息化考核制度绑定，才能真正落地。

3.4 教育行业怎么选：结合存量文档、维护人力和公式需求

三条路线怎么选，我自己的判断依据有三条。

存量文档占比：如果学校有大量必须发布的存量Word文档，比如历年中考试卷分析、优质课教案集、课题结题材料，推荐路线二，做批处理和转换脚本；如果存量少，新内容为主，直接上路线三，建站初期就把选题、格式、图片规范定下来。

维护人力：学校的技术岗往往只有一两个人，还兼职电教、摄影和修电脑。如果负责的人对脚本不熟，建议采用路线一加路线二的混合：日常简单文档用复制粘贴，复杂文档用Pandoc脚本跑，脚本我可以免费分享在文末。

公式需求：数学、物理、化学学科是公式大户。如果目标网站要发布公式密集的讲义和试卷，强烈推荐路线二，并且要专门设计公式转换链，把MathType和老版Word公式转成MathML或LaTeX，再由MathJax渲染。这一块依赖方案做得好，能直接挽救一个学校数学组的工作效率。

4. 基于Pandoc中转的批量处理实操

4.1 环境准备与转换

Pandoc在各平台都有安装包，安装完成后，在终端或者CMD里执行转换。教育系统服务器的操作系统Linux和Windows都有，命令基本一致，我以Windows环境和Pandoc 3.1版本为例。

pandoc 教案.docx --extract-media=media -t markdown -o 教案.md

转换后目录里会多出一个media文件夹，所有图片被提取出来。注意Windows环境下，Pandoc保存文件名可能是绝对路径格式，会在Markdown里出现类似![](media/images/image1.png)这样的引用，相对路径没问题。

如果源文件是老版.doc二进制格式，Pandoc读不了，先统一转成docx。假设你装好了LibreOffice，用它的无头模式批量处理：

soffice --headless --convert-to docx --outdir D:\converted D:\raw\*.doc

LibreOffice转换老版.doc时，图片格式和公式可能会发生一次劣化，尤其是MathType公式。处理这情况的经验是：先把所有.doc升级成.docx，再用Pandoc转HTML/ Markdown，不要希望在LibreOffice一步到位。

4.2 图片提取、重命名、路径回填

Pandoc提取的图片命名是按顺序来的，image1.png、image2.png这样，放在media文件夹里。但教育场景下，几十个文档的media文件夹混在一起容易出现同名覆盖，最好在转换脚本里给每个文档单独建目录，或者提取后按文档名重命名。

我实际用的脚本逻辑是这样：

1. 遍历一个录入目录下的所有 docx 文件
2. 为每个文档建立输出子目录，目录名就是文档标题
3. Pandoc 转换时 --extract-media 指到该文档自己的子目录
4. 转换完成后，用 PowerShell 或 Python 遍历图片，统一重命名成"文档标题_序号"
5. 用字符串替换，把 Markdown 文件里的旧图片路径改成新路径

这样处理的优势是，后续上传到 WordPress 时，不会因为同名文件导致覆盖。

图片路径回填还有一个坑：Pandoc生成的HTML里，图片的引用路径往往带了media/前缀，但Markdown里相对路径也可能带/开头，导致上传时排查麻烦。建议在脚本里统一做一次正则替换，把路径中的绝对盘符和file:///前缀清掉。

4.3 用WordPress媒体库API或脚本导入

转换结束后，就面临把图片和HTML/Markdown导入WordPress的问题。有两种常见方式。

第一种是直接把Markdown内容复制到后台的块编辑器里，手动上传图片。这种方式适合文档数量少的情况。有一个免费插件叫"Markdown Content Importer"，可以直接读取Markdown文件并创建文章，图片路径写成本地路径后再配合媒体库导入工具，能省下不少人力。

第二种方式用WP-CLI或者写PHP脚本调WordPress函数。我写过一个简单的导入脚本，逻辑是：读取一个文件夹下的HTML/Markdown文件，将所有img标签的src指向media文件夹内的对应图片；用media_handle_sideload函数把图片塞进媒体库，拿到新的附件ID；然后重置文章正文里的图片路径，更新到wp_posts表。这样几千张图的大批量导入，几分钟就能跑完。

脚本需要注意的点：media_handle_sideload要求服务器允许写入uploads目录；上传过程中如果生成缩略图失败，要在admin里检查wp_generate_attachment_metadata的返回值；教育网环境下PHP执行超时是常态，脚本里要设置set_time_limit(0)，并且分批处理。

4.4 检查清单：从浏览器呈现回查docx差异

处理完一批文档，不要着急宣布"转换完成"，先做一次抽查。我的检查清单如下：

• 每张图片是否能在页面正常显示，是否出现破图（WMF/EMF转换失败的高频症状）
• 图片是否被拉伸失真，尤其表格类和截图类图片容易因为宽度自适应导致变形
• 图片是否还在文字的正确位置附近，还是全被挤到文档末尾
• 公式类的图片是否清晰可读，文字是否有乱码或缺失
• 表格缩略图是否完整，Web端表格被截断的情况在试卷分析中很常见
• 页面加载速度是否异常，是否有图片尺寸过大导致的首屏缓慢

这些检查最好在测试环境里做，不要在正式校务系统上做破坏性测试。如果用了图片懒加载和CDN，检查一次缓存刷新机制是否及时，避免老师那边看到的是旧图片。

5. WordPress侧的"二次治理"：压缩、响应式与懒加载

5.1 图片压缩的边界：别把表格截图压糊

Word文档里的图片，尤其是从أعلى课程软件、录屏软件、智慧教室平台导出的截图，往往带有大量文字和小图标。这类图片对压缩算法非常敏感，如果用默认的80%质量JPEG压缩，很容易出现文字边缘发虚、图标锯齿、颜色断层。

处理这类图片的原则是：有文字截图的图片，尽量保留PNG格式，或者用WebP无损模式；照片类和扫描件类用JPEG适当压缩；纯色为主的图标和图形，用PNG-8或WebP有损模式就够。实际运维中，我会针对media文件夹里的图片按类型分目录处理，而不是统一一个压缩参数。

图片压缩工具有很多，WordPress侧我推荐用Smush或ShortPixel这类插件，但它们对WMF/EMF转换来的PNG不友好，因为它们只压缩上传后的图片。如果是在转换阶段就做好尺寸和格式管理，导入后再让插件做无损压缩，能省不少存储空间。教育网带宽一般不大，几张几MB的大图能直接把校园网里某台老服务器打爆。

5.2 srcset与响应式实现

WordPress从5.5开始，就自动为访问媒体库的图片生成多个尺寸版本，并在文章里输出srcset属性和sizes属性。但这有一个前提：文章里的img标签是WordPress自己的wp-image-{id}类名，并且是通过媒体库插入的。

如果你走的是Pandoc转换加脚本导入这条路，很容易出现一种情况：虽然图片上传到了媒体库，但文章正文里图片img标签没有class="wp-image-xxx"，WordPress就不会自动加上srcset。这种情况下，手机访问网站时，浏览器会把一张2000px宽的PNG直接按屏幕宽度渲染，流量和内存都会飙升，校园网和机房老电脑的体验会很难受。

解决办法有两个。一是写一个过滤器函数，扫描文章内容，把img标签替换成带srcset的版本；二是用插件的"图片懒加载+Retina支持"功能，常见的有WP Rocket、Perfmatters，它们能自动为图片生成响应式属性。不管哪种方式，都不要忘记在文章内容里检查图片的实际显示宽度，避免超大图片被CSS缩放后依旧加载原尺寸。

5.3 加载性能：懒加载、格式取舍（WebP是否用）

WordPress 5.5以后默认给图片加了懒加载，所以基础体验有保障。但我在教育行业部署时还会额外做两件事。

第一件是给图片加渐进式加载。学校机房和老师家里的老旧电脑，网速通常一般，如果图片采用baseline编码（从上到下刷新），视觉上会一直白屏，体验极差。在压缩环节就把JPEG转成progressive格式，能让页面先显示模糊轮廓再变清晰，体感速度快不少。

第二件是WebP的取舍。WebP的压缩率比JPEG和PNG高30%到50%，能显著提升加载速度，但教育系统里还有一个隐藏风险：学校机房里的老Windows电脑还在用IE11或旧版Edge，这类浏览器不支持WebP。所以，除非你能通过WordPress插件或者服务器配置实现"支持WebP就给WebP，不支持就给JPEG/PNG"的降级方案，否则建议先不上WebP，保证兼容性优先级高于性能。等学校机房浏览器版本跟上来再说，在学校里"新技术"往往要排在"稳定可用"后面。

5.4 图片命名与SEO、无障碍规范

教育行业网站经常要接受上级单位的网站普查和评估，图片Alt属性、Title属性都是硬性指标。但Word文档里插入的图片基本没有Alt文本，转换导入后自然也是空白，这会导致网页检查不合格，同时无障碍访问也无从谈起。

处理建议是：在转换脚本里根据文档内容上下文，为图片自动生成Alt占位符，比如"教案_第2节_图1"，后续再人工补充。图片文件名也尽量用语义化命名，不要保留image1.png这种默认名。我把这个逻辑做进了自己的导入脚本里，识别Markdown里的图片引用序号，再结合文档标题生成一个可读的默认Alt，管理员再花少量时间补细节，比一个一个手动加Alt高效得多。

另外，图片的Title、Caption和描述字段可以留空或者简填，避免和Alt冲突。对于包含敏感信息的图片，比如学生成绩、试卷答案，还要做好权限控制，别让带权限的图片被搜索引擎索引或者被未登录用户直接访问，这在教育行业尤其需要注意。

6. 教育场景的专项坑位：公式、老版doc、扫描件与批注

6.1 公式：MathType、OMML的转换路径与兜底方案

公式是教育行业Word文档里最核心的"图片格式兼容"问题，没有之一。数学、物理、化学试卷里的公式，要么用MathType输入，要么用Word自带的公式编辑器（OMML格式）。这两类在docx文件结构里的存储方式完全不一样。

MathType公式在docx里是OLE对象，文件后缀可能是.bin，Word需要本机装有MathType才能真正渲染。Word自带的公式编辑器则把公式存储为OMML（Office Math Markup Language），Pandoc可以将其直接转换为MathML或LaTeX，再经MathJax在网页端渲染，效果很好。所以我的处理规则是：优先推动老师用Word自带公式编辑器，而不是MathType。

但存量文档里已经用MathType写了不少公式怎么办？兜底方案是：先用MathType自带的导出功能，把文档里的公式批量转为LaTeX（MathType 6.9以上支持批量导出），再在WordPress里用MathJax渲染。或者偷懒一点，直接在转换前用LibreOffice打开docx，把MathType OLE对象转换成Word原生公式，再用Pandoc转MathML，但这个过程偶尔会丢失公式的下标和粗体信息，需要人工抽查。

6.2 老版.doc文件：先用LibreOffice无头模式翻新

老版.doc（Word 97-2003）里可能会有大量悬浮图片、嵌入文本流、文本框，Pandoc对老版.doc支持不足，所以必须先翻新成docx。翻新命令上文提过，用soffice --convert-to docx。翻新后要注意两点：一是LibreOffice转换.doc时可能改变图片路径和格式，最好用专门的doc版本检查；二是生成的docx需要再次检查公式对象是否被正确保留，很多老Word文档里的MathType公式在LibreOffice里会变成图片，而不是保留可编辑结构。

教育行业还有一个特有场景：上级部门下发的红头文件模板是.doc格式，里面的红头、红章、落款都是图片。转存时如果图片被LibreOffice重新采样，红色印章的颜色会偏移，打印出来有偏差。所以凡是涉及盖章文件的处理，尽量保留原始图片格式，不要轻易走Web转换流程，或者过渡性使用高分辨率PNG。

6.3 扫描版PDF与图片型PDF：OCR不能省

学校资料里大量存在扫描版PDF，比如老试卷、印刷教材、手写教案、家长签名确认单。这些PDF本质上就是一张张图片包，Pandoc转换这种PDF时，会直接当作图片处理，整篇可能变成一张巨大的JPG。这种文件直接挂到WordPress上，对访客极其不友好，加载慢、看不清、搜索不到内容。

正确做法是先做OCR，把扫描版PDF识别成可编辑文本，再按文本流程转换。教育行业免费的OCR方案，千兆梯次下主要有Tesseract和PaddleOCR。Tesseract对印刷体中文识别率还行，但面对手写体和复杂版式很吃力，PaddleOCR的识别效果更好，也能直接输出Markdown结构。但OCR再强，碰到涉密文档、学生隐私信息等，系统侧一定要有合规审查流程，最好由管理员和老师双重确认再发布。

OCR后生成的Markdown里，图片仍然是原扫描图，但OCR文本可以作为Alt和Description节点保留，文章的检索价值和可用性会天差地别。我自己处理档案类扫描件时，一定会把OCR文本作为隐藏层存放在文章自定义字段里，既不影响展示，又方便后台搜索。

6.4 批注与修订：发布前的清理规则

很多老师的Word文档里带着批注和修订痕迹，尤其是课题评审、教案互评、教研组长意见这类协作记录。如果直接转换，批注在Markdown/HTML里显示成普通文本，或者被Pandoc跳过，但修订痕迹可能以各种形式残留在正文中。

发布前必须做一次"内容净化"。Word里先"接受所有修订"，再"删除所有批注"；或者用Pandoc的--track-changes=accept参数，自动接受修订。还有一类隐藏信息：文档属性里的作者、单位、创建时间，可能涉及隐私，转换后用Python脚本清理docx元数据，或者导出为HTML时直接丢弃这些字段。

就我看到的情况，教育行业往往最忽视文档清理。很多学校网站上线后，被访客在网页源码里直接看到老师姓名、个人电脑用户名甚至校园网IP信息，完全是转换时没清理元数据导致的。这个坑不大，但补救起来非常被动。

最后再讲一个小经验。在校务系统里处理Word图片兼容，真的不是"装个插件"就能一劳永逸的事，而是要从内容生产、转换处理、运维规范三个层面同时推进。技术手段上，Pandoc加LibreOffice加OCR，能覆盖绝大部分来源的文档；管理手段上，建议学校在信息化制度里明确一条：凡是需要发布到校务系统的Word文档，原则上优先用"另存为HTML"或Markdown导出，再进后台，别让老师直接从Word复制粘贴。这两步配合起来，校务系统的内容质量和后期维护压力会有质的改观。如果你正在搭建或维护教育行业的WordPress站点，希望我这篇经历能帮你少踩几个坑。