Puppeteer-Sharp中RemoveExposedFunctionAsync方法的缺陷与修复

在自动化浏览器测试领域，Puppeteer-Sharp作为.NET平台上的重要工具，提供了丰富的页面操作功能。其中页面函数暴露机制是开发者常用的功能之一，但在实际使用中发现了一个值得注意的问题。

问题背景

Puppeteer-Sharp允许开发者通过ExposeFunctionAsync方法将.NET函数暴露给页面JavaScript环境，这在需要双向通信的场景中非常有用。对应的RemoveExposedFunctionAsync方法则用于移除这些暴露的函数。然而，当前实现中存在一个逻辑缺陷，导致函数无法被完全移除。

问题现象

当开发者尝试以下操作序列时：

1. 暴露一个函数"f"
2. 移除该函数"f"
3. 再次尝试暴露同名函数"f"

第三步操作会抛出异常，提示"window['f'] already exists!"。这表明虽然调用了移除方法，但函数实际上并未被完全清理。

技术分析

深入源码可以发现，问题出在RemoveExposedFunctionAsync方法的实现逻辑上。当前代码使用逻辑与(&&)来判断是否从两个不同的集合中移除了函数绑定：

if (!_exposedFunctions.TryRemove(name, out var exposedFun) && !_bindings.TryRemove(name, out _))

正确的逻辑应该是使用逻辑或(||)，因为我们需要确保从两个集合中都移除相关绑定：

if (!_exposedFunctions.TryRemove(name, out var exposedFun) || !_bindings.TryRemove(name, out _))

影响范围

这个缺陷会影响所有需要动态管理暴露函数的场景，特别是那些需要根据运行时条件反复暴露和移除同名函数的应用。例如：

• 动态功能加载/卸载的系统
• 需要重新初始化页面环境的测试用例
• 热更新功能的实现

解决方案

修复方案相对简单，只需将条件判断中的逻辑与改为逻辑或即可。这一修改确保了：

1. 从暴露函数集合中移除注册
2. 同时从绑定集合中清理相关条目
3. 为后续重新暴露同名函数创造条件

最佳实践建议

在使用暴露函数功能时，开发者应注意：

1. 避免频繁暴露/移除函数，这会影响性能
2. 考虑使用函数版本控制而非简单覆盖
3. 在复杂场景中封装管理函数生命周期的工具类
4. 及时更新到包含此修复的版本

总结

这个案例展示了即使是成熟的开源项目，也可能存在需要改进的地方。理解底层实现机制有助于开发者更好地使用工具，并在遇到问题时能够快速定位原因。对于Puppeteer-Sharp用户来说，关注这个修复将确保页面函数管理功能的正常使用。