错误处理与日志最佳实践独立开发者构建可维护系统的实战指南错误处理的三个核心原则错误处理是独立开发者最容易知道重要但一直拖延的工程环节。早期产品用户少错误影响范围小你总觉得先把功能做出来错误处理后面再加。但等到用户量到几千、每天API请求到几万次时你会发现没有系统化的错误处理和日志排查一个问题需要几小时——你需要在服务器日志文件里手动搜索错误信息需要猜测这个错误是哪个用户触发的需要复现这个错误在什么条件下发生。我在2023年到2026年逐步建立了产品的错误处理和日志体系。以下是最佳实践的完整记录。原则一区分预期错误与非预期错误很多开发者把所有错误都用同样的方式处理——返回500 Internal Server Error。这是错误的。预期错误Expected Errors和非预期错误Unexpected Errors需要完全不同的处理策略。预期错误这是正常业务流程的一部分的错误。如用户登录时密码错误用户请求的资源不存在404用户输入的表单数据验证失败400用户权限不足403这些错误的特征是你知道它们会发生且需要在产品层面给用户友好的反馈。处理策略返回合适的HTTP状态码4xx系列返回人类可读的错误信息如密码错误请重试不要记录为错误日志——这是正常业务流不需要告警非预期错误这是不应该发生的错误。如数据库查询失败连接断了、SQL语法错误外部API调用失败网络超时、API返回500代码里的逻辑错误如试图读取undefined的属性这些错误的特征是它们不应该在正常业务流程中发生发生了说明有bug或系统故障。处理策略返回500 Internal Server Error或502/503如果是外部服务不可用返回给用户一个通用的抱歉出了点问题提示不要把技术错误信息暴露给用户必须记录详细的错误日志包含堆栈追踪、用户上下文、请求参数可选发送告警通知根据错误频率决定是否立即告警原则二结构化日志而不是console.log到处打早期产品的日志通常是这样的console.log(用户登录成功, userId); console.error(数据库查询失败, error); console.log(API请求开始, req.body);这种日志的问题不可查询。出了问题时你需要在服务器上用grep或tail -f手动搜索日志。如果日志量很大这几乎不可能。缺少上下文。日志只记录了发生了什么没有记录发生在谁身上请求ID是什么调用链路是什么。格式不一致。有的日志是字符串有的是JSON有的是错误对象。后期要做日志分析几乎不可能。解决方案结构化日志Structured Logging所有日志用统一的JSON格式包含以下字段{ timestamp: 2026-07-01T14:30:00.123Z, level: error, message: 数据库查询失败, error: { message: Connection terminated, stack: Error: Connection terminated\n at ... }, context: { requestId: req_abc123, userId: user_456, path: /api/generations, method: POST } }在Node.js里可以用winston或pino这类日志库来实现结构化日志import winston from winston; const logger winston.createLogger({ format: winston.format.combine( winston.format.timestamp(), winston.format.json() ), transports: [ new winston.transports.File({ filename: error.log, level: error }), new winston.transports.File({ filename: combined.log }) ] }); // 使用 logger.info(用户登录成功, { userId, sessionId }); logger.error(数据库查询失败, { error, userId, query });关键实践给每个请求分配一个唯一的Request ID这样当一个请求触发了多个日志条目如API请求开始→数据库查询→AI API调用→返回响应你可以用Request ID把这些日志条目关联起来。实现方式用Express中间件给每个请求生成一个UUIDapp.use((req, res, next) { req.requestId crypto.randomUUID(); logger.info(API请求开始, { requestId: req.requestId, method: req.method, path: req.path, userId: req.user?.id }); next(); });然后在所有后续的日志调用里都带上requestId。这样排查问题时你只需要搜索requestId就能看到这个请求的全链路日志。原则三用Sentry或类似工具做错误追踪与聚合结构化日志解决了记录错误的问题。但它没有解决错误聚合与趋势分析的问题。如果你有1000个用户其中50个用户触发了同一个错误如AI API调用超时在日志文件里这会表现为50条独立的错误日志。你需要手动统计这个错误发生了多少次、影响了多少用户。错误追踪工具如Sentry的价值就是自动做这个聚合。Sentry会自动聚合相同错误把堆栈追踪相同的错误归类为一个Issue统计发生频率和影响用户数这个错误在过去24小时发生了50次影响了30个用户提供上下文每次错误发生时的用户信息、请求信息、面包屑用户在做这个错误之前做了什么操作告警当某个错误的发生频率超过阈值时发送邮件或Slack通知接入Sentry的核心实践在后端和前端都接入Sentry后端Sentry捕获API层面的未处理异常前端Sentry捕获浏览器里的JavaScript错误和用户操作层面的问题。设置合理的告警规则不是每一个错误都需要立即告警。我的告警规则是P0过去1小时内同一个错误发生了10次 → 立即Slack通知P1过去24小时内某个错误影响了5个用户 → 每日汇总邮件P2其他错误 → 不告警定期在Sentry后台审查用Sentry的发布版本功能追踪错误和代码版本的关系每次部署新版本时在Sentry里标记一个新的Release。这样当某个错误出现在Sentry里时你能看到这个错误是在哪个版本引入的。用户输入验证与错误反馈的用户体验最后谈一个经常被忽视的话题错误处理的用户体验。技术层面的错误处理记录日志、发送告警是重要的。但用户看到错误提示时的体验同样重要。最佳实践给用户的信息应该是可行动的❌ 错误Internal Server Error✅ 正确服务器处理你的请求时出了点问题。请稍后重试如果问题持续请联系支持supportproduct.com。区分用户能修复的错误和用户不能修复的错误用户能修复的如表单验证失败明确告诉用户哪一栏填错了、怎么改用户不能修复的如服务器错误告诉用户这不是你的问题我们已经知道了正在修复用Toast或Inline错误提示不要用Alert弹窗在2026年用户体验的最佳实践是表单验证错误用Inline提示在输入框旁边显示红色文字操作失败用Toast通知页面右上角滑入的提示不要用浏览器原生的alert()弹窗。实战案例一次生产错误的完整排查过程2024年8月15日我收到了Sentry的告警AI API调用超时在过去1小时内发生了23次影响了18个用户。排查过程在Sentry里查看错误详情看到了错误的堆栈追踪、每个错误发生时的Request ID、受影响的用户ID列表。用Request ID查询完整日志在Grafana我的日志查询界面里搜索其中一个Request ID看到了这个请求的全链路日志14:30:01 - API请求开始14:30:01 - 数据库查询用户订阅状态成功14:30:02 - 调用Claude API超时30秒后放弃14:30:32 - 返回500错误给用户识别根因所有23次错误都集中在14:30-14:45这个时间段。我查了Claude API的状态页status.anthropic.com发现Claude API在14:25-14:50有一次部分服务中断。修复这次错误是外部服务的问题不是我的代码bug。但我在代码中加入了外部API调用超时后的重试逻辑用axios-retry库这样下次Claude API短暂超时时系统会自动重试不需要把错误暴露给用户。后续优化我加入了多个AI模型Fall-back机制——如果Claude API超时自动切换到GPT-4 API。这个优化让同样的外部服务中断不再影响我的用户。结论好的错误处理系统不是没有错误而是当错误发生时你能快速定位、快速修复、且用户受到的影响最小。独立开发者不需要搭建像大公司那样复杂的错误管理平台但至少需要结构化日志、错误追踪工具如Sentry、以及给用户友好错误提示的用户体验意识。