uncaughtexception仅捕获同步未捕获错误，unhandledrejection专捕未处理promise拒绝；二者均非兜底方案，触发后应记录并exit(1)，不可继续服务。
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，而是每种错误类型都要对应到具体动作：记录、告警、降级、重试、拒绝、补偿……漏掉一类，线上就多一个深夜报警。
