一次-source_parser-正文读取测试跑通就是成功

最近在测试一个新流程，核心目的就一个：验证 source_parser 能不能读到正文块。这事听起来简单，但实际跑起来，坑不少。

先交代背景。我们团队最近在重构内容解析管线，其中 source_parser 是关键组件。它的职责是从各种源文格式里提取正文内容，交给下游做结构化处理。之前的老版本有个隐患：对某些非标准格式的正文块识别率不高，导致部分文章正文丢失或截断。这回新版本重点修了这个。

场景是这样的：我新建了一个测试用的源文，内容就是一段普通的正文，没加任何特殊标记。然后本地跑 generate 命令，模拟真实发布流程。整个过程没加任何额外配置，就是走标准流程。

等命令跑完，我去 .state/artifacts 目录看结果。一眼就看到了 xhs 的 json 文件。当时心里就一个念头：成了。

这个 json 文件里，正文块的内容完整保留，和源文一字不差。我逐字段比对过，标题、正文、元数据，全都对得上。尤其让我不放心的是，正文里有几处换行和特殊符号，解析器也没吞，原样保留了。

其实这次测试的门槛不高，关键点在于 source_parser 的解析逻辑能不能覆盖到正文块。之前一直担心，如果解析器只认特定格式，那正文内容可能漏掉。这次结果说明，解析器没掉链子。

跑通就是成功。这话听着像废话，但在测试领域，能验证一个流程跑通，本身就是阶段性胜利。至少证明当前的 source_parser 配置和 generate 流程是匹配的，没有出现预期外的中断或数据丢失。

不过也别高兴太早。这次用的是标准正文，情况比较单纯。真实环境里的正文千奇百怪：有的带 HTML 标签，有的嵌了表格，有的干脆是纯文本加一堆乱码。这些边界情况不测，不敢说稳。

接下来打算再测几个边界情况：

等这些都过了，就可以放心往下游推了。毕竟解析管线一旦断在源头，后面再好的算法也白搭。

有在关注 source_parser 或者相关测试流程的朋友吗？欢迎交流踩过的坑。你们那边解析正文的时候，遇到过什么离谱问题？

📌 发布建议

发布建议：本文适合技术测试、内容解析相关从业者阅读，可作为流程验证的参考记录。发布时可搭配流程图或命令行截图，增强可读性。