Marked 空嵌套引用后面的文字消失，18.0.14 已修正

Markdown 原文里，空的两层引用后面还有一行 text，转换后的 HTML 却只剩引用块。若使用 Marked 18.0.9 至 18.0.13，可以先用这份很短的输入核对丢失位置：

>>
text

预期是空嵌套引用结束后，text 仍作为普通段落保留。受影响路径没有生成该段落；输入扩展为更多引用层，或后面再跟另一段引用时，也可能把后续内容一起吞掉。

先看解析结果有没有这段文字

这条回归发生在 blockquote 的分词阶段。解析器把后续行追加进引用的 raw 范围，却没有确认嵌套引用真正消费了多少内容。外层 lexer 随后按这个范围跳过输入，余下的文字也没有对应 token。

因此，改变 CSS 的 margin、显示方式或段落颜色无济于事。可以在既有受控处理代码中，对同一输入比较 marked.lexer() 的 token 与 marked.parse() 的 HTML。若 token 中已经没有 text，就应先定位解析器；如果 token 和 HTML 都有，而页面不显示，则继续检查后续清洗、模板和样式。

不要在原文后统一加一层引用标记，让“丢掉的字看起来回来了”。那会把本来位于引用外的段落改成引用内容，评论、文档或导出文件的含义随之改变。

18.0.14 已把未消费的尾行留给外层

Marked 18.0.14 的正式发行包含针对空嵌套引用丢失文字的修正；当前正式 18.1.1 也保留了对应处理。嵌套引用重新分词后，解析器会计算尚未消费的尾行，只把实际消费的部分计入 raw，余下输入继续交给外层处理。

沿项目支持范围采用包含修正的版本，并检查最终打包进前端、服务端或文档工具中的实际副本。项目可能有多个 Markdown 转换入口，更新编辑器预览使用的一份，不代表导出任务里的另一份也变化了。

暂时不能更新时，保留原始 Markdown，并限制受影响的转换结果进入正式输出。对自己维护的固定文档可以评估加入明确的空行边界，但要检查它是否改变段落与引用结构，不宜对用户输入批量插入空行来掩盖解析缺陷。

回归对照引用层级与段落位置

最小输入修好后，继续检查 >>> 后的普通文字、空引用前已有正文，以及后面再次出现引用标记的组合。目标不仅是“字符串 text 出现在 HTML 中”，还包括它位于正确的段落和引用层级。

下面只展示最小输入应保留的结构：

<blockquote>
<blockquote>
</blockquote>
</blockquote>
<p>text</p>

已有 renderer 扩展、walkTokens 或 HTML 清洗步骤仍应保留。解析器升级不提供 HTML 安全过滤，也不该为了排查段落丢失而撤掉项目原有的清洗。先比较中间输出，再从原来的预览和导出入口验收，避免只修了演示函数。