Node.js 移除事件监听：已经 off 了，为什么本轮回调仍然执行
一个事件有两个处理器：第一个发现任务已经取消，于是移除第二个；日志却显示第二个在这一轮仍被调用。这不是删除函数失效，而是“今后不再订阅”和“当前分发立刻停止”具有不同的时间边界。
先把同一轮和下一轮分开观察
Node.js 的 EventEmitter 按监听注册顺序同步调用处理器。事件开始分发时已经附加的监听，会进入这轮调用；在其中调用 off 或 removeListener，不会把后续监听从正在进行的 emit 中撤回。下一次 emit 才体现新的注册状态。
下面先让 first 移除 second，连续触发两次事件，并把执行轨迹保存在数组里。随后建立另一组处理器，用明确的 stopped 状态让第二个处理器跳过动作。两组实验都没有网络、定时器或外部服务，顺序可以直接由断言检查。
保存为 demo.mjs，执行 node demo.mjs。第二组里“回调被调用”和“业务动作继续做”特意分开记录，这能判断到底是订阅变化还是内部状态判断发挥了作用。
配图为 AI 生成的概念插图，用抽象物件说明本文关系，并非真实软件截图或运行输出。
import assert from 'node:assert/strict';
import { EventEmitter } from 'node:events';
const bus = new EventEmitter();
const trace = [];
function second(round) {
trace.push(`second:${round}`);
}
bus.on('job', round => {
trace.push(`first:${round}`);
bus.off('job', second);
});
bus.on('job', second);
bus.emit('job', 1);
bus.emit('job', 2);
assert.deepEqual(trace, ['first:1', 'second:1', 'first:2']);
assert.equal(bus.listenerCount('job'), 1);
console.log('trace:', trace.join(' -> '));
const guarded = new EventEmitter();
const guardedTrace = [];
const state = { stopped: false };
function act() {
guardedTrace.push(state.stopped ? 'skipped' : 'acted');
}
guarded.on('job', () => {
state.stopped = true;
guarded.off('job', act);
});
guarded.on('job', act);
guarded.emit('job');
assert.deepEqual(guardedTrace, ['skipped']);
console.log('guarded:', guardedTrace.join(', '));结果说明了两个不同的保证
第一组轨迹依次是 first:1、second:1、first:2。第一轮的第二个回调仍执行，第二轮却已不再出现；监听数量最后为一，也证明移除确实成功。只检查监听清单会漏掉当前轮仍可能调用的事实，只看第一轮则容易误判接口无效。
第二组打印 skipped，表示回调仍进入了函数，但在真正动作之前检查了停止状态。这里的条件是同步可见的普通状态，没有试图终止 JavaScript 调用栈。业务若只要求不再接收下一次通知，解除订阅足够；若当前轮也不能继续动作，就需要接收方检查状态。
off 必须拿到注册时的同一个函数对象。重新写一个长得一样的箭头函数，再传给 off，并不会匹配原处理器。示例用具名函数保存引用，让“引用不相同”和“分发已经开始”这两类问题不会混在一起。
不要把示例外推成通用取消机制
若处理器已经启动异步操作，后来改变 stopped 不能撤销已经发生的结果。实际任务应在重要动作前再次检查取消状态，并结合具体接口提供的取消方式。解除事件订阅处理的是注册关系，不会自动回滚写入，也不会替已启动的 Promise 结束工作。
这套顺序也不应直接套到浏览器 DOM 事件或 EventTarget 上。接口名称相近不代表移除语义一致，应确认使用的确实是 EventEmitter。本例没有抛异常的监听；若前面的处理器同步抛错，调用流程会受异常影响，需要另行设计错误处理。
对于反复创建和关闭的组件，关闭时既要移除注册，也要让组件状态明确变成不可处理。测试保留“在第一监听里移除第二监听”这个样本，再额外检查下一轮没有重复调用，能同时覆盖当前动作防护与后续资源清理。
资料核对日期：2026年10月2日（北京时间）。最终展示代码在 Node.js v24.19.0 中独立运行并通过全部断言。
