PuppeteerSharp使用最佳实践及属性、枚举值差异问题咨询

一、PuppeteerSharp 通用最佳实践 #

• 资源复用优先：尽可能复用Browser实例，不要每次请求都重新启动浏览器，单个Browser下创建多个Page实例即可，可大幅减少启动开销。
• 闲置资源及时释放：Page实例使用完后立即调用Dispose()释放，避免内存泄漏，长期运行的服务建议设置Browser实例的定期重启机制，规避Chromium本身的内存溢出问题。
• 按需禁用不必要资源：如果不需要加载图片、样式、字体等资源，可通过SetRequestInterceptionAsync拦截对应类型的请求，能显著提升页面加载速度，降低资源消耗。
• 超时设置合理：不要使用过长的默认超时，针对不同操作（页面加载、元素选择）设置对应的超时时间，避免任务长时间阻塞。
• 避免硬等待：尽量不要用Task.Delay()做等待，优先使用WaitForSelectorAsync、WaitForExpressionAsync等条件等待API，既提升稳定性也减少不必要的等待耗时。
• 生产环境禁用Headful模式：除非有调试需求，否则始终启用无头模式（Headless = true），减少UI渲染的资源开销。

二、EnqueueAsyncMessages 与 EnqueueTransportMessages 属性说明 #

基础定义 #

• EnqueueAsyncMessages：控制是否将异步JavaScript消息（如DOM事件触发的回调、Promise回调返回的消息）加入到内部队列处理，默认值为开启。
• EnqueueTransportMessages：控制是否将底层Chromium DevTools协议的传输消息加入队列批量处理，默认值为开启。

启用禁用时机与性能影响 #

• 保持默认开启即可覆盖99%的使用场景：开启状态下消息处理的顺序性和稳定性更高，不会出现消息丢失或者回调顺序错乱的问题，普通场景下几乎没有可感知的性能损耗。
• 仅在高并发批量处理短任务的场景下可考虑关闭：比如你需要同时跑上百个页面做简单的内容抓取、不需要处理页面内的异步JS回调、也不需要监听DevTools协议事件的场景，关闭两个属性可以减少队列调度的开销，大概能带来10%~20%的吞吐量提升。
• 注意：关闭后如果涉及EvaluateFunctionAsync执行带回调的JS、监听页面事件、调用需要等待DevTools响应的API时，大概率会出现回调不触发、数据返回错乱的问题，没有特殊需求不建议修改默认值。

三、ResourceType 枚举中 Image 与 Img 的差异 #

二者没有本质的语义差异，属于版本迭代过程中的兼容保留项。

• 早期的PuppeteerSharp版本中，对图片资源的枚举值命名为Img，后续为了和Puppeteer（Node.js版本）的API保持一致，新增了Image作为标准命名。
• 目前两个枚举值的底层映射是完全相同的，拦截或者判断图片资源时随便用哪个都能匹配到所有图片类型的请求，后续版本大概率会逐渐废弃Img这个别名，优先使用Image即可。

内容的提问来源于stack exchange，提问作者Trebor678