Apollo Server 默认会捕获解析器内的异常并返回 GraphQL 错误响应，通常不会导致进程崩溃。若出现服务崩溃，通常是未处理的 Promise 拒绝或进程级异常，需配合 formatError 格式化业务错误，并监听 process.on('uncaughtException') 防止进程退出。
先说结论：Apollo Server 内置错误处理机制可拦截大部分解析器异常，但需配置全局钩子和进程级监听以确保稳定性。
- 适合：Node.js 环境下的 Apollo Server 项目，特别是涉及异步数据库调用或外部 API 的场景。
- 先准备：确认 Apollo Server 版本支持 formatError 配置，预留错误日志存储位置。
- 再验证：通过故意抛出异常测试响应结构，确认进程未退出且日志记录完整。
快速处理思路
在 Apollo Server 配置中添加 formatError 函数拦截 GraphQL 执行错误，同时在入口文件注册 Node.js 进程级异常监听。
const server = new ApolloServer({ schema, formatError: (error) => { console.error('GraphQL Error:', error); return { message: error.message, code: error.extensions?.code || 'INTERNAL_SERVER_ERROR' }; }});process.on('uncaughtException', (err) => { console.error('Uncaught Exception:', err); // 记录日志后决定是否退出});process.on('unhandledRejection', (reason, promise) => { console.error('Unhandled Rejection at:', promise, 'reason:', reason);});为什么会这样
GraphQL 执行错误与 Node.js 进程崩溃是两个不同层级的问题。Apollo Server 在执行解析器（Resolver）时会将抛出的异常捕获并放入响应体的 errors 数组，不会中断 HTTP 服务。
但如果异步操作未在 Promise 链中处理，或错误发生在 GraphQL 执行上下文之外（如定时任务、启动脚本），则会触发 Node.js 的 uncaughtException 事件导致进程退出。公开资料中没有看到可靠的量化数据表明具体多少比例的崩溃源于此，但这是常见的生产环境问题。
分步处理
第一步：配置 Apollo Server 错误格式化
在初始化 ApolloServer 实例时传入 formatError 选项。该函数接收原始错误对象，允许你修改返回给客户端的信息，同时保留服务端日志。
第二步：区分用户错误与系统错误
参考 Spectrum 项目的实践，定义自定义错误类（如 UserError）并通过 Symbol 标记。在 formatError 中判断错误类型，用户错误返回明确提示，系统错误返回通用信息。
第三步：注册进程级异常监听
在应用入口文件（如 index.js）顶部添加 process.on 监听器。捕获 uncaughtException 和 unhandledRejection，记录错误堆栈后，根据策略决定重启或关闭服务。
怎么验证是否生效
发送一个故意触发错误的 GraphQL 查询，检查 HTTP 状态码是否为 200 且响应体包含 errors 字段。同时观察服务端控制台，确认没有进程退出日志，且 formatError 中打印了错误信息。
常见坑
不要在 formatError 中直接抛出新异常，否则会导致服务器崩溃。生产环境避免将原始堆栈信息返回给客户端，防止泄露敏感路径。
常见问题
formatError 能拦截所有错误吗？
不能，它只能拦截 GraphQL 执行过程中的错误，无法拦截进程级未捕获异常。
捕获异常后需要重启服务吗？
建议记录日志后重启，因为 Node.js 进程在发生 uncaughtException 后状态可能不稳定。
如何区分业务错误和系统错误？
通过自定义错误类的 name 属性或 extensions.code 字段进行区分，并在服务端逻辑中显式抛出。
参考来源
- SpectrumGraphQL 错误处理：自定义异常与客户端提示
- Apollo GraphQL 错误处理：构建健壮应用的完整指南
- GraphQL 错误处理完全指南：从请求错误到执行错误的解决方案