一位用户把 PAGES 文稿上传到网站后台，在网页端打开后发现字体变了、行距挤在一起、原本并排的分栏变成上下堆叠，图片也跑到文字中间。这类反馈在网站维护中并不少见。需要先分清一个基本判断：问题出在文件转换环节，还是出在网页渲染环节。转换问题意味着导出的兼容格式本身已丢失排版信息，渲染问题则是文件内容完整但浏览器显示不出来。两者核对方向完全不同，混在一起排查往往越查越乱。
第一层核对文件导出方式。PAGES 是苹果生态的文稿格式，直接在网页端打开并不现实，通常要导出为 PDF 或 DOCX 再上传。导出为 DOCX 时，字体、段落样式、表格边框、页眉页脚都可能发生替换或丢失；导出为 PDF 时版式相对固定，但文字不可再编辑，分栏和文本框的呈现更接近原稿。维护人员应先确认用户上传的到底是哪一种导出文件，再拿原稿与导出件逐页对比，看错位是在导出阶段就已出现，还是上传之后才出现。这一步不做，后面所有排查都缺少基准。
第二层核对字体替换链。网页端没有用户本机安装的字体时，浏览器会按替代顺序寻找可用字体，字宽不同会直接改变换行位置，行距也随之变化。核对时要看原稿使用的字体名称、导出文件中记录的字体、网页端实际加载的字体三者是否一致。若原稿使用了系统自带字体之外的字体，导出后往往被替换为常见字体，分栏宽度和段落高度都会偏移。维护方可以要求用户提供字体清单，或在导出前统一替换为网页端可稳定显示的字体，减少不可控变量。
第三层核对分栏、文本框与图片环绕方式。多栏排版、浮动文本框、文字环绕图片这些布局，在网页端很难原样还原，尤其是导出为 DOCX 后，文本框常被转为普通段落，环绕方式退化为上下排列。核对时应逐项标记哪些元素属于固定版式、哪些属于流式内容。固定版式适合用 PDF 呈现，流式内容适合用网页结构重新排版。把两者混在一个文件里上传，错乱几乎是必然结果。
可执行的核对清单按四步走。文件步：确认导出格式、导出软件版本、原稿与导出件的页数是否一致。字体步：列出原稿字体、导出字体、网页端显示字体，标记替换项。布局步：逐页检查分栏数量、文本框位置、图片环绕方式是否与预期一致。显示步：在常用浏览器和移动端各打开一次，记录差异位置。四步完成后，再判断是要求用户重新导出，还是由维护方调整网页呈现方式。
维护流程上，提前约定上传格式和验收标准比事后逐页修更省力。网站维护方可以在交付说明中写明推荐格式、字体范围和版式限制，并在验收时按上述四步逐项确认。it数运在网站维护的交付检查中，习惯把文件格式、字体替换和布局还原分开记录，避免把转换问题和渲染问题混为一谈。用户上传的文稿类型越多，这套分层核对的价值越明显。
