PuppeteerSharp 中 CDPSession 处理 StackTrace 的 JSON 解析问题分析

问题背景

在使用 PuppeteerSharp 14.1.0 版本与 .NET 8 配合时，开发者遇到了一个特定场景下的 JSON 解析异常。当目标网页执行 console.info('text') 这样的 JavaScript 控制台日志输出后，PuppeteerSharp 的页面客户端会意外关闭，导致后续操作无法继续。

异常现象

异常发生时，系统会抛出以下错误信息：

Page failed to process Runtime.consoleAPICalled. Error reading string. Unexpected token: StartObject. Path 'stackTrace.parentId'..

错误堆栈显示问题出在 Newtonsoft.Json 对 stackTrace.parentId 字段的解析过程中。开发者期望该字段是一个字符串类型，但实际上接收到的却是一个包含 id 属性的对象结构。

根本原因分析

通过深入研究，我们发现问题的根源在于 PuppeteerSharp 的 StackTrace 类定义与 Chrome DevTools 协议实际返回的数据结构不匹配。具体表现为：

1. 协议定义：根据 Chrome DevTools 协议文档，stackTrace.parentId 应该是一个包含 id 属性的对象结构
2. 当前实现：PuppeteerSharp 中的 StackTrace 类将 ParentId 定义为简单的字符串类型

这种类型不匹配导致了 JSON 反序列化失败。当 Chrome 返回如下结构时：

"stackTrace": {
    "callFrames": [...],
    "parentId": {
        "id": "19"
    }
}

而 PuppeteerSharp 期望的是：

"stackTrace": {
    "callFrames": [...],
    "parentId": "19"
}

解决方案

针对这个问题，社区提出了两种可行的解决方案：

1. 修改数据结构：调整 StackTrace 类的定义，使其 ParentId 属性与实际协议结构匹配
2. 使用灵活类型：将 ParentId 的类型改为 JToken，使其能够处理各种可能的输入格式

最终，PuppeteerSharp 选择了第一种方案，通过更新 StackTrace 类的定义来精确匹配协议规范，这既解决了兼容性问题，又保持了类型安全性。

技术启示

这个案例为我们提供了几个重要的技术启示：

1. 协议一致性：在实现浏览器自动化工具时，必须严格遵循底层协议规范，任何微小的偏差都可能导致难以预料的问题
2. 错误处理：对于可能变化的数据结构，采用更灵活的反序列化策略可以提高系统的健壮性
3. 版本兼容性：即使是次要版本升级，也可能引入新的边缘情况，需要进行充分的测试

总结

PuppeteerSharp 作为 .NET 平台上重要的浏览器自动化工具，其稳定性和可靠性对开发者至关重要。这次问题的发现和解决过程展示了开源社区协作的力量，也提醒我们在使用这类工具时要关注其与底层协议的兼容性。通过及时更新到修复后的版本，开发者可以避免类似问题的发生，确保自动化测试和网页抓取任务的顺利进行。