浏览器源更新后为何一次打赏会触发两个提醒

为什么一次打赏会触发两个提醒

浏览器源更新后，页面会重新启动。脚本会再次连接服务器、订阅事件，并创建用于显示通知的处理函数。如果旧的处理函数没有被移除，或者同时有两个连接在工作，那么一个打赏事件就会被处理多次。

更新本身并不一定是故障的原因。它往往只是让连接逻辑中的错误暴露出来。例如，初始化函数可能会在页面加载时运行一次，在恢复连接时再运行一次，并且在收到服务消息后再运行一次。每次运行都会新增一个对 donation 事件的订阅。

结果就是服务器只发送一个打赏对象，但浏览器却调用了同一个函数两次。有时重复发生在服务器端：应用把新连接视为单独的接收方，把事件同时发送给旧会话和新会话。因此，首先需要确定重复出现在哪里：是在源、在处理函数，还是在显示阶段。

如何定位重复产生的位置

先做一个简单的测试。在单独的窗口或标签页中打开浏览器源链接，只保留一个页面实例，然后发送一个测试事件。如果提醒只出现一次，原因很可能与场景设置或源的多个实例有关。如果在单独的标签页中就已经重复，那就检查页面代码和订阅机制。

把打赏处理分成几个阶段会很有帮助：接收事件、校验事件、将提醒加入队列、渲染。可以在日志或控制台中临时在每个阶段输出标记。如果接收记录出现了两次，问题就出在视觉层之前。如果事件只接收了一次，但队列中有两个元素，错误就在处理函数中。如果队列只有一个元素，而屏幕上有两个提醒，那就检查显示函数和 HTML 容器。

为了诊断，如果打赏数据中传了标识符，就为每个事件附上它的标识符。在接收时和显示前都记录这个标识符。两次调用中出现相同的标识符，说明同一个事件被重复处理了。两个不同的标识符则说明有两次投递，需要分别排查。

不要只检查标签页数量。在 OBS 中，复制场景、添加嵌套场景，或者用同一个地址重复添加浏览器源，都可能产生两个实例。有时一个源留在单独的图层中，另一个又被添加到它上面。视觉上看起来像是双重提醒，尽管事件只来了一次。

重连后的重复订阅

最常见的原因是：每次连接时都会添加处理函数，但断开时没有移除。简化来看，问题是这样：函数执行 socket.on 并传入显示提醒的处理函数，然后连接中断，应用重新连接并再次执行 socket.on。此后，一个收到的打赏就会调用两个函数。下一次重连后，可能会变得更多。

同样的错误也会出现在普通的 addEventListener 中。如果初始化函数被调用多次，浏览器就会为同一个事件添加多个监听器。检查“初始化已执行”的标志并不总是有效：完整刷新页面时变量会被重置，而在同一页面内重连时问题依然存在。

订阅应该在连接的生命周期内只创建一次，并且在新订阅之前显式移除旧订阅。对于事件处理函数，使用 removeEventListener，并传入与连接时相同的函数引用。对于带套接字的库，通常需要 off、unsubscribe 或类似的取消订阅方法。

套接字的最小方案可能如下：const onDonation = data => showAlert(data); socket.off('donation', onDonation); socket.on('donation', onDonation); function cleanup() { socket.off('donation', onDonation); window.removeEventListener('beforeunload', cleanup); socket.close(); } window.addEventListener('beforeunload', cleanup);

这里重要的不是具体的库，而是操作顺序。处理函数保存在变量中，因此可以用同一个引用移除它。在新订阅之前先删除旧的，在页面关闭或源停止时执行 cleanup。如果每次运行都创建新的套接字，必须先关闭旧的，然后再创建新的。否则两个连接可能都会继续接收相同的数据。

重连时也要关闭旧连接并清除相关的定时器。否则旧的套接字可能在新的已经工作时仍在接收数据。如果代码启动了新的重连定时器却没有取消之前的，这种情况尤其常见。

在 OBS 和浏览器源中要检查什么

如果单独窗口只显示一次提醒，那就转到场景。停止预览，临时删除多余的图层，只保留一个浏览器源。然后在目标场景中检查行为。这个测试比同时检查所有场景和滤镜要快。

• 查找两个使用相同页面地址的源。
• 检查场景副本和嵌套场景，那里可能包含同一个叠加层。
• 确认提醒没有同时由浏览器源和另一个使用同一页面的图层输出。
• 更改设置后要完全重启源，而不只是切换场景。

有时在更新 URL 或参数后，OBS 中会残留旧的浏览器源标签页。关闭并重新添加源有助于验证这个假设，但这不能替代修复代码。如果每次更新后问题都会重现，就要查找处理函数的重复注册或双重连接。

还要考虑断开延迟。更新时旧会话可能不会立即关闭。如果服务器在几秒钟内仍认为它处于活动状态，那么在这个间隙到达的事件可能会落入两个会话。正常的服务器逻辑应该移除不活动的连接，并在页面关闭后不保留订阅。

防止同一事件重复投递

即使浏览器源工作正常，同一个事件有时也可能被重复投递。在恢复连接、重新发送消息，或者接收事件与确认处理之间发生故障时，这种情况都有可能发生。因此，提醒处理函数必须能够抵御重复。

最好的方法是校验打赏的唯一标识符。在将事件加入队列之前，把它的标识符保存到已处理事件的集合中。如果这个标识符已经出现过，就应跳过这次重复。列表应只保留有限的时间，以免无限增长。

不要只用金额、发送者名称或消息文本来做这件事。两笔不同的打赏可能具有相同的数据。按时间校验也不可靠：几笔不同的打赏可能在几乎同一时刻到达。如果没有标识符，可以临时比较字段组合和时间，但这是有风险的备用方案，可能会错误地合并两个事件。

防重复机制应该放在显示提醒之前，而不是放在动画内部。否则第二次调用仍然会向页面添加元素、播放声音或再向队列添加一条记录。要单独控制队列：一个事件应该只被加入一次，重复调用不应启动第二个独立的队列。

如果事件在多个标签页或组件之间传递，要检查是否有多个接收方同时处理它。一个共享的消息通道可能连接到了多个处理函数。在这种情况下，要么只保留一个消费者，要么明确定义由哪个组件负责显示提醒。

为什么清缓存并不总是有效

浏览器源更新后，常常会建议清除缓存。如果加载的是旧版本的脚本，这可能会有帮助，但缓存不会移除正在运行页面中的多余处理函数，也不会关闭源的第二个副本。如果每次重连后重复都稳定出现，原因几乎肯定在连接逻辑或场景结构中。

检查是否确实加载了新版本的文件。临时更改资源地址，或使用预设的更新机制，然后重启浏览器源。之后再用一个窗口和一个源实例重新测试。不要长期给链接添加随机参数：这可能会产生大量缓存变体，让诊断变得复杂。

如果使用了中间缓存或 service worker，它也可能返回过时的脚本。在这种情况下，比较已加载文件的版本和你期望看到的版本。但即使是旧文件，也需要消除重复订阅的原因，否则下次更新后问题还会再次出现。

在提醒代码中要检查什么

首先找出所有调用 socket.on、addEventListener、连接函数以及启动队列的地方。有时问题不在单个处理函数，而在于两个不同的模块各自独立监听 donation 事件，并且各自启动了自己的显示逻辑。

然后检查组件的生命周期，如果提醒是通过框架输出的。订阅应放在 effect 或类似的代码块中，并返回清理函数。不能在每次状态更新时都创建新的处理函数而不移除之前的。在普通 JavaScript 中，重要的是保存对活动套接字和当前处理函数的引用，以便在页面停止时能够正确关闭它们。

检查重连定时器。新的定时器不应在旧的之上启动。否则在几次断开后，会产生并行的连接尝试，并随之产生额外的订阅。对于每个定时器，如果不再需要，都需要通过 clearTimeout 或 clearInterval 清除。

单独查看显示提醒的代码。它不应同时向队列添加元素，又立即为同一个对象调用显示函数。还要检查元素状态变化时动画是否会被重复启动。如果日志中只有一次接收和一次入队，而屏幕上有两个通知，就需要在这里查找原因。

诊断清单：按顺序该做什么

1. 在单独的标签页中打开浏览器源 URL，并发送一笔测试打赏。确认在 OBS 之外是否出现重复。
2. 场景中只保留一个源实例。检查场景副本、嵌套场景以及可能包含同一地址的图层。
3. 在接收、入队和显示阶段添加带事件标识符的日志。这样就能看出对象数量是在哪里增加的。
4. 找出所有 socket.on 和 addEventListener 的调用。检查旧的处理函数是否通过 socket.off 和 removeEventListener 并以相同的函数引用被移除。
5. 检查重连：旧套接字是否关闭、旧定时器是否取消、是否在原有订阅之上创建了新订阅。
6. 在入队之前添加对打赏唯一标识符的校验，然后完全重启源，并用单个事件重新测试。

如果单独标签页只接收一次事件，而 OBS 显示两个提醒，就查找源的第二个实例或场景中的重复。如果事件在单独标签页中就已经到达两次，就检查订阅、连接和服务器投递。如果接收和队列都只记录一次，但屏幕上有两个通知，问题就出在视觉层。