Serverless中Node.js函数需主动处理未捕获Promise拒绝：统一监听unhandledRejection并exit(1)，禁用悬空Promise，handler用async/try-catch包裹，弃用domain改用结构化错误类。
在 Serverless 环境（如 AWS Lambda、腾讯云 SCF、阿里云 FC）中，Node.js 函数一旦发生未捕获的 Promise 拒绝（unhandledRejection），运行时可能不会立即崩溃，但会触发实例异常终止或资源冻结失败，尤其在冷启动/复用执行上下文场景下，容易导致日志丢失、监控断连、重试混乱，甚至影响后续请求调度。关键不是“不让它退出”，而是“不让它静默退出”——必须确保每个异步错误都被显式处理并可控响应。
监听 unhandledRejection 并主动终止
Serverless 平台通常不支持长期守护进程，因此 process.on('unhandledRejection') 不应仅用于日志记录，而要配合明确的退出策略：
- 在函数入口统一注册监听器，捕获所有未被
.catch()或try/catch拦截的 Promise rejection - 立即记录完整错误（含
reason.stack和原始reason类型） - 调用
process.exit(1)主动终止当前执行环境，避免实例残留或状态污染 - 注意：不能仅
throw reason（旧式写法易引发二次 uncaughtException）
禁止悬空 Promise，尤其 Async IIFE
常见于初始化逻辑（如连接数据库、加载配置）中使用立即执行的异步函数：
用于自动切换项目中适合的node 版本
下载
根据 package.json 中的 engines 字段自动检测 Node.js 版本需求，未安装 nvm 时自动安装并切换至对应版本。支持 Windows、macOS、Linux。适用于 Node.js 项目开发、版本切换和环境配置。
- 错误写法：
(async () => { await initDB(); })();—— 返回的 Promise 未被await或.catch()，变成悬空 Promise - 正确做法：用
void显式放弃返回值，并加.catch(console.error)守底：void (async () => { await initDB(); })().catch(console.error); - 更稳妥方式：将初始化逻辑封装为同步可判断的准备函数，或在主 handler 中
await它，让错误自然冒泡到顶层 try/catch
Handler 内统一用 async/await + try/catch 包裹
Serverless 函数的主 handler 是错误处理的第一道防线，必须覆盖全部异步路径：
立即学习“Java免费学习笔记（深入）”；
- 即使底层用回调或 EventEmitter，也应封装为 Promise（如
util.promisify或手动包装） - 整个 handler 函数声明为
async，最外层用try/catch捕获所有同步抛出和 await 拒绝 - 在
catch中区分错误类型（如instanceof AppError），设置合适的 HTTP 状态码或响应体，并记录结构化日志 - 避免在 catch 中仅
console.log后继续执行——Serverless 函数应“快速失败”，不带病运行
禁用 domain，改用结构化错误模型
domain 模块已废弃（Node.js 20+ 移除），且在 Serverless 环境中不可靠（实例生命周期短、无稳定上下文）：
- 不要依赖
domain.create().run()做沙箱隔离——它无法跨异步边界可靠传递上下文 - 改用轻量级错误类继承
Error，例如：class ValidationError extends Error { constructor(msg) { super(msg); this.name = 'ValidationError'; this.statusCode = 400; } } - 所有业务异常都应是此类实例，便于中间件或顶层 catch 统一识别与响应
- 第三方库抛出的非 Error 对象（如字符串、数字），需在进入业务逻辑前强制包装：
if (!(err instanceof Error)) err = new Error(String(err));
