为何在事件处理器中添加与移除事件处理器的表现存在差异？

浏览器的事件触发机制是基于事件调度队列快照的逻辑，但移除监听器的处理是即时生效的，这背后是DOM事件规范的明确规定，并非设计不一致。

1. 处理中添加监听器：不影响当前事件队列 #

先看你提供的第一个示例代码：

document.documentElement.addEventListener("click", () =>
{
    console.log("Handler 1");
    document.documentElement.addEventListener("click", () => console.log("Handler 2"));

    return;
});

首次点击仅输出Handler 1，原因是：当事件开始触发时，浏览器会先创建当前事件的监听器队列快照——也就是此时已注册的所有符合条件的监听器列表。在事件处理过程中新添加的监听器，只会被加入到未来的事件触发队列中，不会修改当前正在处理的快照队列。

这种设计的核心目的是避免事件处理过程中无限添加监听器导致的死循环，同时保证当前事件的处理流程稳定、可预测。

2. 处理中移除监听器：即时生效并修改当前队列 #

再看第二个示例代码：

const handler2 = () => console.log("Handler 2");

document.documentElement.addEventListener("click", () =>
{
    console.log("Handler 1");
    document.documentElement.removeEventListener("click", handler2);

    return;
});
document.documentElement.addEventListener("click", handler2);

点击后仅输出Handler 1，因为虽然初始的队列快照包含Handler 1和Handler 2，但DOM规范明确要求：在事件处理过程中移除监听器时，需要即时检查当前队列中的待执行监听器，若匹配则将其从队列中移除。

这是因为移除监听器通常是开发者主动想要终止后续不必要的逻辑执行，如果仍按照快照执行，会违背开发者的预期——比如开发者可能在满足某个条件后，明确不想让后续的监听器触发。

行为差异的合理性 #

这两种操作的行为差异并非设计漏洞，而是基于使用场景和开发者预期的不同：

• 添加监听器：开发者在事件处理中添加新监听器，几乎都是为了响应未来的事件，而非当前正在处理的事件。如果允许修改当前队列，很容易导致意外的循环触发（比如在点击事件里添加同类型点击监听器，当前事件会反复触发新添加的逻辑）。
• 移除监听器：开发者在事件处理中移除监听器，大多是为了阻止当前事件的后续监听器执行。如果此时仍然执行快照中的监听器，会让移除操作失去即时生效的意义，不符合开发者的直观预期。

这种行为是DOM Events规范明确规定的，所有符合规范的浏览器都会遵循这一逻辑，所以你在Edge和Firefox中看到的表现是一致的。

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