BilibiliSponsorBlock项目中的fetch代理兼容性问题分析

问题背景

在BilibiliSponsorBlock项目中，最近版本更新引入了一个关于fetch API代理的兼容性问题。该问题主要影响了一些同样运行在B站页面上的第三方插件，特别是那些使用自定义页面或404页面的插件。

问题现象

当其他插件尝试在B站的自定义页面（如某些插件生成的404页面）中使用fetch API时，由于这些页面不存在window.__INITIAL_STATE__对象，而BilibiliSponsorBlock的fetch代理方法直接访问了这个对象，导致整个fetch方法执行中断。

技术分析

问题的核心在于fetch代理的实现方式不够健壮。具体来说：

1. 直接访问问题：代理方法未经检查就直接访问了window.__INITIAL_STATE__对象
2. 错误处理不足：没有对可能的异常情况进行捕获和处理
3. 兼容性考虑不周：没有考虑到其他插件可能运行的页面环境差异

解决方案

针对这个问题，开发者提出了三种可行的解决方案：

1. 前置条件检查：在访问window.__INITIAL_STATE__前先进行存在性检查
2. 选择性代理：先判断window.__INITIAL_STATE__是否存在，再决定是否代理fetch
3. 异常捕获：使用try-catch包裹代理逻辑，出现异常时回退到原始fetch调用

最终，项目维护者选择了修复方案，通过更健壮的实现方式解决了这个问题。

经验总结

这个案例给我们提供了几个重要的开发经验：

1. API代理需谨慎：当代理核心API如fetch时，必须考虑对其他代码的影响
2. 环境假设要验证：不能假设运行环境中一定存在某些全局对象
3. 错误处理要完善：特别是对可能影响其他功能的代码，必须有完善的错误处理机制
4. 兼容性测试重要：新功能上线前需要进行充分的兼容性测试

对开发者的建议

对于开发类似浏览器插件的开发者，建议：

1. 尽量减少对核心API的修改
2. 如果必须修改，确保添加足够的条件检查和错误处理
3. 考虑使用沙箱或隔离的执行环境
4. 在插件文档中明确说明可能的影响范围

这个案例展示了在复杂的前端环境中，即使是看似简单的功能修改也可能产生意想不到的副作用，因此需要开发者保持谨慎和全面的思考。