界面切换后，旧组件留下的事件监听器还在响应，常见修法是把回调和事件名存起来，销毁时再手动 removeEventListener。DOM 监听器还有另一种收尾方式：注册时传入 AbortSignal，需要结束时调用 abort()。但信号取消究竟等不等同于手动移除？已经取消的信号还能不能注册？这两个边界值得先跑一遍。
这篇用 Node.js 的 EventTarget 做了小实验。它实现了与浏览器事件目标相同形态的 addEventListener，可检查 signal 关联的监听器生命周期；它不是浏览器布局或真实组件框架的测试，因此不会推断页面渲染行为。
取消后，事件不再进入回调
监听器通过 signal 选项关联控制器。派发一次事件后计数是 1，调用 abort() 再派发，计数仍是 1。取消的是这一条注册关系，事件目标本身还可以继续收到其他监听器的事件。
const controller = new AbortController();
let calls = 0;
target.addEventListener('change', () => calls++, {
signal: controller.signal
});
target.dispatchEvent(new Event('change'));
controller.abort();
target.dispatchEvent(new Event('change'));
console.log(calls); // 1
本机脚本还把同一结果和手动删除作了比较。removeEventListener 要拿到正确的事件类型和回调引用，捕获选项也必须相符；只要回调在创建时是匿名函数，之后就没有现成引用可供删除。signal 把取消动作集中到控制器上，清理逻辑不必另存那份回调。
预先取消的 signal 不会留下新监听器
如果传入的 signal 在注册前已经 aborted，实验中的回调一次也没执行。这个行为对异步初始化有实际意义：请求或组件任务可能在监听器安装前就被取消，继续注册会让已过期的逻辑残留。这里不需要先注册、再补一次移除。
after first dispatch: 1
signal aborted: true
after dispatch following abort: 1
listener registered with pre-aborted signal: 0
once listener after two dispatches: 1
assertions: passed
同一个控制器可以关联多条监听器。一次 abort() 会让这些注册一起失效，适合一组资源由同一生命周期管理的情况，例如弹层关闭时结束它自己的 DOM 事件监听。控制器的边界应跟拥有者一致；若把全页共享监听器也挂到某个短命组件的 signal 上，局部清理反而会误伤其他功能。
once 仍然是另一种结束条件
once: true 的工作方式是回调执行一次后自动移除。脚本连续派发两次，回调计数仍为 1。它表达的是次数限制，而 signal 表达的是外部生命周期终止，两者可以并用，但不是互相替代的选项。
异步请求也常用 AbortController 取消 fetch；相关的取消信号和事件监听器属于同一个接口设计，但取消 fetch 还涉及请求状态与异常处理，不能用这里的 EventTarget 输出代替验证。这里测的只是监听器行为。
这个示例也没有依赖第三方包，脚本可以直接用 Node 执行。换到浏览器时，可将 target 换成具体 DOM 节点，signal 选项依然对应同一种事件监听接口。实际项目需要确认目标浏览器支持该选项；如果需兼容不支持 signal 选项的旧环境，就仍要保留回调引用并手动移除。Node 中通过，只能证明当前 Node 实现下的行为，不替代旧浏览器兼容性测试。
有个容易忽略的细节：abort() 是一次性的状态转换。同一控制器已经取消后，不适合作为可复用开关。新一轮生命周期应创建新的控制器，否则后来添加的监听器也会因为 signal 已取消而不生效。组件重新挂载时尤其要避免把旧控制器留在长期存活的外层变量里。
我更愿意把 signal 用在确有共同生命周期的一组监听器上；零散的一条监听器若已有清晰的回调引用，手动移除更直接。取消信号减少的是清理时维护的配对关系，不会自动替开发者决定哪些任务应该一起结束。优先让取消边界对应组件或交互的真实归属，才不会把方便变成隐蔽的耦合。
