柏拉图恋爱实战项目3步搞定报错堆栈
报错一堆看不懂 StackTrace？ 别慌，这往往是新手在实战项目里最容易卡壳的地方。很多人对着满屏红色代码发呆，根本不知道问题出在哪一行，更别提怎么修了。其实，只要理清逻辑，哪怕是最复杂的异常链，也能拆解成几个简单的断点。
今天咱们不讲虚的，直接上手一个名为柏拉图恋爱的模拟系统。这名字听着浪漫，实际上是个标准的 Java 后端实战项目，用来演示如何优雅地处理业务异常和系统异常。我们会从零搭建，重点攻克那个让人头大的 StackTrace。
项目目标与核心痛点解析
先说清楚，为什么选“柏拉图恋爱”这个名字？因为在软件工程中，我们常把这种“纯逻辑、无物理交互”的数据流转比作精神恋爱——数据在内存里穿梭，没有落盘，全靠代码逻辑维系。
这个实战项目的核心目标只有一个：让异常变得可读。
在传统的初学者代码里，你经常看到这样的写法：
try {
// 复杂业务逻辑
} catch (Exception e) {
e.printStackTrace();
}
这就是痛点所在。e.printStackTrace() 会把几千行的堆栈信息直接打印到控制台。在本地调试时，你可能还能一眼扫到关键行；但在生产环境，或者当嵌套层级超过三层时，这堆字符就像天书一样。你根本不知道是数据库连不上，还是参数校验失败，或者是某个空指针引用。
我们的目标，是通过封装自定义异常、统一异常处理器，将这种“天书”转化为人类能读懂的“错误码 + 友好提示”。这就是本次实战项目要解决的核心问题。
目录结构与环境准备
工欲善其事，必先利其器。为了保证实战项目的可复现性，我们采用 Spring Boot 作为基础框架，这是目前 Java 生态中最主流的选择。
以下是本项目推荐的目录结构，请严格按照此结构创建文件，避免包引用错误：
platonic-love-project/
├── pom.xml
├── src/
│ ├── main/
│ │ ├── java/
│ │ │ └── com/
│ │ │ └── example/
│ │ │ └── platonic/
│ │ │ ├── PlatonicApplication.java // 启动类
│ │ │ ├── config/
│ │ │ │ └── GlobalExceptionHandler.java // 全局异常处理器
│ │ │ ├── controller/
│ │ │ │ └── LoveController.java // 控制器
│ │ │ ├── service/
│ │ │ │ ├── LoveService.java // 服务接口
│ │ │ │ └── impl/
│ │ │ │ └── LoveServiceImpl.java // 服务实现
│ │ │ ├── exception/
│ │ │ │ ├── BusinessException.java // 业务异常
│ │ │ │ └── ErrorCode.java // 错误码枚举
│ │ │ └── dto/
│ │ │ └── Result.java // 统一响应结果
│ │ └── resources/
│ │ └── application.yml
│ └── test/
│ └── java/
│ └── com/
│ └── example/
│ └── platonic/
│ └── PlatonicApplicationTests.java
关键点说明：
exception 包：这是本次实战项目的灵魂，所有自定义异常都放在这里。
config 包：全局异常拦截器，负责捕获所有未被局部捕获的异常。
dto 包：统一的数据传输对象，确保前后端交互格式一致。
请确保你的本地 JDK 版本为 11 或 17，Maven 版本 3.6+。如果你还在用 Eclipse，建议切换到 IDEA，因为 IDEA 对 Spring Boot 的异常调试支持更好，能直接在堆栈窗口点击跳转，极大提升排查效率。
核心代码实现：从报错到规范
接下来进入硬核部分。我们将分步构建这个实战项目的核心逻辑。
1. 定义错误码与业务异常
在真实的实战项目中，错误不能只靠文字描述，必须标准化。我们创建一个 ErrorCode 枚举：
package com.example.platonic.exception;
import lombok.Getter;
/**
* 错误码定义
* 参考行业规范：1000-1999 为系统错误，2000-2999 为业务错误
*/
@Getter
public enum ErrorCode {
// 系统级错误
SYSTEM_ERROR(1001, 系统内部错误，请联系管理员),
DB_CONNECTION_ERROR(1002, 数据库连接失败),
// 业务级错误
LOVE_TARGET_NOT_FOUND(2001, 心仪对象不存在或已脱单),
MESSAGE_SEND_LIMIT(2002, 消息发送频率过高，请冷静一下),
INVALID_AGE_RANGE(2003, 年龄不符合柏拉图式交往标准);
private final int code;
private final String message;
ErrorCode(int code, String message) {
this.code = code;
this.message = message;
}
}
接着，创建 BusinessException，继承自 RuntimeException：
package com.example.platonic.exception;
import lombok.Getter;
import lombok.Setter;
/**
* 自定义业务异常
* 用于捕获可预期的业务逻辑错误
*/
@Getter
@Setter
public class BusinessException extends RuntimeException {
private final int code;
public BusinessException(ErrorCode errorCode) {
super(errorCode.getMessage());
this.code = errorCode.getCode();
}
public BusinessException(int code, String message) {
super(message);
this.code = code;
}
}
逐行讲解：
继承 RuntimeException：因为业务错误通常是可预期的（如用户输入错误），不应强制开发者使用 throws 声明，这样代码更简洁。
final int code：错误码是常量，不可变，确保日志记录和前端解析的一致性。
2. 全局异常处理器：StackTrace 的终结者
这是解决“报错一堆看不懂”的关键。我们使用 Spring 的 @RestControllerAdvice 注解：
package com.example.platonic.config;
import com.example.platonic.dto.Result;
import com.example.platonic.exception.BusinessException;
import com.example.platonic.exception.ErrorCode;
import lombok.extern.slf4j.Slf4j;
import org.springframework.web.bind.annotation.ExceptionHandler;
import org.springframework.web.bind.annotation.RestControllerAdvice;
/**
* 全局异常处理器
* 拦截所有 Controller 抛出的异常
*/
@Slf4j
@RestControllerAdvice
public class GlobalExceptionHandler {
/**
* 处理业务异常
* 此时不打印完整堆栈，因为这是预期的业务逻辑
*/
@ExceptionHandler(BusinessException.class)
public Result? handleBusinessException(BusinessException e) {
log.warn(业务异常发生: Code={}, Message={}, e.getCode(), e.getMessage());
return Result.error(e.getCode(), e.getMessage());
}
/**
* 处理未知系统异常
* 此时必须打印完整堆栈，用于开发人员排查
*/
@ExceptionHandler(Exception.class)
public Result? handleSystemException(Exception e) {
// 关键点：这里才打印堆栈，且记录为 ERROR 级别
log.error(系统未知异常: , e);
return Result.error(ErrorCode.SYSTEM_ERROR.getCode(),
ErrorCode.SYSTEM_ERROR.getMessage());
}
}
深度解析：
注意看 handleSystemException 方法。当发生未知异常时，我们调用 log.error(系统未知异常: , e)。这里的 e 会被 SLF4J 自动识别为 Throwable 对象，从而打印完整的 StackTrace。
而在生产环境中，前端用户只会看到 Result 返回的 SYSTEM_ERROR 提示，不会看到那堆红色的代码。这就是实战项目中“异常隔离”的核心思想：开发看堆栈，用户看提示。
3. 统一响应结果类
package com.example.platonic.dto;
import lombok.Data;
@Data
public class ResultT {
private int code;
private String message;
private T data;
public static T ResultT success(T data) {
ResultT result = new Result();
result.setCode(200);
result.setMessage(操作成功);
result.setData(data);
return result;
}
public static T ResultT error(int code, String message) {
ResultT result = new Result();
result.setCode(code);
result.setMessage(message);
return result;
}
}
运行与测试：复现那个“天书”错误
代码写完了，怎么验证它真的能解决 StackTrace 的问题？我们需要主动制造错误。
修改 LoveServiceImpl.java，添加一个故意触发空指针的场景：
package com.example.platonic.service.impl;
import com.example.platonic.exception.BusinessException;
import com.example.platonic.exception.ErrorCode;
import com.example.platonic.service.LoveService;
import org.springframework.stereotype.Service;
@Service
public class LoveServiceImpl implements LoveService {
@Override
public String sendFlower(String targetName) {
// 模拟业务逻辑：如果对象为空，抛出业务异常
if (targetName == null || targetName.isEmpty()) {
throw new BusinessException(ErrorCode.LOVE_TARGET_NOT_FOUND);
}
// 模拟系统错误：故意制造 NullPointerException
// 在真实项目中，这可能是因为依赖注入失败或配置错误
String config = null;
config.trim(); // 这里会抛出 NullPointerException
return 送花成功;
}
}
编写 Controller：
package com.example.platonic.controller;
import com.example.platonic.dto.Result;
import com.example.platonic.service.LoveService;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.RestController;
@RestController
public class LoveController {
@Autowired
private LoveService loveService;
@GetMapping(/send-flower)
public ResultString sendFlower(@RequestParam(required = false) String target) {
return Result.success(loveService.sendFlower(target));
}
}
测试步骤：
启动应用。
访问 http://localhost:8080/send-flower?target=LiMing。
观察控制台日志和浏览器返回结果。
预期结果：
浏览器返回：
{
code: 1001,
message: 系统内部错误，请联系管理员,
data: null
}
控制台日志：
你会看到一条 ERROR 级别的日志，后面跟着完整的 java.lang.NullPointerException 堆栈信息。
这就是区别所在。 如果没有 GlobalExceptionHandler，浏览器会直接返回 500 错误，并且可能包含 HTML 格式的堆栈信息（取决于配置），或者干脆白屏。现在，我们拿到了干净的 JSON，而开发人员通过日志拿到了详细的 StackTrace。
如果你发现控制台没有打印堆栈，请检查 application.yml 中的日志级别配置，确保 root: INFO 或 com.example.platonic: DEBUG。
优化扩展与避坑指南
在真实的实战项目中，仅仅能捕获异常是不够的，还需要考虑性能和可维护性。
1. 异步日志记录
高并发场景下，log.error 同步写入磁盘可能会阻塞线程。建议引入异步日志配置：
logging:
file:
name: logs/platonic.log
pattern:
console: %d{yyyy-MM-dd HH:mm:ss} [%thread] %-5level %logger{36} - %msg%n
并在 logback-spring.xml 中配置 AsyncAppender。这样，即使 StackTrace 很长，也不会拖慢接口响应速度。
2. 避免在循环中抛出异常
这是一个常见的性能陷阱。如果在 for 循环中频繁抛出 BusinessException，JVM 需要不断填充堆栈跟踪，消耗大量 CPU 资源。
错误示范：
for (Item item : list) {
if (item.isInvalid()) {
throw new BusinessException(ErrorCode.INVALID_ITEM); // 高频抛异常，性能杀手
}
}
正确做法：
先收集所有错误，最后统一抛出，或者在循环外进行校验。
3. 参考开源实现
为了让大家看到工业级的写法，推荐参考 GitHub 上的开源仓库 jeecg-boot 或 ruoyi-vue。这两个项目都是国内非常流行的 Java 后台管理系统框架，它们的全局异常处理模块非常成熟。
你可以直接在 GitHub 搜索 jeecg-boot global exception，查看它们是如何处理 SQL 异常、参数校验异常（MethodArgumentNotValidException）以及自定义业务异常的。它们的 Result 封装和错误码设计，都是经过大规模实战项目验证的，值得借鉴。
注意： 不要直接复制粘贴，要结合你项目的实际需求进行裁剪。比如，jeecg-boot 的错误码体系非常庞大，如果你的项目只是一个小工具，只需要保留核心的 5-10 个错误码即可。
4. 前端配合
后端返回的 code 和 message 只是第一步。前端需要配置 Axios 的拦截器，统一处理非 200 的响应：
axios.interceptors.response.use(
response = {
const res = response.data;
if (res.code !== 200) {
// 弹出提示
Message.error(res.message);
return Promise.reject(new Error(res.message));
}
return res;
},
error = {
// 处理网络错误
Message.error('网络异常，请稍后重试');
return Promise.reject(error);
}
);
这样，无论后端抛出什么异常，用户看到的都是统一的友好提示，而不是原始的 StackTrace 文本。
小结
回顾一下这个柏拉图恋爱的实战项目，我们从最头疼的 StackTrace 入手，通过以下三步实现了规范的异常处理：
定义规范：建立 ErrorCode 枚举和 BusinessException 类，将错误标准化。
全局拦截：使用 @RestControllerAdvice 统一捕获异常，区分业务异常和系统异常。
分层处理：业务异常只记录日志，不暴露细节；系统异常记录完整堆栈，但对外返回通用提示。
这套方案不仅解决了“报错看不懂”的问题，更提升了系统的可维护性和用户体验。在以后的实战项目中，无论是 Spring Boot 还是其他框架，异常处理的核心思想都是相通的：隔离错误、标准化输出、分级记录。
技术之路，没有银弹，只有不断的实践和踩坑。这个小小的示例，希望能成为你排查复杂堆栈问题的起点。
还有什么不懂的？评论区留言挨个回 
长河君 · 2026/9/22 6:37:41 · 阅读 1.2k 柏拉图恋爱实战项目3步搞定报错堆栈
柏拉图恋爱实战项目3步搞定报错堆栈
报错一堆看不懂 StackTrace？ 别慌，这往往是新手在实战项目里最容易卡壳的地方。很多人对着满屏红色代码发呆，根本不知道问题出在哪一行，更别提怎么修了。其实，只要理清逻辑，哪怕是最复杂的异常链，也能拆解成几个简单的断点。
今天咱们不讲虚的，直接上手一个名为柏拉图恋爱的模拟系统。这名字听着浪漫，实际上是个标准的 Java 后端实战项目，用来演示如何优雅地处理业务异常和系统异常。我们会从零搭建，重点攻克那个让人头大的 StackTrace。
项目目标与核心痛点解析
先说清楚，为什么选“柏拉图恋爱”这个名字？因为在软件工程中，我们常把这种“纯逻辑、无物理交互”的数据流转比作精神恋爱——数据在内存里穿梭，没有落盘，全靠代码逻辑维系。
这个实战项目的核心目标只有一个：让异常变得可读。
在传统的初学者代码里，你经常看到这样的写法：
try {
// 复杂业务逻辑
} catch (Exception e) {
e.printStackTrace();
}
这就是痛点所在。e.printStackTrace() 会把几千行的堆栈信息直接打印到控制台。在本地调试时，你可能还能一眼扫到关键行；但在生产环境，或者当嵌套层级超过三层时，这堆字符就像天书一样。你根本不知道是数据库连不上，还是参数校验失败，或者是某个空指针引用。
我们的目标，是通过封装自定义异常、统一异常处理器，将这种“天书”转化为人类能读懂的“错误码 + 友好提示”。这就是本次实战项目要解决的核心问题。
目录结构与环境准备
工欲善其事，必先利其器。为了保证实战项目的可复现性，我们采用 Spring Boot 作为基础框架，这是目前 Java 生态中最主流的选择。
以下是本项目推荐的目录结构，请严格按照此结构创建文件，避免包引用错误：
platonic-love-project/
├── pom.xml
├── src/
│ ├── main/
│ │ ├── java/
│ │ │ └── com/
│ │ │ └── example/
│ │ │ └── platonic/
│ │ │ ├── PlatonicApplication.java // 启动类
│ │ │ ├── config/
│ │ │ │ └── GlobalExceptionHandler.java // 全局异常处理器
│ │ │ ├── controller/
│ │ │ │ └── LoveController.java // 控制器
│ │ │ ├── service/
│ │ │ │ ├── LoveService.java // 服务接口
│ │ │ │ └── impl/
│ │ │ │ └── LoveServiceImpl.java // 服务实现
│ │ │ ├── exception/
│ │ │ │ ├── BusinessException.java // 业务异常
│ │ │ │ └── ErrorCode.java // 错误码枚举
│ │ │ └── dto/
│ │ │ └── Result.java // 统一响应结果
│ │ └── resources/
│ │ └── application.yml
│ └── test/
│ └── java/
│ └── com/
│ └── example/
│ └── platonic/
│ └── PlatonicApplicationTests.java
关键点说明：
exception 包：这是本次实战项目的灵魂，所有自定义异常都放在这里。
config 包：全局异常拦截器，负责捕获所有未被局部捕获的异常。
dto 包：统一的数据传输对象，确保前后端交互格式一致。
请确保你的本地 JDK 版本为 11 或 17，Maven 版本 3.6+。如果你还在用 Eclipse，建议切换到 IDEA，因为 IDEA 对 Spring Boot 的异常调试支持更好，能直接在堆栈窗口点击跳转，极大提升排查效率。
核心代码实现：从报错到规范
接下来进入硬核部分。我们将分步构建这个实战项目的核心逻辑。
1. 定义错误码与业务异常
在真实的实战项目中，错误不能只靠文字描述，必须标准化。我们创建一个 ErrorCode 枚举：
package com.example.platonic.exception;
import lombok.Getter;
/**
* 错误码定义
* 参考行业规范：1000-1999 为系统错误，2000-2999 为业务错误
*/
@Getter
public enum ErrorCode {
// 系统级错误
SYSTEM_ERROR(1001, 系统内部错误，请联系管理员),
DB_CONNECTION_ERROR(1002, 数据库连接失败),
// 业务级错误
LOVE_TARGET_NOT_FOUND(2001, 心仪对象不存在或已脱单),
MESSAGE_SEND_LIMIT(2002, 消息发送频率过高，请冷静一下),
INVALID_AGE_RANGE(2003, 年龄不符合柏拉图式交往标准);
private final int code;
private final String message;
ErrorCode(int code, String message) {
this.code = code;
this.message = message;
}
}
接着，创建 BusinessException，继承自 RuntimeException：
package com.example.platonic.exception;
import lombok.Getter;
import lombok.Setter;
/**
* 自定义业务异常
* 用于捕获可预期的业务逻辑错误
*/
@Getter
@Setter
public class BusinessException extends RuntimeException {
private final int code;
public BusinessException(ErrorCode errorCode) {
super(errorCode.getMessage());
this.code = errorCode.getCode();
}
public BusinessException(int code, String message) {
super(message);
this.code = code;
}
}
逐行讲解：
继承 RuntimeException：因为业务错误通常是可预期的（如用户输入错误），不应强制开发者使用 throws 声明，这样代码更简洁。
final int code：错误码是常量，不可变，确保日志记录和前端解析的一致性。
2. 全局异常处理器：StackTrace 的终结者
这是解决“报错一堆看不懂”的关键。我们使用 Spring 的 @RestControllerAdvice 注解：
package com.example.platonic.config;
import com.example.platonic.dto.Result;
import com.example.platonic.exception.BusinessException;
import com.example.platonic.exception.ErrorCode;
import lombok.extern.slf4j.Slf4j;
import org.springframework.web.bind.annotation.ExceptionHandler;
import org.springframework.web.bind.annotation.RestControllerAdvice;
/**
* 全局异常处理器
* 拦截所有 Controller 抛出的异常
*/
@Slf4j
@RestControllerAdvice
public class GlobalExceptionHandler {
/**
* 处理业务异常
* 此时不打印完整堆栈，因为这是预期的业务逻辑
*/
@ExceptionHandler(BusinessException.class)
public Result? handleBusinessException(BusinessException e) {
log.warn(业务异常发生: Code={}, Message={}, e.getCode(), e.getMessage());
return Result.error(e.getCode(), e.getMessage());
}
/**
* 处理未知系统异常
* 此时必须打印完整堆栈，用于开发人员排查
*/
@ExceptionHandler(Exception.class)
public Result? handleSystemException(Exception e) {
// 关键点：这里才打印堆栈，且记录为 ERROR 级别
log.error(系统未知异常: , e);
return Result.error(ErrorCode.SYSTEM_ERROR.getCode(),
ErrorCode.SYSTEM_ERROR.getMessage());
}
}
深度解析：
注意看 handleSystemException 方法。当发生未知异常时，我们调用 log.error(系统未知异常: , e)。这里的 e 会被 SLF4J 自动识别为 Throwable 对象，从而打印完整的 StackTrace。
而在生产环境中，前端用户只会看到 Result 返回的 SYSTEM_ERROR 提示，不会看到那堆红色的代码。这就是实战项目中“异常隔离”的核心思想：开发看堆栈，用户看提示。
3. 统一响应结果类
package com.example.platonic.dto;
import lombok.Data;
@Data
public class ResultT {
private int code;
private String message;
private T data;
public static T ResultT success(T data) {
ResultT result = new Result();
result.setCode(200);
result.setMessage(操作成功);
result.setData(data);
return result;
}
public static T ResultT error(int code, String message) {
ResultT result = new Result();
result.setCode(code);
result.setMessage(message);
return result;
}
}
运行与测试：复现那个“天书”错误
代码写完了，怎么验证它真的能解决 StackTrace 的问题？我们需要主动制造错误。
修改 LoveServiceImpl.java，添加一个故意触发空指针的场景：
package com.example.platonic.service.impl;
import com.example.platonic.exception.BusinessException;
import com.example.platonic.exception.ErrorCode;
import com.example.platonic.service.LoveService;
import org.springframework.stereotype.Service;
@Service
public class LoveServiceImpl implements LoveService {
@Override
public String sendFlower(String targetName) {
// 模拟业务逻辑：如果对象为空，抛出业务异常
if (targetName == null || targetName.isEmpty()) {
throw new BusinessException(ErrorCode.LOVE_TARGET_NOT_FOUND);
}
// 模拟系统错误：故意制造 NullPointerException
// 在真实项目中，这可能是因为依赖注入失败或配置错误
String config = null;
config.trim(); // 这里会抛出 NullPointerException
return 送花成功;
}
}
编写 Controller：
package com.example.platonic.controller;
import com.example.platonic.dto.Result;
import com.example.platonic.service.LoveService;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.RestController;
@RestController
public class LoveController {
@Autowired
private LoveService loveService;
@GetMapping(/send-flower)
public ResultString sendFlower(@RequestParam(required = false) String target) {
return Result.success(loveService.sendFlower(target));
}
}
测试步骤：
启动应用。
访问 http://localhost:8080/send-flower?target=LiMing。
观察控制台日志和浏览器返回结果。
预期结果：
浏览器返回：
{
code: 1001,
message: 系统内部错误，请联系管理员,
data: null
}
控制台日志：
你会看到一条 ERROR 级别的日志，后面跟着完整的 java.lang.NullPointerException 堆栈信息。
这就是区别所在。 如果没有 GlobalExceptionHandler，浏览器会直接返回 500 错误，并且可能包含 HTML 格式的堆栈信息（取决于配置），或者干脆白屏。现在，我们拿到了干净的 JSON，而开发人员通过日志拿到了详细的 StackTrace。
如果你发现控制台没有打印堆栈，请检查 application.yml 中的日志级别配置，确保 root: INFO 或 com.example.platonic: DEBUG。
优化扩展与避坑指南
在真实的实战项目中，仅仅能捕获异常是不够的，还需要考虑性能和可维护性。
1. 异步日志记录
高并发场景下，log.error 同步写入磁盘可能会阻塞线程。建议引入异步日志配置：
logging:
file:
name: logs/platonic.log
pattern:
console: %d{yyyy-MM-dd HH:mm:ss} [%thread] %-5level %logger{36} - %msg%n
并在 logback-spring.xml 中配置 AsyncAppender。这样，即使 StackTrace 很长，也不会拖慢接口响应速度。
2. 避免在循环中抛出异常
这是一个常见的性能陷阱。如果在 for 循环中频繁抛出 BusinessException，JVM 需要不断填充堆栈跟踪，消耗大量 CPU 资源。
错误示范：
for (Item item : list) {
if (item.isInvalid()) {
throw new BusinessException(ErrorCode.INVALID_ITEM); // 高频抛异常，性能杀手
}
}
正确做法：
先收集所有错误，最后统一抛出，或者在循环外进行校验。
3. 参考开源实现
为了让大家看到工业级的写法，推荐参考 GitHub 上的开源仓库 jeecg-boot 或 ruoyi-vue。这两个项目都是国内非常流行的 Java 后台管理系统框架，它们的全局异常处理模块非常成熟。
你可以直接在 GitHub 搜索 jeecg-boot global exception，查看它们是如何处理 SQL 异常、参数校验异常（MethodArgumentNotValidException）以及自定义业务异常的。它们的 Result 封装和错误码设计，都是经过大规模实战项目验证的，值得借鉴。
注意： 不要直接复制粘贴，要结合你项目的实际需求进行裁剪。比如，jeecg-boot 的错误码体系非常庞大，如果你的项目只是一个小工具，只需要保留核心的 5-10 个错误码即可。
4. 前端配合
后端返回的 code 和 message 只是第一步。前端需要配置 Axios 的拦截器，统一处理非 200 的响应：
axios.interceptors.response.use(
response = {
const res = response.data;
if (res.code !== 200) {
// 弹出提示
Message.error(res.message);
return Promise.reject(new Error(res.message));
}
return res;
},
error = {
// 处理网络错误
Message.error('网络异常，请稍后重试');
return Promise.reject(error);
}
);
这样，无论后端抛出什么异常，用户看到的都是统一的友好提示，而不是原始的 StackTrace 文本。
小结
回顾一下这个柏拉图恋爱的实战项目，我们从最头疼的 StackTrace 入手，通过以下三步实现了规范的异常处理：
定义规范：建立 ErrorCode 枚举和 BusinessException 类，将错误标准化。
全局拦截：使用 @RestControllerAdvice 统一捕获异常，区分业务异常和系统异常。
分层处理：业务异常只记录日志，不暴露细节；系统异常记录完整堆栈，但对外返回通用提示。
这套方案不仅解决了“报错看不懂”的问题，更提升了系统的可维护性和用户体验。在以后的实战项目中，无论是 Spring Boot 还是其他框架，异常处理的核心思想都是相通的：隔离错误、标准化输出、分级记录。
技术之路，没有银弹，只有不断的实践和踩坑。这个小小的示例，希望能成为你排查复杂堆栈问题的起点。
还有什么不懂的？评论区留言挨个回