一、使用 Spring 拦截器来实现登录验证
引入
一般来说，session 会话被我们用来作为用户的登录验证，以往我们会封装一个类，专门用于获取 session 中的用户，如果获取到了，说明用户已经登录了；反之，则没有登录。但即便封装一个类，在每个 Controller 类中，依然需要通过此封装好的类，写几行代码来继续验证用户是否已经登录了。所以，每个控制层都需要验证，这其实很不方便。
所以，就有了 Spring 拦截器的功能，它可以自定义我们想要拦截的页面。然而，我们仍然是需要 Servlet 为我们提供的 request 对象，因为它和 session 会话紧密相连。
代码实现
步骤1 自定义拦截器
① 创建一个类 (自定义拦截器)
② 让当前类实现 Spring 框架提供的 HandlerInterceptor 接口
③ 重写 preHandle 方法 (需要明确，这一步拦截器的逻辑是由我们自己实现的。)
创建 LoginInterceptor 类，作为登录拦截的作用：
// 自定义用户登录的拦截器(自定义拦截前端访问的逻辑) @Component public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { HttpSession httpSession = request.getSession(false); if (httpSession != null && httpSession.getAttribute("userinfo") != null) { // 表示用户已经登录 return true; } // 代码走到这里，说明用户还未登录 // 在这里可以实现自己的业务逻辑，比方说让用户再次跳转到登录页面 response.sendRedirect("login.html"); return false; } }
对 preHandle 方法进行说明：
preHandle 方法的返回值是布尔类型的，如果最终我们的代码返回 true，表示判断通过，可以访问后面的接口(控制层)；如果最终我们的代码返回 false，表示拦截器拦截成功，直接返回错误结果 (空白页面) 给前端。
实际上，这就是 AOP 的思想，拦截器在前端和后端中间插了一杠子，此时，前端访问并不直接与控制层打交道了，而是先和拦截器这个动态代理打交道，如果代理这一关过了，才能继续走后端的接口。
步骤2 添加拦截器并设置拦截规则
将步骤1 自定义的拦截器加入到框架的配置中，并且设置拦截规则。
① 创建一个类并标明 " @Configuration " 注解
② 让当前类实现 WebMvcConfigurer 接口
③ 重写 addInterceptors 方法，在方法中添加拦截规则
创建 AddConfiguration 类，添加一些拦截规则：
@Configuration public class AddConfiguration implements WebMvcConfigurer { @Autowired private LoginInterceptor loginInterceptor; @Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(loginInterceptor). addPathPatterns("/**"). // 拦截所有 URL excludePathPatterns("/login"). // 不拦截登录接口 excludePathPatterns("/register"). // 不拦截注册接口 excludePathPatterns("/login.html"). // 不拦截登录的静态页面 excludePathPatterns("/**/*.js"). // 不拦截所有的 js 文件 excludePathPatterns("/**/*.css"). // 不拦截所有的 css 文件 excludePathPatterns("/**/*.png"); // 不拦截所有的 png 图片 } }
拦截规则
① addPathPatterns：表示需要拦截的 URL
② excludePathPatterns：表示不需要拦截的 URL
③ **：表示拦截所有方法
④ 拦截规则不仅可以拦截 URL，也可以拦截静态 html页面，CSS、JS 文件
步骤3 创建前后端交互，用于测试
创建 UserController 类，与前端交互：
@RestController public class UserController { @RequestMapping("/login") public String login(HttpServletRequest request, String username, String password) { if (StringUtils.hasLength(username) && StringUtils.hasLength(password)) { if (username.equals("Jack") && password.equals("123")) { // 登录成功后，创建 session 会话，并往会话中放入 userinfo 对象 HttpSession httpSession = request.getSession(true); httpSession.setAttribute("userinfo", "userinfo"); return "<h1> 登录成功 </h1>"; } } return "<h1> 登录失败 </h1>"; } @RequestMapping("/index") public String index() { return "你好，index"; } }
创建 login.html，以作登录失败的跳转提示：
<!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <meta http-equiv="X-UA-Compatible" content="IE=edge"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>login 页面</title> </head> <body> <h1>请重新登录</h1> </body> </html>
展示效果：
在我们未登录而访问 index 路径时，就会重定向至登录页面了。
当我们登录成功后，才能正确访问被拦截的页面：
拦截器原理
拦截器在前端和后端中间插了一杠子，此时，前端访问并不直接与控制层打交道了，而是先和拦截器这个动态代理打交道。拦截器就像高铁站的安检一样，只有前端通过了安检，才能与后端控制层打交道。
此外，一个项目中可以同时配置多个拦截器。比方说，一个拦截器作为登录验证；另一个拦截器用作前端传递来的非法参数校验。( 只是两个的拦截逻辑和拦截规则不同罢了 )
二、统一异常处理
引入
假设你在浏览网页的时候，出现了下面的页面，你会有什么心情？
显然，你的第一反应不是懵懵的，就是暴躁的，反正不是快乐的。
如果我们做一个项目，未考虑到服务器端代码的异常、用户的传参异常，或是其他异常，就会出现类似于上面的错误信息。上面的 " 500 " 状态码，显然就意味着服务器端出错了。因为用户并不是程序员，他们根本看不懂后端的错误提示，甚至连前端拿到 500 这样的错误信息，也不知道后端出现了什么问题。所以，前后端如何配合，才能够将异常以一种 " 可理解 " 的方式展现在大众面前，是一件非常有意义的事情。
代码实现
① 创建一个异常类
② 为类添加 " @RestControllerAdvice " / " @ControllerAdvice " 注解
③ 为方法上添加 " @ExceptionHandler(xxx.class) " 注解
创建 MyExceptionAdvice 类，在里面实现统一异常处理
@RestControllerAdvice public class MyExceptionAdvice { @ExceptionHandler(Exception.class) public HashMap<String, Object> ExceptionAdvice(Exception e) { HashMap<String, Object> result = new HashMap<>(); result.put("status", -1); result.put("data", null); result.put("message", "发现异常：" + e.getMessage()) ; System.out.println("异常出现的位置："); e.printStackTrace(); return result; } @ExceptionHandler(NullPointerException.class) public HashMap<String, Object> nullPointExceptionAdvice(NullPointerException e) { HashMap<String, Object> result = new HashMap<>(); result.put("status", -1); result.put("data", null); result.put("message", "空指针异常：" + e.getMessage()); System.out.println("异常出现的位置："); e.printStackTrace(); // 给后端程序员观看出错的位置 return result; // 将异常数据打包成 json 数据，交给前端 } }
创建 UserController 类，用于测试：
@RestController public class UserController { @RequestMapping("/index") public String index() { return "你好，index"; } @RequestMapping("/error_demo") public String error(){ String result = null; result.equals("123"); // 空指针异常 return null; } @RequestMapping("/error_demo2") public String error2(){ int a = 10 / 0; // 算数异常 return null; } }
展示结果：json 数据
IDEA 控制台打印异常日志：
注意事项：
① 异常有很多种，算数异常、数组越界、空指针异常…我们不可能将所有异常全部列举出来，所以我们可以写所有异常的父类 Exception.
② 当指定的异常和 Exception 异常同时存在，那么异常类会先执行前者。就如上面的例子，我已经指定了空指针异常，也写出了 Exception 异常，但最终执行的是空指针异常。
③ 后端不但要保证能够将简化后的异常信息返回给前端，也要知道异常的问题出现在了什么地方。所以，后端使用 " e.printStackTrace(); " 就能够在 IDEA 上很好地观察异常出现位置。
④ 前端一般只需要拿到约定的错误数据即可 (常见的 json 数据)，至于怎么将错误信息展示给用户看，是前端的职责。遇到异常，怎么修改，这才是后端的事情。
三、统一数据返回格式
① 创建一个统一数据返回格式的类
② 为类添加 " @RestControllerAdvice " / " @ControllerAdvice " 注解
③ 让类实现 ResponseBodyAdvice 接口
④ 重写 supports、beforeBodyWrite 方法
创建 MyResponseAdvice 类，在里面构造统一返回对象
@RestControllerAdvice public class MyResponseAdvice implements ResponseBodyAdvice { /** * 如果返回 true， 表示返回数据之前对数据进行重写，也就会进入 beforeBodyWrite 方法 * 如果返回 false，表示结果不进行任何处理，直接返回 */ @Override public boolean supports(MethodParameter returnType, Class converterType) { return true; } @Override public Object beforeBodyWrite(Object body, MethodParameter returnType, MediaType selectedContentType, Class selectedConverterType, ServerHttpRequest request, ServerHttpResponse response) { // 构造统一返回对象 HashMap<String, Object> result = new HashMap<>(); result.put("status", 1); result.put("data", body); // 将原先放在 body 数据的内容，现在放在了 data 之中 result.put("message", ""); return result; } }
创建 UserController 类，用于测试：
@RestController public class UserController { @RequestMapping("/login2") public boolean login2(HttpServletRequest request, String username, String password) { if (StringUtils.hasLength(username) && StringUtils.hasLength(password)) { if (username.equals("Jack") && password.equals("123")) { HttpSession httpSession = request.getSession(true); httpSession.setAttribute("userinfo", "userinfo"); return true; } } return false; } }
展示结果：
注意事项：
统一数据返回格式的优点有很多，比如以下几个：
① 方便前端程序员更好的接收和解析后端数据接口返回的数据。
② 降低前端程序员和后端程序员的沟通成本，两者按照某个格式实现就行了，因为所有接口都是这样返回的。此外，更有利于项目统一数据的维护和修改。
③ 有利于后端技术部门的统一规范的标准制定，不会出现稀奇古怪的返回内容。
但实际上，统一也就意味着不能个性化，如果前后端交互的数据是统一的，在某些特殊的场景下，不能够很好地解决、优化问题。所以，是否选择统一数据返回，还需要根据具体的业务场景决定。
四、为所有前端发送的 URL 地址都添加前缀 (了解)
@Configuration public class AddConfiguration implements WebMvcConfigurer { // 为所有前端发送的 URL 地址都添加前缀 @Override public void configurePathMatch(PathMatchConfigurer configurer) { configurer.addPathPrefix("app", c -> true); } }
