有用户反馈，一份在本地编辑好的ODP演示文稿上传到网站后，标题字体变成了默认黑体，正文行距也跟着变了。打开原文件一切正常，网页预览却像换了一份稿子。这类问题在ODP格式上并不少见，因为它属于开放文档格式，不同软件对字体资源的处理方式并不统一，网页预览环节一旦接不上，字体替换就会发生。
第一层要核对的是文件本身有没有真正嵌入字体。很多编辑软件默认只记录字体名称，不打包字体文件，看起来设置了字体，实际文件里只有一句声明。判断方法不复杂，把ODP解压后查看内部结构，若存在字体资源目录且体积明显增加，说明字体随文件携带；若只有内容与样式描述，字体名只是引用。仅引用字体名的文件，到了没有该字体的环境里必然被替换。
第二层要核对预览服务端的可用字体列表。文件声明了某款字体，服务端没装，替换就会启动。常见缺失集中在几类：商业字库字体、系统自带但版本不同的中文字体、以及名称相近容易混淆的字体族。检查时先导出文件里实际声明的字体名，再与服务端已安装列表逐项比对，重点看替换顺序，确认系统是按字体族回退还是直接跳到默认字体。
第三层要核对渲染引擎对ODP字体映射规则的支持差异。同一份文件在不同环境显示不同，往往是映射规则理解不一致。验证方法是准备一份含多种字体的测试稿，在本地软件、网页预览、导出图片三个环境分别打开，记录每处文字的实际显示字体，差异点就是映射规则的冲突位置。对比时保持文件不变，只换环境，才能定位是引擎问题还是文件问题。
把三层串起来，可以整理成一份排查清单。先看文件是否携带字体资源，再看服务端字体列表是否覆盖声明，最后看渲染端映射是否一致，顺序不要颠倒，否则容易在错误的一层反复修改。it数运在网站维护中处理这类上传预览问题，通常也是按文件、服务端、渲染端逐层确认，先排除文件自身原因，再动环境配置，避免改了半天配置却发现源头在文件里。
给几条可执行建议。上传前用解压方式自检字体是否真正嵌入，重要文稿尽量使用服务端已覆盖的字体；为预览服务建立字体白名单，明确哪些字体可用、缺失时如何回退；同时保留原始文件下载入口，预览显示不理想时用户仍能拿到完整文件自行打开。三层核对加上兜底通道，ODP字体错乱大多能定位到具体环节。
