commonjs 本身不提供运行时异常拦截能力，模块崩溃实为未捕获异常或 promise 拒绝，需通过监听 uncaughtexception 和 unhandledrejection 事件统一捕获并记录完整错误信息后主动退出。

CommonJS 本身不提供运行时异常拦截能力，它只是 Node.js 的模块加载规范。所谓“模块崩溃”实际是模块内代码抛出的未捕获异常或 Promise 拒绝，需靠 Node.js 运行时机制统一捕获，而非 CommonJS 层面处理。

监听全局未捕获异常

Node.js 中所有同步异常最终都会触发 uncaughtException 事件。这是拦截模块级崩溃的第一道防线：

• 在应用入口（如 app.js 或 server.js）最顶部注册监听，早于任何 require 调用
• 捕获后必须记录完整错误信息（error.stack、error.message、process.uptime() 等），再调用 process.exit(1) 主动退出——避免状态不一致和二次崩溃
• 不要仅靠 console.error，应写入文件日志或上报监控服务（如 Sentry、ELK）

捕获未处理的 Promise 拒绝

现代 CommonJS 项目大量使用 async/await，Promise 拒绝若未被 .catch() 或 try/catch 捕获，会触发 unhandledRejection 事件：

Comprehensive Three.js 3D graphics reference

详细的 Three.js 3D 图形参考，涵盖场景设置、相机、几何体、材质、光照、动画、控制器、加载器、数学工具和调试。

下载

• 监听该事件，获取 reason（可能是 Error 实例或原始值），统一格式化后记录
• 建议默认行为是记录 + process.exit(1)；若业务允许降级，可选择性忽略特定错误（如网络超时），但需明确标记
• 注意：Node.js 15+ 默认将未处理拒绝视为致命错误，进程会自动退出，但仍需监听以完成日志记录

增强模块加载时的错误上下文

虽然无法在 require 时直接拦截模块内异常，但可通过包装方式增强可追溯性：

• 自定义一个 safeRequire 工具函数，在 require 前后打点，记录模块路径与加载时间
• 当 uncaughtException 触发时，结合 process.mainModule?.filename 和当前 require.cache 快照，辅助判断崩溃是否发生在某模块初始化阶段
• 对关键业务模块（如数据库连接、配置加载），在 require 后立即执行简单健康检查，失败时主动抛出带模块标识的错误

避免常见陷阱

很多团队误以为 CommonJS 模块系统能“捕获模块崩溃”，结果留下盲区：

• 不依赖 try/catch 包裹 require：模块顶层代码抛错不会被外部 try 捕获，因为 require 是同步执行且错误发生在调用栈深处
• 不忽略异步回调错误：如 fs.readFile 回调中抛错，仍属未捕获异常，必须靠全局监听兜底
• 不省略错误现场数据：仅记录 error.message 不够，error.stack、process.versions、环境变量等都应纳入日志结构

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南