微信草稿箱 API 内容截断 Bug 报告

日期: 2026-05-11（更新：哨兵测试确认根因）
影响版本: 微信公众平台草稿箱 API (/cgi-bin/draft/add)
严重程度: 高（<section> 容器内末尾 <p> 元素静默丢失）
状态: ✅ 已通过哨兵测试精确定位根因

一、问题描述

这几天用CodeBuddy开发一个Wordpress同步文章到微信公众号的插件，通过微信公众平台草稿箱API (draft/add) 提交图文素材时，HTML内容在PHP端100%完整，但微信编辑器端显示时，<section> 主容器内部的最后一个 <p> 子元素被静默丢弃。

具体现象

原始HTML末尾结构（发送前）：

<section style="...max-width: 100%; ...">  <!-- 主容器 -->
  <!-- ... 中间所有内容 ... -->

  <section style="border-left: 4px solid #409eff;...">
    <span style="font-weight: bold;">最后提醒</span>
  </section>

  <p>如果动手能力不是很强，没有太大问题的机器尽量不要拆解...寿命反而长一点。</p>
  <!-- ↑ 这是主容器内的最后一个 <p> -->

</section>  <!-- 主容器关闭 -->

微信编辑器实际显示（从 test.html ProseMirror DOM 提取）：

<section style="...max-width: 100%; ...">  <!-- 主容器 -->
  <!-- ... 中间所有内容 ... -->

  <section style="border-left: 4px solid #409eff;...">
    <span style="font-weight: bold;"><span leaf="">最后提醒</span></span>
  </section>

  <!-- ❌ <p>如果动手能力...</p> 被静默丢弃！ -->

</section>  <!-- 主容器关闭 -->

“最后提醒” H2标题正确渲染，但其后作为主容器最后一个子元素的 <p> 正文段落被完全丢弃。

二、哨兵测试（关键验证）

为排除”通用的末尾截断”假设，设计了哨兵标记测试：

测试方法

在 process_content_for_wechat() 返回后、发送给API前，在主容器 </section> 外部追加一个哨兵 <p> 元素：

$sentinel = '<p style="display:none;color:red;">[SENTINEL-END-MARK-DO-NOT-DELETE]</p>';
$content = $content . $sentinel;  // 追加到主容器外部

发送结构变为：

┌─────────────────────────────┐
│  <section 主容器>            │
│    ...                      │
│    <section>最后提醒</section>│
│    <p>如果动手能力...</p>    │ ← 主容器内最后元素
│  </section>                  │
└─────────────────────────────┘
│  <p>[SENTINEL]</p>           │ ← 主容器外（哨兵）
└─────────────────────────────┘

测试结果

元素	PHP发送时	json_encode后	微信编辑器中	结果
`<p>如果动手能力...</p>` （主容器内）	✅ 有 (12,438字符)	✅ JSON中有	❌ 丢失	被丢弃
`<p>[SENTINEL]...</p>` （主容器外）	✅ 有 (12,438字符)	✅ JSON中有	✅ 正常保留	不受影响

结论（已100%确认）

这不是通用的”末尾截断”！而是：微信草稿箱API的HTML解析器（或ProseMirror转换层）会静默丢弃 <section> 容器内部紧邻闭合标签前的最后一个 <p> 子元素。容器外的 <p> 不受影响。

数据流示意图：

PHP发送:                    微信接收后:
┌──────────────────┐        ┌──────────────────┐
│ <section 主容器>  │        │ <section 主容器>  │
│   ...            │        │   ...            │
│   <section>提醒</section>│ → │   <section>提醒</section>│
│   <p>正文...</p> │ ──✂──→│   (~~被丢弃~~)   │
│ </section>        │        │ </section>        │
└──────────────────┘        ├──────────────────┤
│ <p>[SENTINEL]</p> │ ─────→│ <p>[SENTINEL]</p> │✅ 正常保留
└──────────────────┘        └──────────────────┘

三、完整追踪证据

3.1 PHP处理流程追踪（`process_content_for_wechat()` 函数内部）

以下为 coco_wechat_trace.log 完整记录（40行，含哨兵测试）：

=== 入口快照 === 长度: 4,386, 含'最后提醒': YES
入口尾部: ...<h2>最后提醒</h2>
<p>如果动手能力不是很强...寿命反而长一点。</p>

--- 第一步(块级清理)后 --- 长度: 4,386, 含'最后提醒': YES ✅
--- 第二步(标题)后 --- 长度: 5,696, 含'最后提醒': YES ✅
--- 第三步(段落)后 --- 长度: 6,284, 尾部含'寿命反而长一点。</p>' ✅
--- 第十步(pre/code)后 --- 长度: 11,831, 尾部含'寿命反而长一点。</p>' ✅
--- 第十五步(清理)前 --- 长度: 12,050, 尾部含'寿命反而长一点。</p>' ✅
  清理前 '最后提醒'后面是否有<p>: YES ✅
  删空<p>后: 长度 12,050, 有<p>: YES ✅
  清空白行后: 长度 12,050 ✅
  移除不支持标签后: 长度 12,050 ✅
  删script/style后: 长度 12,050 ✅
  div→section转换前: div数=0, /div数=0, 尾部完整 ✅
  div→section转换后: 长度 12,050, 有<p>: YES ✅

=== 哨兵测试 === 已在末尾追加哨兵标记，总长度: 12,438

=== 最终校验 === 长度: 12,438 (入口: 4,386, 变化: +8,052), 标签完整性: OK ✅

3.2 发送前追踪（`create_wechat_media()` 函数）

=== 发送前(create_wechat_media) === 
  content长度: 12,438
  最后提醒后有<p>: YES ✅
  含'如果动手能力': YES ✅

发送前 content尾部400字符:
  ...尽量不要拆解，因为MD这东西也算老古董了...最好是时不时拿来听一听，
  寿命反而长一点。</p>
</section><p style="display:none;color:red;">[SENTINEL-END-MARK-DO-NOT-DELETE]</p>

=== json_encode后 === 
  总长度: 13,129 (JSON编码后)
  JSON中含'如果动手能力': YES ✅

json_encode后 content尾部400:
  ...尽量不要拆解，因为MD这东西也算老古董了...寿命反而长一点。<\/p>
<\/section><p style=\"display:none;color:red;\">[SENTINEL-END-MARK-DO-NOT-DELETE]<\/p>

3.3 微信编辑器返回内容（从 test.html 第387行提取）

<!-- ProseMirror 编辑器中的实际DOM结构（已简化）-->
<section class="ProseMirror" style="...">
  <section><!-- 主容器 max-width:100% ... -->    
    <!-- ... 中间所有内容均正常 ... -->

    <!-- "最后提醒" 标题 - 正常渲染 ✅ -->
    <section style="margin: 18px 0 12px 0; padding-left: 12px; border-left: 4px solid #409eff; ...">
      <span style="font-size: 17px; font-weight: bold;"><span leaf="">最后提醒</span></span>
    </section>

    <!-- ❌ 缺失：<p>如果动手能力...</p> 不存在！ -->

  </section>  <!-- 主容器关闭 -->

  <!-- ✅ 哨兵标记 - 出现了！（证明不是通用末尾截断） -->
  <p style="display:none;color:red;"><span leaf="">[SENTINEL-END-MARK-DO-NOT-DELETE]</span></p>

</div>  <!-- 编辑器根关闭 -->

四、数据流分析

┌─────────────────────────────────────┐
│ WordPress 原始 post_content         │  4,386 字符
│ 含 <h2>最后提醒</h2> + <p>段落</p>  │  ✅ 完整
└──────────────┬──────────────────────┘
               ▼
┌─────────────────────────────────────┐
│ process_content_for_wechat()        │
│ 15步格式化处理 + 哨兵追加            │
│ 每步追踪: 内容完整, 有"如果动手能力" │  ✅ 全部通过
└──────────────┬──────────────────────┘
               ▼ 返回 12,438 字符（含哨兵）
┌─────────────────────────────────────┐
│ create_wechat_media() 发送前检查    │  12,438 字符
│   - 最后提醒后有<p>: YES            │  ✅
│   - 含"如果动手能力": YES           │  ✅
│   - 含[SENTINEL]: YES               │  ✅
└──────────────┬──────────────────────┘
               ▼
┌─────────────────────────────────────┐
│ json_encode($draft_data) 后          │  13,129 字符
│ JSON字符串中含"如果动手能力": YES    │  ✅ 完整
│ JSON字符串中含[SENTINEL]: YES       │  ✅ 完整
└──────────────┬──────────────────────┘
               ▼ wp_remote_post() 发送
┌─────────────────────────────────────┐
│ ★ 微信草稿箱 API ★                  │
│ POST /cgi-bin/draft/add             │  ← 问题发生在此处
│ 响应: {"media_id":"xxx"} HTTP 200    │
└──────────────┬──────────────────────┘
               ▼ 用户在微信后台打开草稿
┌─────────────────────────────────────┐
│ 微信编辑器 (ProseMirror) 渲染       │
│ test.html 实际DOM                   │
│                                     │
│  主容器内 <p>如果动手能力...</p>     │  ❌ 丢失
│  主容器外 <p>[SENTINEL]</p>         │  ✅ 保留
└─────────────────────────────────────┘

关键结论: 内容离开PHP环境时100%完整（包括主容器内和外的所有<p>），json_encode()也未截断。问题发生在微信草稿箱API的HTML解析/存储阶段，且仅影响 <section> 容器内部的末尾 <p> 子元素。

五、技术细节

5.1 发送给微信API的实际JSON（尾部片段）

{
  "articles": [{
    "title": "...",
    "content": "<section style=\"max-width: 100%; font-family: ...\">\n  ...\n  <section style=\"...border-left: 4px solid #409eff;...\"><span style=\"...font-weight: bold;\">最后提醒</span></section>\n<p>如果动手能力不是很强，没有太大问题的机器尽量不要拆解...寿命反而长一点。</p>\n</section>\n<p style=\"display:none;color:red;\">[SENTINEL-END-MARK-DO-NOT-DELETE]</p>",
    ...
  }]
}

5.2 被丢弃内容的特征

特征	值
标签类型	`<p>` （普通段落）
所在位置	`<section>` 主容器的最后一个直接子元素
前一个兄弟元素	`<section>` （H2样式的”最后提醒”标题）
父元素	`<section style="max-width:100%; ...">` （主容器）
文字长度	约150个中文字符
特殊属性	无（纯文本`<p>`标签）

5.3 保留内容的特征（哨兵）

特征	值
标签类型	`<p>` （与被丢弃的相同）
所在位置	`<section>` 主容器的外部（兄弟元素）
文字内容	`[SENTINEL-END-MARK-DO-NOT-DELETE]`
CSS属性	`display:none; color:red;`
结果	✅ 正常保留

5.4 对比结论

唯一区别在于 <p> 是否位于 <section> 主容器的闭合标签之前（即作为最后一个内部子元素）。

六、复现条件

最小复现路径

构造一篇HTML文章，满足以下条件：

<section style="任意样式">
 <!-- 中间可以有任意内容 -->
 <section>某个标题</section>
 <p>这段文字会被丢弃！！！</p>
</section>

通过微信草稿箱API提交：

POST https://api.weixin.qq.com/cgi-bin/draft/add?access_token=xxx
Content-Type: application/json

{
 "articles": [{
   "title": "测试",
   "content": "<section>...<section>标题</section><p>会被丢弃的段落</p></section>"
 }]
}

在微信公众号后台打开草稿，观察末尾段落是否存在

复现的关键条件

条件	是否必须	说明
`<p>` 必须是 `<section>` 的最后一个子元素	✅ 是	核心触发条件
前一个兄弟是 `<section>` 或其他块级元素	⚠️ 可能	当前案例如此，待更多验证
`<section>` 嵌套层级	⚠️ 待验证	当前约3-4层
内容总长度	❌ 否	哨兵证明不是长度限制
`<p>` 的具体样式/属性	❌ 否	被丢弃的`<p>`无特殊属性

环境信息

项目	值
PHP版本	8.x
WordPress	最新版
API端点	`https://api.weixin.qq.com/cgi-bin/draft/add`
Content-Type	`application/json; charset=utf-8`
编码	UTF-8, `JSON_UNESCAPED_UNICODE`
编辑器引擎	ProseMirror（微信公众号后台）

七、建议微信团队排查方向

方向1：API服务端 HTML 解析器（最可能的原因）

微信草稿箱API接收到JSON后，会对HTML进行服务端解析和清洗。根据哨兵测试结果，高度怀疑此处存在bug：

重点排查：HTML解析器在处理 </section> 闭合标签时，是否会错误地”吸收”或丢弃前一个 <p> 兄弟节点？
是否使用了类似 htmlparser2、cheerio、jsdom 等库？这些库在某些边界情况下有已知问题
解析器是否将 </section> 前的 <p> 误判为”空段落”或”冗余标签”而过滤掉？

方向2：ProseMirror 序列化/反序列化

即使API存储的内容正确，ProseMirror从HTML转为内部document模型时可能丢数据：

验证方法：调用 draft/batchget 接口获取已保存的原始content字段，比对是否在存储时就已缺失
ProseMirror的 schema 中对 <section> 内部 <p> 作为最后一个子节点是否有特殊处理？

方向3：DOM 规范化/清洗逻辑

微信可能对提交的HTML做了额外的 sanitize 操作：

是否有去除”尾部空白段落”的逻辑？但本例中的 <p> 包含150字非空内容
是否对连续的块级元素有合并/优化策略误伤了有效内容？

八、临时规避方案

在微信修复此问题前，推荐以下workaround：

方案A：在主容器末尾添加保护元素（已验证可行 ✅）

在 <section> 主容器的内部最后追加一个不可见的占位元素：

// 在主容器闭合前追加一个空的 section 或其他非 <p> 元素
$content = $content . '<section style="height:0;overflow:hidden;line-height:0;"></section>';
// 这样原来的 <p> 就不再是"最后一个子元素"了

或者更简洁的方式——确保最后一个子元素不是 <p>：

<section style="主容器样式">
  ...
  <section>最后提醒</section>
  <p>这段不会被丢了</p>  <!-- 不再是最后一个子元素 -->
  <br/>  <!-- 或者加一个保护用的空元素 -->
</section>

方案B：将被丢弃的 `<p>` 用 `<section>` 包裹

<section style="主容器样式">
  ...
  <section>最后提醒</section>
  <section><p>用section包裹就不会被丢</p></section>
</section>

方案C：使用 `draft/get` 接口做发送后校验

提交草稿后立即调用 draft/get 获取内容，比对正文字数是否匹配，不匹配则报警。

九、附件

文件	说明
`coco_wechat_trace.log`	PHP端完整处理追踪日志（40行，含哨兵测试）
`test.html`	微信公众号后台草稿箱页面的完整HTML（1347行）
`coco-wechat-sync.php`	WordPress插件源码（格式化+同步逻辑）

十、联系方式

如有需要进一步配合排查，可通过以下方式联系：

项目仓库: coco-wechat-sync (WordPress微信同步插件)
Bug涉及接口: POST /cgi-bin/draft/add （草稿箱新增接口）
测试账号: 可配合提供测试公众号进行复现

Post Views: 17

可可知秋

微信公众号草稿箱 API 内容截断 Bug

微信草稿箱 API 内容截断 Bug 报告

一、问题描述

具体现象

二、哨兵测试（关键验证）

测试方法

测试结果

结论（已100%确认）

三、完整追踪证据

3.1 PHP处理流程追踪（`process_content_for_wechat()` 函数内部）

3.2 发送前追踪（`create_wechat_media()` 函数）

3.3 微信编辑器返回内容（从 test.html 第387行提取）

四、数据流分析

五、技术细节

5.1 发送给微信API的实际JSON（尾部片段）

5.2 被丢弃内容的特征

5.3 保留内容的特征（哨兵）

5.4 对比结论

六、复现条件

最小复现路径

复现的关键条件

环境信息

七、建议微信团队排查方向

方向1：API服务端 HTML 解析器（最可能的原因）

方向2：ProseMirror 序列化/反序列化

方向3：DOM 规范化/清洗逻辑

八、临时规避方案

方案A：在主容器末尾添加保护元素（已验证可行 ✅）

方案B：将被丢弃的 `<p>` 用 `<section>` 包裹

方案C：使用 `draft/get` 接口做发送后校验

推荐：方案A

九、附件

十、联系方式

发表回复取消回复

微信草稿箱 API 内容截断 Bug 报告

一、问题描述

具体现象

二、哨兵测试（关键验证）

测试方法

测试结果

结论（已100%确认）

三、完整追踪证据

3.1 PHP处理流程追踪（process_content_for_wechat() 函数内部）

3.2 发送前追踪（create_wechat_media() 函数）

3.3 微信编辑器返回内容（从 test.html 第387行提取）

四、数据流分析

五、技术细节

5.1 发送给微信API的实际JSON（尾部片段）

5.2 被丢弃内容的特征

5.3 保留内容的特征（哨兵）

5.4 对比结论

六、复现条件

最小复现路径

复现的关键条件

环境信息

七、建议微信团队排查方向

方向1：API服务端 HTML 解析器（最可能的原因）

方向2：ProseMirror 序列化/反序列化

方向3：DOM 规范化/清洗逻辑

八、临时规避方案

方案A：在主容器末尾添加保护元素（已验证可行 ✅）

方案B：将被丢弃的 <p> 用 <section> 包裹

方案C：使用 draft/get 接口做发送后校验

推荐：方案A

九、附件

十、联系方式

发表回复 取消回复

3.1 PHP处理流程追踪（`process_content_for_wechat()` 函数内部）

3.2 发送前追踪（`create_wechat_media()` 函数）

方案B：将被丢弃的 `<p>` 用 `<section>` 包裹

方案C：使用 `draft/get` 接口做发送后校验

发表回复取消回复