Node.js error 事件：监控已经记录了异常，程序为什么仍然会抛错
给事件对象加上监控回调后，日志已经记下错误，程序却仍然抛出异常。原因可能是注册了 errorMonitor，却没有真正的 error 监听器。监控负责观察错误事件，并不代表应用已经接手处理；两者的职责不能靠“日志里看见了”来判断。
EventEmitter 对名为 error 的事件有特殊规则。普通事件无人监听时，emit 通常返回 false；error 无人处理时则会抛出异常。下面在 Node.js v24.19.0 执行，保存为 demo.mjs，再运行 node demo.mjs。实验把预期异常捕获为断言，不会故意留下未处理异常。
把观察与处理分别接上
第一步发送没有订阅者的 notice，确认返回 false。随后只安装 errorMonitor，再发 first 错误，监控记录增加，但 emit 仍抛出。第二步添加 error 监听器，发送 second，才验证正常的错误处理入口收到该对象，并让这次 emit 返回 true。
AI概念示意图：观察者看见警铃，独立接收器承担处理信号的角色；观察路径与处理路径有不同职责。图片不是运行截图。
import assert from 'node:assert/strict';
import { EventEmitter, errorMonitor } from 'node:events';
const emitter = new EventEmitter();
assert.equal(emitter.emit('notice', 'sample'), false);
const monitored = [];
const handled = [];
emitter.on(errorMonitor, error => monitored.push(error.message));
assert.throws(
() => emitter.emit('error', new Error('first')),
/first/
);
assert.deepEqual(monitored, ['first']);
assert.deepEqual(handled, []);
emitter.on('error', error => handled.push(error.message));
assert.equal(emitter.emit('error', new Error('second')), true);
assert.deepEqual(monitored, ['first', 'second']);
assert.deepEqual(handled, ['second']);
console.log('monitor:', monitored.join(','));
console.log('handled:', handled.join(','));
const brokenHandler = new EventEmitter();
brokenHandler.on('error', () => { throw new Error('handler failed'); });
assert.throws(
() => brokenHandler.emit('error', new Error('original')),
/handler failed/
);
console.log('handler failure still throws');有监听器不等于任务已恢复
前两行输出 monitor: first,second 与 handled: second。第一条错误被看见但没有被处理，第二条同时经过两个入口。true 只说明这次事件有相应监听器，不能当成文件写入成功、请求重试成功或故障已修复的业务回执。
实际处理器要决定后续状态，例如标记任务失败、释放自有资源或通知等待方结束。如果只放一个空函数来避免抛错，任务可能继续停在半完成状态，使用者反而得不到失败结果。处理流程应有明确的结束点，并测试它是否真正发生。
errorMonitor 使用的是导出的 Symbol，而不是字符串。注册名为 errorMonitor 的普通字符串事件，不会获得同样能力。监控回调也不应修改传入错误来改变其他处理器的判断；若需要记录，提取必要字段并保留事件身份即可。
处理器自身抛错仍要面对
最后建立另一个对象，它确实有 error 监听器，但监听器内部抛出 handler failed。外层断言仍捕获这个新异常，说明安装了监听并没有把回调变成不会失败的保护区。对需要记录和清理的步骤，应安排明确的异常路径，避免诊断代码遮盖最初原因。
本例直接调用 emit，监听器在这次调用中同步执行，所以周围的断言能够捕获异常。真实库可能稍后从异步回调触发事件；围在启动函数外面的 try 代码块，不会自动跨越时间捕获未来那次调用。应在产生事件的对象上提前建立处理关系。
监听器返回值通常被忽略，返回一个错误字符串不会让 emit 自动失败，返回成功文字也不会形成确认协议。若调用方需要等待一个明确结果，应另外使用约定的回调、Promise 或状态接口，让成功与失败都有可观察出口。
按事件对象的协议进行验收
不要把这里的规则直接套到浏览器 EventTarget。接口名称相似，不代表异常分发和生命周期完全一致。异步监听函数返回的 Promise 还涉及拒绝处理及 captureRejections 等配置，本例只验证同步监听，因此不对那些路径作完成保证。
迁移到自己的服务时，可依次测试普通事件无人监听、只有监控、安装处理器、处理器自身失败四种情况。保留事件源和任务标识，分别核对错误有没有被观察、任务有没有结束。这样才不会把监控系统正常工作误认为应用已正确恢复。
