异常处理进阶：企业错误监控与防御技巧

本文深入剖析企业级 Node.js 应用中五大典型错误处理陷阱：从 uncaughtException 与 unhandledRejection 的本质区别及安全退出原则，到 Express 中 next(err) 类型误用导致的静默崩溃；从 Sentry 初始化时机不当引发的启动期监控盲区，到数据库错误不分类型盲目重试带来的数据风险；最终指出错误处理的核心不是堆砌工具，而是为每类错误精准匹配记录、告警、降级、重试或补偿等差异化响应策略——漏掉一种，就可能换来一次凌晨三点的线上事故。

Node.js 中 uncaughtException 和 unhandledRejection 的区别与误用

这两个钩子不是兜底方案，而是最后的“抢救窗口”——错过就进程退出。很多人把它们当 try/catch 的全局替代，结果日志写了、错误吞了，服务却悄悄卡死或内存泄漏。

• uncaughtException 只捕获同步代码中未被 catch 的 Error，比如 JSON.parse('{') 或手动 throw new Error()；它**不捕获 Promise 拒绝、异步回调里的错误、未监听的 EventEmitter 错误**
• unhandledRejection 专治 Promise 链末端没写 .catch() 或 await 后没包 try 的情况，但**不会触发 if Promise 被正常 reject 后又被另一个 .catch() 捕获**
• 两者都**不能安全地继续提供服务**：Node.js 官方明确说，uncaughtException 触发后堆栈已损坏，再发 HTTP 响应可能失败；强行 process.exit(0) 会跳过 graceful shutdown
• 正确做法是记录错误 + 触发一次 process.exit(1)，同时靠 PM2 / Kubernetes 等外部进程管理器拉起新实例

Express 中 next(err) 传错类型导致 500 静默丢失

Express 的错误中间件只认 Error 实例，传字符串、数字、对象进去，err.status 和 err.message 全失效，最终 fallback 到默认 500 页面，连日志都看不出错在哪。

• 常见错误写法：next('User not found')、next({ code: 'NOT_FOUND' })、next(404)
• 正确写法必须是 Error 子类：next(new Error('User not found'))，或自定义类：class NotFoundError extends Error { constructor(msg) { super(msg); this.status = 404; } }
• 如果用 TypeScript，next() 的类型提示会帮你拦住非 Error 类型，但 JS 项目得靠 ESLint 插件 eslint-plugin-express 的 express/no-missing-error-handler 规则
• 别在路由里写 res.status(500).send() 代替 next()：这样绕过了所有全局错误中间件，日志、告警、Sentry 上报全丢

Sentry 初始化时机不对，导致启动期错误不上报

Node.js 应用刚启动时发生的错误（比如配置文件读取失败、DB 连接超时、环境变量缺失）最容易漏监控——因为 Sentry SDK 还没 ready。

• 典型错误顺序：先 require('./config') → 报错 → 再 require('@sentry/node') → Sentry.init()
• 必须把 Sentry.init() 放在所有业务 require 之前，最好作为入口文件第一行（index.js 顶部），且加 try/catch 包裹自身初始化逻辑
• 对 uncaughtException 和 unhandledRejection 的集成，要显式传 integrations: [new Sentry.Integrations.OnUncaughtException(), new Sentry.Integrations.OnUnhandledRejection()]，否则默认不启用
• 本地开发时设 enabled: process.env.NODE_ENV === 'production' 是好习惯，但别用 if (!Sentry.isInitialized()) 做条件判断——这个方法在 init 前永远返回 false，容易误判

数据库连接层没做 error 分类，重试策略全乱套

数据库报错五花八门，但很多应用统一 sleep(1000); retry()，结果网络超时重试 3 次，主键冲突也重试 3 次，最后数据重复写入。

• PostgreSQL 常见错误码要拆开处理：23505（唯一约束）该返回 409，不该重试；08006（连接失败）才适合指数退避重连
• 用 pg 时，错误对象有 err.code 和 err.severity 字段；用 mysql2 时看 err.sqlState；ORM 如 Prisma 则需检查 error.code（如 P2002 表示唯一键冲突）
• 连接池本身有 acquireTimeoutMillis 和 idleTimeoutMillis，但这些只是资源等待超时，和 SQL 执行失败无关——后者必须靠 query 层的 try/catch 捕获
• 别在事务里对可预期错误（如乐观锁失败）用 throw：应该 return { success: false, reason: 'version_mismatch' }，让上层决定是重试还是降级

真正难的不是加几个 try 或配个 Sentry，而是每种错误类型都要对应到具体动作：记录、告警、降级、重试、拒绝、补偿……漏掉一类，线上就多一个深夜报警。

以上就是《异常处理进阶：企业错误监控与防御技巧》的详细内容，更多关于的资料请关注golang学习网公众号！