为什么你写了日志，线上还是定位不了问题？

文章主旨：

生产环境中异常处理的核心目标不是记录所有异常，而是通过分层设计、统一返回结构和自定义业务异常，实现“对外可控、对内可查、责任清晰”，从而快速定位问题并恢复服务。

关键要点：

• 异常处理三层标准：对外接口统一、日志完整可还原现场、严格区分业务异常与系统异常。
• 异常分层：业务异常（可预期，如校验失败）与系统异常（不可预期，如空指针、数据库异常）。
• 统一返回结构：使用 ApiResult 封装 code、message、data，异常场景下 data 为空，永不直接暴露原始异常信息给前端。
• 自定义业务异常：继承 RuntimeException，包含 code 和 message，用于可控的业务逻辑失败场景。
• 示例场景：金额校验失败时抛出 BizException，配合统一返回结构，前端可识别 code 并提示用户友好信息。

内容结构：

前言：指出生产环境问题定位的关键是日志信息足够详细，异常的意义在于快速定位、止损、恢复服务，并强调本文对线上维护者的实用价值。

一、异常在生产环境中的正确定位
异常设计需满足三点：对外可控（接口返回统一，不泄露细节）、对内可查（日志完整，可还原现场）、责任清晰（区分业务异常与系统异常）。推荐异常分层：业务异常（可预期）和系统异常（不可预期）。

二、统一返回结构：异常不等于500
异常永远不应直接返回给前端。定义 ApiResult 类（包含 code、message、data），使用泛型 T，异常时 data 为空。异常的职责是标记失败，而非传递错误细节。

三、业务异常：一定要存在
自定义 BizException（继承 RuntimeException），包含 code 和 message。示例：金额校验失败时抛出该异常，统一用 code 标识失败原因，前端可据此展示对应文案。

文章总结：

本文从实战角度系统阐述了生产环境异常设计的最佳实践，强调“可查可控”的核心理念，并通过分层与封装实现快速故障定位与用户体验保护。

代码历史上最昂贵的 7 个错误

了解更多

热爱技术的小郑

查看原文：为什么你写了日志，线上还是定位不了问题？

文章来源：

热爱技术的小郑

扫码关注公众号