Tampermonkey服务工作者重启导致通知重复显示问题解析

问题现象

在Tampermonkey浏览器扩展的最新版本中，用户报告了一个关于GM_notification API的异常行为。当使用该API创建通知时，如果设置了超时参数(timeout)，在服务工作者(Service Worker)重启后，通知会重复出现，直到用户手动点击关闭。

具体表现为：开发者使用GM_notification创建带有超时设置的通知后，通知会在首次超时后消失，但随后又会重新出现，形成循环显示的状态。这种异常行为影响了用户体验，特别是对于那些依赖通知功能进行用户交互的脚本。

技术背景

Tampermonkey作为用户脚本管理器，提供了GM_notification API来允许脚本向用户显示桌面通知。在Chrome扩展架构中，通知系统通常与后台页面或服务工作者交互来实现。随着Chrome扩展向Manifest V3迁移，服务工作者取代了传统的后台页面，这带来了新的生命周期管理挑战。

服务工作者是事件驱动的，浏览器可能会根据资源使用情况随时终止和重新启动它们。这种设计提高了浏览器性能，但也要求扩展开发者妥善处理状态保存和恢复。

问题根源

经过分析，这个问题源于服务工作者重启后的状态恢复机制。当服务工作者被终止后重新启动时：

1. 原始通知虽然已经通过超时自动关闭
2. 但服务工作者重启后未能正确识别通知状态
3. 导致系统错误地认为通知需要重新显示

特别是在设置了timeout参数的情况下，这种状态不一致更为明显。服务工作者无法正确追踪已经超时关闭的通知，因此在重启后错误地重新创建了这些通知。

解决方案

Tampermonkey开发团队在beta版本5.3.6216中修复了这个问题。修复方案主要涉及：

1. 改进通知状态跟踪机制
2. 确保服务工作者重启后能正确识别已关闭的通知
3. 优化通知生命周期管理

对于遇到此问题的用户，建议升级到修复后的beta版本。升级方法是通过开发者模式手动安装CRX文件。升级前建议先导出脚本和设置作为备份。

开发者建议

对于Tampermonkey脚本开发者，在使用GM_notification API时应注意：

1. 考虑服务工作者可能随时重启的特性
2. 对于关键通知，实现自己的状态跟踪机制
3. 测试脚本在不同浏览器状态下的行为
4. 及时关注Tampermonkey的版本更新

这个问题的修复体现了浏览器扩展开发中服务工作者生命周期管理的重要性，也为类似问题的解决提供了参考。