gumbo-parser是纯C99实现的HTML5解析器，无外部依赖、通过全部html5lib测试，但需手动遍历GumboOutput*校验，易因漏调gumbo_destroy_output致内存泄漏，且root外还包一层GUMBO_NODE_DOCUMENT节点。
html-ppt-to-pdf
将使用 `` 约定的 HTML 幻灯片转换为高保真、矢量文本 PDF（使用 Playwright + Chromium 原生 PDF 功能）。
下载
gumbo-parser 是目前最接近 HTML5 规范的 C 语言解析器，纯 C99 实现、无外部依赖、通过全部 html5lib 测试。它不是“拿来即用”的测试工具，而是为自动化测试提供底层解析能力的库——所有测试逻辑（断言、覆盖率、错误注入）都得你自己用
GumboOutput* 结构遍历和校验。常见踩坑点：忘记调用
gumbo_destroy_output 导致内存泄漏；误把
output->root 当作文档根元素，其实它外面还包了一层
GUMBO_NODE_DOCUMENT 节点。
requests-html 适合 Python 快速验证场景，封装了
PyQuery +
lxml，支持 CSS/XPath 定位、JavaScript 渲染（基于 Chromium）、异步请求。但注意：它的
.html 属性返回的是懒加载对象，首次访问才真正解析；若页面含大量动态内容，
.render() 默认超时 8 秒且不重试，容易在 CI 中偶发失败。真实 E2E 测试中，它更适合做“预检”而非主断言引擎。
HtmlAgilityPack 是 .NET 生态里最成熟的选项，支持 LINQ to HTML、XPath、XSLT，对畸形 HTML 容错极强（比如自动闭合缺失标签、修复嵌套错误）。但它默认不校验 HTML5 语义，例如
<main></main> 或
<dialog></dialog> 标签会被当作普通元素处理；若测试目标是规范符合性，需额外加
HtmlDocument.OptionUseHtml5Parser = true 开关，否则 DOM 结构可能与浏览器不一致。
jsdom 不是传统意义的“HTML 解析器”，而是 Node.js 环境下的 DOM 实现。它本身不解析 HTML，而是靠内置的
parse5（可替换）完成解析，再构建完整 DOM 接口。优势在于能直接运行被测页面的 JS 逻辑，适合测试组件生命周期、事件响应等；劣势是
IntersectionObserver、
ResizeObserver 等 API 默认不可用，必须手动 mock，否则测试会静默跳过关键路径。
真正决定测试可靠性的，从来不是解析器本身有多“准”，而是你是否控制了输入边界、是否清理了副作用、是否覆盖了错误恢复路径。比如用
gumbo-parser 测试自闭合
<div></div>，预期不是崩溃，而是生成 8 个
output_->errors 条目——这个“错误数量”才是可断言的契约，不是 DOM 树长得像不像。
