node.js 中 'error' 事件是标准化异常通道，未监听时会触发进程终止；普通事件则被忽略。必须显式监听 'error'，不可依赖 try/catch，这是运行时强制保护策略。
因为 Node.js 对 error 事件有特殊约定：它被视作“未捕获异常”的等价信号，而非普通业务事件。
error 是语义化的异常通道
EventEmitter 并不把 'error' 当成一个普通字符串事件名。它的设计初衷是作为对象内部出错时的**标准化上报机制**。一旦 emit('error') 被调用，Node.js 会立即检查是否有监听器——如果没有，就直接抛出一个未捕获的 Error，触发进程的默认异常终止流程。
这和 throw new Error() 的效果一致，区别只在于错误来源不同。
不是 EventEmitter 自己崩溃，而是 Node.js 主动退出
进程退出不是 EventEmitter 模块的 bug 或缺陷，而是运行时的强制保护策略。Node.js 认为：一个组件发生了 error 却没人处理，说明程序处于不可预期状态，继续运行风险更高。
这种行为在所有继承自 EventEmitter 的核心模块中都生效，比如 fs.ReadStream、net.Socket、http.ClientRequest 等——它们内部遇到 I/O 错误时，都会 emit('error')，你必须监听，否则进程挂掉。
为什么其他事件不会这样？
普通事件（如 'data'、'connect'）没有这个语义约束。emit 一个没人监听的普通事件，Node.js 完全忽略，不会报错也不会中断执行。
只有 'error' 被硬编码进了事件系统的异常处理路径里。这是 API 设计层面的契约，不是实现细节。
如何避免崩溃？
- 始终为可能 emit('error') 的对象显式绑定
on('error', handler) - 不要依赖 try/catch 包裹 emit() —— 因为 emit 是同步的，但 error 监听器没注册时，异常发生在 emit 内部，无法被外层 catch 捕获
- 对动态创建的 EventEmitter 实例，可在构造后立即加兜底监听：
emitter.on('error', err => console.error('Unhandled error:', err)) - 使用
once('error', ...)适合一次性资源，防止重复监听
这个机制看似严格，实则是 Node.js 推动开发者显式处理失败路径的关键设计。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
