同一份Markdown文件，在本地编辑器中标题层级分明、列表缩进整齐、代码块带底色，上传到网站后台预览时却变成一整段挤在一起的文字，井号原样露出，列表缩进消失，代码块也没有背景色。遇到这种情况，先别急着怀疑文件损坏。从文件保存到页面呈现，中间要经过编码读取、解析转换、服务端过滤、前端渲染和样式应用等多个环节，任何一层理解不一致，格式都可能丢失。下面按处理顺序逐层核对。
第一层：文件编码与换行符
Markdown本质上是纯文本，编码决定了字符如何被读取。如果文件保存为GBK或GB18030，而网页端按UTF-8解析，中文可能乱码，井号、星号等标记符号也可能被误判。更隐蔽的是BOM头，部分编辑器保存UTF-8时会自动加上字节顺序标记，解析库若未跳过它，第一个标题符号前会多出不可见字符，导致整行无法识别为标题。换行符同样要留意，Windows用回车加换行，Linux和macOS用换行，某些解析器对单独的回车不敏感，会把两行合并成一行。核对方法是用十六进制查看器确认文件开头是否有BOM，并统一保存为无BOM的UTF-8，换行符统一为换行。
第二层：前端解析库版本与语法扩展支持范围
标准Markdown只定义基础语法，表格、任务列表、脚注、删除线属于扩展语法，不同解析库和不同版本支持程度不同。同一份文件在旧版本里可能把表格识别成普通段落，把任务列表的方括号原样输出。核对时要确认当前使用的解析库名称和版本，查看其文档中明确支持的语法列表，并测试一份包含标题、有序列表、无序列表、代码块、表格、链接的样本文件。若业务需要扩展语法，应在解析配置中显式开启对应插件，而不是假设默认全部支持。
第三层：服务端转义与过滤规则
很多网站在存储用户内容前会做安全过滤，把尖括号、引号、反斜杠等字符转义为实体。如果过滤发生在Markdown解析之前，原本用于表示代码块的反引号或用于表示引用的尖括号可能被改写，解析器读到的已不是原始标记。更常见的是过滤规则把连续空格或制表符压缩，导致列表缩进层级失效。核对方法是取一份原始文件，分别查看入库前、入库后、输出到页面前的三个版本，对比关键符号是否被改动。安全过滤应当放在解析之后，或者使用能识别Markdown语法的过滤策略，避免误伤格式标记。
第四层：样式表对渲染结果的覆盖
解析正确不代表显示正确。全局样式可能把标题的上下边距清零，把列表的项目符号隐藏，把代码块的等宽字体替换为普通字体，导致视觉上像没有格式。常见冲突包括标题字号与正文相同、列表符号被列表样式设为无、代码块背景色被覆盖、段落行高过小使内容挤在一起。核对时用浏览器开发者工具查看渲染后元素的标签和计算样式，确认标题是否生成了对应标签，列表是否保留了项目符号，代码块是否应用了等宽字体和背景。样式层的问题通常只需调整几条规则，但排查时容易被忽略。
上线前的四步自查
第一步，确认文件为无BOM的UTF-8，换行符统一。第二步，确认解析库版本和扩展语法配置与文件实际使用的语法匹配。第三步，确认服务端过滤规则在解析之后执行，且不压缩缩进和关键符号。第四步，确认样式表没有隐藏标题层级、列表符号和代码块样式。按这个顺序核对，多数渲染错乱都能定位到具体环节。it数运在网站维护中处理这类问题时，也会先固定文件样本和解析链路，再逐层比对，避免在错误的层反复修改。
