公众号草稿列表出现空项？微信新编辑器把空白解析成了列表项

先说结论：如果你的公众号草稿在后台里出现“奇数编号全空”“列表里夹着一堆空项”这类现象，问题通常不在正文内容本身，而在 HTML 标签之间残留了会被微信新编辑器当成文本节点的空白。 当这些空白正好落在 li、ol、ul 一类列表结构附近时，编辑器会把它们重新解释成空列表项，于是后台看起来像“每隔一项就空一次”。

这不是一个纯视觉小 bug，而是一个会直接影响发稿效率的问题：你在本地预览、网页预览、甚至其他平台里都可能看不出异常，只有进了公众号后台草稿列表或编辑器视图才露出来。对要把官网文章同步到多个平台的团队来说，这意味着“Markdown 能渲染”不等于“微信编辑器能稳定接收”。OmniGoAI 的 OmniPost 在处理公众号稿件时，核心价值之一就是把这类平台特有问题提前暴露出来，而不是等到运营同学进后台才发现整篇排版坏掉。

为什么公众号会把空白变成空列表项？

原因在于微信新编辑器不是简单地把 HTML 原样展示出来，而是会做一轮自己的导入、归一化和重建。对浏览器来说，标签之间的换行、缩进、空格往往只是“可忽略空白”；但对编辑器型系统来说，这些空白有时会先被保留成文本节点，再在导入列表结构时被误判成一个需要占位的条目。

最容易出问题的场景通常有三个：

1. 列表标签之间保留了格式化缩进与空行；
2. Markdown 转 HTML 后，li 内外混入了多余换行；
3. 上游清洗器把本该贴紧的标签拆成了“标签 + 空白 + 标签”。

于是你最后看到的不是“内容少了一段”，而是：

1. 第 1 项空白；
2. 第 2 项正常；
3. 第 3 项空白；
4. 第 4 项正常。

这类“奇数编号全空”的现象，本质上说明编辑器在重建列表时把空白节点也算成了列表成员。

为什么这个问题在别处不明显，偏偏在公众号后台才爆出来？

因为大多数 Markdown 预览器和网站前端只负责“显示结果”，不会像公众号编辑器那样再做一次内容导入。浏览器对空白的容忍度很高，所以你在官网、本地 Markdown 预览器，甚至知乎、CSDN 这类技术平台里都可能看起来没问题。

但公众号后台不是单纯的渲染终点，它更像一个“二次编辑环境”。内容进入后台后，系统会重新理解段落、列表、图片和卡片结构。也正因为如此，公众号相关问题经常呈现出这种特征：

• 官网预览正常；
• 通用 HTML 预览正常；
• 进公众号草稿后异常；
• 人工在后台删删改改又能临时修好。

如果你之前还遇到过公众号 API 草稿、封面上传或外链审查问题，这种体验会更明显。我们之前写过两篇相关文章：一篇解释公众号 API 建草稿常见前置条件，另一篇讲公众号外链规则与“先草稿、后人工终审”的必要性。这次的“空列表项”问题属于同一类：不是正文意思错了，而是微信编辑器的接收边界和普通网页不同。

哪些写法最容易触发“奇数编号全空”？

下面这些写法风险最高：

1. 过度美化的 HTML 缩进

为了让源码更漂亮，很多渲染器会输出类似这样的结构：

<ol>
  <li>第一步</li>
  <li>第二步</li>
</ol>

在正常浏览器里这没问题，但如果后续某个清洗环节又插入了额外空行，微信编辑器可能把这些空白当成独立节点。

2. Markdown 和 HTML 混写

比如列表里夹 <p>、<div>、自定义 span，或者先从富文本复制再回贴 Markdown。这会让导出结构变得比你想象中更复杂，也更容易在 li 外围留下无意义空白。

3. 预处理器“保留语义空白”

有些清洗器为了避免误伤文本，会保留标签间空白。对网页端这是宽松策略，对公众号编辑器却可能是风险输入。

最稳的修复思路是什么？

把列表结构压紧，让真正的列表项彼此直接相邻。 具体做法通常比“手工去公众号后台删空行”更可靠：

1. 在进入公众号前，先检查列表相关 HTML 是否存在标签间空白；
2. 对 ol > li、ul > li 一类结构做最小化清理，只删结构性空白，不动正文文字；
3. 不要把富文本残片和 Markdown 列表混在一起；
4. 每次改完后都重新进公众号草稿视图核对一次，而不是只看网页预览。

工程上最重要的一点是：不要把“空白”当作纯格式问题。 在公众号链路里，空白有时已经变成数据了。

这对多平台分发流程意味着什么？

它说明“一个 Markdown 走天下”在现实里并不成立。技术社区、官网、英文平台与公众号编辑器的接收边界都不同。真正稳定的流程应该是：

1. 先在官网保留语义清晰、结构规范的原始稿；
2. 针对微信这类高风险编辑器做额外清洗；
3. 用平台预览或草稿视图做最后核对；
4. 再决定是否正式发布。

这也是为什么我们会把官网发布、搜索收录与平台分发拆成多个步骤，而不是一把梭地把同一份 HTML 原样灌到所有地方。对公众号来说，“可导入”本身就是一层独立验收标准。

如果你在做多平台同步，OmniPost 这类本地优先分发工具的价值，不只是“帮你发出去”，而是帮你在真正发出去前识别平台差异、保留草稿与排查线索。否则一旦后台才发现列表全乱，问题就已经落到运营同学身上了。

发布前怎么快速自检？

你可以用下面这份简化清单：

1. 列表是否来自纯 Markdown，而不是 Markdown + 富文本混贴；
2. HTML 清洗后，ol / ul 与 li 之间是否还残留大段缩进空白；
3. 公众号草稿视图里是否出现交替空项；
4. 如果出现，能否通过压紧列表结构稳定复现并修复；
5. 修复后再检查封面、摘要和外链合规，不要只盯正文。

常见问题

FAQ 1：为什么官网预览正常，公众号后台却有空列表项？

因为官网和普通浏览器只负责渲染，而公众号后台会重新导入并重建内容结构。某些在浏览器里可忽略的空白，在微信编辑器里会被当成节点处理。

FAQ 2：这是 Markdown 的锅，还是微信编辑器的锅？

更准确地说，是两者边界不一致。Markdown/HTML 产物对网页端有效，不代表对微信编辑器的导入逻辑同样安全。

FAQ 3：手工删掉公众号后台里的空项就够了吗？

短期能救急，但不稳。只要下次导入链路没改，问题还会再出现。更可靠的办法是在进入公众号之前就把列表结构压紧，并保留可复现的清洗规则。

FAQ 4：技术平台也会这样吗？

通常没有公众号这么敏感。知乎、CSDN、掘金、博客园更接近“内容展示平台”，而公众号后台是更强的“编辑器导入环境”，所以差异最明显。

FAQ 5：如果我要同时发官网、知乎、CSDN 和公众号，应该怎么排顺序？

先发官网原始稿，再针对各平台做改写或清洗；公众号放在高风险链路单独核对。需要统一管理这些版本时，可以用 OmniPost 处理分发与草稿流转。下载地址：<https://omnigoai.com/zh/download/omnipost/>。