一份RTF文档在本地文字处理软件里打开时段落分明、字体显示正常，可一旦上传到网站后台预览，字体全部变了样，行距被压得喘不过气，标题和正文糊成一团。多数人的第一反应是文件坏了，于是重新导出再传一次，结果仍然一样。问题常常不出在文件本身，而是RTF从桌面软件走到网页渲染器的这段路上，样式映射出了问题。RTF本质上是一种交换格式，它把字体、段落、字符样式写成一套控制字和样式表，交给接收方按自己的规则去翻译。翻译链条上任何一环对不上，排版就会走形。
首先要核对的是文档声明的字符集与字体表。RTF文件头部一般带有字符集声明和字体表，列出文档用到的字体编号与名称。网页预览环境不一定装了这些字体，渲染器会按替换规则去找相近的字体顶上。如果字体表里只写了一款特定字体、没有备用项，替换结果就难以控制，字宽一变，换行和段落高度也跟着受影响。核对时先看字体表是否完整，再看默认字体缺失后系统给出的替换字体，跟原字体的度量是否接近。
其次要核对段落与字符样式的继承关系。RTF的样式是有层级的，段落样式可以继承基础样式，字符样式又能叠加在段落之上。有些解析器为了省事，会把继承链压平，只保留最终计算值，甚至只留一部分属性。层级一旦被压平，加粗、缩进、对齐这些靠继承得来的属性就容易丢失。检查办法是把同一段文字在原始文档和预览结果里逐项对比段落属性，看哪些属性在解析后不见了，据此判断是继承链断了，还是属性被覆盖了。
第三层要核对页面预览渲染器的样式白名单。浏览器端渲染RTF通常要经过转换，转换器只认一部分RTF控制字，表格边框、制表位、特殊缩进这些属性可能不在支持范围内，碰到不认识的控制字就直接跳过。跳过不会报错，所以表面看文档能打开，实际样式已经缺项。日常维护时可以准备一份包含常见段落与字符属性的测试文档，逐项上传，观察哪些属性留了下来、哪些被丢掉，慢慢形成这套环境的能力清单。
排查顺序建议固定下来：先看字体表是否完整、替换是否合理，再看样式继承有没有被压平，最后看渲染器白名单丢掉了哪些属性。想快速定位，可以构造一份最小复现文档，只留一个标题、一段正文、一处加粗和一处缩进，字体表只写一款常用字体，逐层上传测试。这样能把问题缩小到具体某一层，而不是在完整文档里反复猜。it数运在网站维护实践中也建议保留用户上传的原始样式声明，不在上传环节做过度清洗，以便排版出问题时能回溯到原始控制字，判断是文件声明的问题还是解析环节的问题。把映射链路查清楚，RTF预览的排版问题大多能找到明确出处。
