0 拦截器

路径1

在Web开发中，一个Web应用通常会被部署到一个Servlet容器中（例如Tomcat、Jetty等），并且这个应用会有一个上下文（Context）根目录。这个上下文根目录是Web应用的基础目录，它包含了应用的所有资源，如HTML文件、JSP页面、图片、CSS样式表、JavaScript脚本等。

当通过Web服务器访问这些资源时，资源的URL路径是相对于这个上下文根目录的。例如，如果你的Web应用的上下文根是/myapp，并且有一个名为index.html的文件位于这个根目录下，那么可以通过URL http://yourserver/myapp/index.html 来访问这个文件。

在Spring MVC的静态资源配置中，“/” 通常指的就是这个上下文根目录。所以，当在配置静态资源位置时使用"/"，实际上是在告诉Spring MVC，在Web应用的上下文根目录中查找静态资源。

然而，需要注意的是，当使用Spring Boot等框架时，静态资源通常会被放置在特定的目录（如src/main/resources/static）下，在打包成WAR或JAR文件后，这些资源会被自动映射到Web应用的上下文根目录。因此，在这种情况下，即使配置资源位置为"/"，Spring Boot也会知道如何正确地将请求映射到这些资源。

在实际应用中，为了避免混淆和潜在的路径冲突，通常会为静态资源设定一个明确的路径前缀，如/static/，而不是使用"/"来代表所有路径。这样做可以确保静态资源和动态资源（如由控制器处理的请求）之间有清晰的分隔。

路径2

@Override:
这个注解表明该方法重写了其父类或接口中的方法。在这里，它重写了WebMvcConfigurer接口中的addResourceHandlers方法。

public void addResourceHandlers(ResourceHandlerRegistry registry):
这是addResourceHandlers方法的声明，它接收一个ResourceHandlerRegistry对象作为参数，这个对象用于注册资源处理器。

registry.addResourceHandler(“/**”).addResourceLocations(“/”, “classpath:webapp/”);:

addResourceHandler("/**"): 这个方法定义了哪些URL路径将被视为静态资源请求。"/**"表示所有的路径，意味着所有的请求都会被当作是请求静态资源的候选。

addResourceLocations(“/”, “classpath:webapp/”): 这个方法指定了静态资源的实际位置。在这里，它定义了两个位置：
“/”: 通常指的是项目的根目录（在Servlet容器中，这通常是Web应用的上下文根目录）。
“classpath:webapp/”: 指的是类路径下的webapp目录，这通常用于打包在JAR或WAR文件中的资源。
当请求静态资源时，Spring MVC会根据这两个位置来查找和提供资源。

WebMvcConfigurer.super.addResourceHandlers(registry);:
这一行代码调用了WebMvcConfigurer接口中默认的addResourceHandlers实现（如果有的话）。这通常不是必需的，除非有特殊的需求要保留Spring Boot或其他配置中的默认静态资源配置。在大多数情况下，如果完全自定义了静态资源的处理方式，可以省略这一行代码。

需要注意的是，这段代码会覆盖Spring Boot的默认静态资源配置，因此需要谨慎使用，确保了解这样做的后果，并确保新的配置能够正确地提供所需的静态资源。

另外，由于这段代码设置了所有路径"/**"都作为静态资源的候选，这可能会导致与控制器路径冲突。在实际应用中，通常会为静态资源设置一个特定的路径前缀，比如/static/**或/resources/**，以避免这种冲突。

静态资源

在Spring MVC中，/resources/** 通常是一个用于静态资源的默认映射路径，比如 JavaScript、CSS、图片文件等。由于这些资源通常是由Spring MVC的静态资源处理器直接处理的，而不会通过控制器(Controller)和拦截器(Interceptor)链。因此，如果试图用一个拦截器去拦截这些路径，可能会发现拦截器并没有被触发。

然而，在配置中，试图用JwtInterceptor拦截/resources/**路径。如果目的是对静态资源应用某些逻辑（比如验证JWT令牌），通常这不是推荐的做法，因为静态资源请求通常不需要任何业务逻辑处理。

如果发现JwtInterceptor没有拦截到/resources/**路径下的请求，可能的原因有：

静态资源被Spring直接处理：Spring MVC 默认配置了一些静态资源的映射，比如/resources/**，/static/**，/public/**等。这些请求在到达拦截器之前可能已经被Spring的静态资源处理器处理了。

Spring Boot的自动配置：如果在使用Spring Boot，它会自动配置资源处理器来服务静态资源。这可能导致拦截器没有被触发。

拦截器配置顺序：如果在项目中还有其他拦截器，并且它们的配置顺序影响了JwtInterceptor的执行，那么也可能导致拦截不成功。

Spring Security配置：如果项目中集成了Spring Security，并且它的安全配置先于拦截器执行，可能需要调整Spring Security的配置来允许拦截器执行。

如果确实需要对静态资源请求执行某些逻辑，可以考虑以下几种方法：

使用Spring Security的过滤器：如果需要对静态资源进行安全验证，比如检查JWT令牌，可以使用Spring Security的自定义过滤器来在请求到达静态资源处理器之前执行这些检查。

自定义静态资源处理器：可以实现自己的静态资源处理器，并在处理请求之前执行需要的逻辑。

调整Spring MVC的静态资源配置：可以尝试修改或禁用Spring MVC的默认静态资源配置，以便拦截器可以拦截到这些请求。但是，请注意，这可能会影响应用程序的性能和用户体验，因为静态资源请求通常需要快速且无需复杂逻辑处理。

最后，如果目的是保护静态资源，通常建议使用Spring Security等安全框架来处理这类需求，而不是依赖拦截器。

在Spring MVC中，当想要拦截特定的URL路径时，需要在拦截器的配置中指定这些路径模式。这些路径模式用于确定哪些请求应该通过拦截器。Spring支持两种路径匹配模式：PathPattern 和 AntPathMatcher。

PathPattern：这是Spring 5中引入的新模式匹配语法，它更加适合Web使用，并且效率更高。它使用{}来指定变量部分，比如/users/{userId}。
AntPathMatcher：这是较老的路径匹配语法，它使用*来匹配任意字符（但不跨越目录分隔符），使用**来匹配多层路径，例如/app/**/test会匹配/app/dir/subdir/test。
在addInterceptors方法中，可以使用addPathPatterns方法来指定拦截器应当拦截的URL路径模式。以下是一个例子，展示了如何使用addPathPatterns来添加多个路径模式：

@Override  
public void addInterceptors(InterceptorRegistry registry) {  
    registry.addInterceptor(new MyInterceptor())  
            .addPathPatterns("/admin/**", "/user/**", "/api/secure/*");  
}

在这个例子中，MyInterceptor将会被应用到以/admin/、/user/开头的所有路径，以及/api/secure/目录下的所有路径。

如果你的Spring版本支持PathPattern，你可以使用更加灵活的路径模式，例如：

java
.addPathPatterns(“/users/{userId}”, “/orders/{orderId}/details”)
这里，任何匹配/users/任意用户ID或/orders/任意订单ID/details的路径都将被拦截器处理。

请确保路径模式正确无误，并且与应用程序中实际的URL结构相匹配。如果路径模式配置错误，拦截器可能不会如期望的那样工作。

最后，请注意，如果Spring Boot应用启用了spring.mvc.pathmatch.parsing.pattern配置（在application.properties或application.yml中设置为true），则默认使用PathPattern进行路径匹配。如果没有启用该配置，则默认使用AntPathMatcher语法。

log.jsp

在Spring MVC中，静态资源文件（如HTML, CSS, JavaScript, 和图片文件等）通常不会被拦截器（Interceptor）处理，因为它们不是通过Spring MVC的DispatcherServlet来处理的。通常，JSP页面需要经过Controller才能展示，所以如果应用中/login.jsp是直接作为静态资源访问的话，那么它可能不会被拦截器捕获。

如果想要让/login.jsp被JwtInterceptor拦截，需要保证这个请求是经过Spring MVC的Controller处理的。也就是说，需要有一个对应的Controller方法来处理对/login.jsp的请求，并在该方法上应用相应的注解（如@RequestMapping或@GetMapping），然后在该方法内部返回login视图名称，以便Spring MVC的视图解析器能够找到并展示login.jsp页面。

例如，可能需要这样的Controller方法：

@Controller  
public class LoginController {  
  
    @GetMapping("/login")  
    public String login() {  
        return "login"; // 这会查找名为login的视图，通常是login.jsp  
    }  
}

在这种情况下，当用户访问/login时，请求会先经过JwtInterceptor，然后再由LoginController的login()方法处理，并最终展示login.jsp页面。

如果想要确保/login.jsp被当作一个动态请求处理（即经过Controller和拦截器），应该避免让用户直接访问JSP页面，而是通过Controller来转发请求到JSP。

请注意，Spring Boot项目中通常推荐使用Thymeleaf、Freemarker等模板引擎来代替JSP，因为JSP与Spring Boot的集成不是官方推荐的，并且在某些情况下可能会遇到配置和使用上的困难。

另外，在addInterceptor时调用了两次addPathPatterns，其实只需要调用一次，并将所有的路径模式包含在一个调用中，使用逗号分隔。修改后的代码如下：

确保应用中有相应的Controller来处理/login请求，并返回login视图。这样，用户访问/login时就会经过JwtInterceptor。如果想要用户访问/login.jsp也经过拦截器，需要在web.xml或者Spring Security配置中做好相应的URL映射和重定向设置。

springmvc动态请求路径

Spring MVC控制器处理的动态请求路径是由开发者在控制器中通过注解和方法定义指定的。以下是关于Spring MVC控制器处理的动态请求路径的详细解释：

@RequestMapping注解：
在Spring MVC中，@RequestMapping注解用于将请求的URL地址和处理请求的方法关联起来，建立映射关系。这个注解可以标注在类或者方法上。
当标注在类上时，它定义了该控制器处理的所有请求路径的公共前缀。
当标注在方法上时，它定义了具体处理某个请求的路径和HTTP方法（如GET、POST等）。
路径变量和参数：
路径变量：在请求路径中，可以使用占位符（如{id}）来表示动态部分，这些占位符可以在方法参数中通过@PathVariable注解来获取。
请求参数：可以通过@RequestParam注解来获取查询字符串中的参数，或者在路径中使用正则表达式等方式来匹配和获取参数。
REST风格：
Spring MVC支持REST风格的URL设计，这意味着URL路径可以反映资源的层次结构和操作。例如，/users/{userId}/orders/{orderId}这样的路径就很好地表示了用户和资源之间的层次关系。
Ant风格和正则表达式：
在@RequestMapping注解中，可以使用Ant风格的路径模式（如/app/**/data）或者正则表达式来匹配更复杂的路径模式。
HTTP方法限定：
可以通过method属性来限定HTTP方法（如GET、POST、DELETE、PUT等），确保只有特定类型的请求会被处理。
请求参数限定：
可以通过params属性来限定请求必须包含或不能包含某些参数，或者参数必须满足特定的值。
综上所述，Spring MVC控制器处理的动态请求路径是高度可配置的，开发者可以根据应用的需求来定义灵活且富有表现力的URL路径模式。这些路径可以反映资源的结构，支持变量替换，并且可以限定HTTP方法和请求参数，从而实现精细化的请求映射和处理。

类路径下的 webapp/ 文件夹

在Java Web应用程序中，当提到“类路径下的 webapp/ 文件夹”时，它通常指的是位于项目的类路径（classpath）中的一个特定文件夹，名为 webapp。这里的“类路径”是指Java虚拟机在运行时查找类文件和其他资源文件时所遵循的路径。

在开发Java Web应用时，资源和类文件通常会被打包到一个WAR（Web Application Archive）文件中，或者在一个可执行的JAR文件中，或者在开发环境中的某个目录下。webapp/ 文件夹通常用于存放Web应用程序的静态资源，如HTML、CSS、JavaScript文件、图片等。

当使用Spring MVC或其他Java Web框架时，可以配置资源处理器来指定从哪些位置提供静态资源。classpath:webapp/ 是一种指示资源处理器从类路径下的 webapp/ 文件夹中查找资源的语法。

例如，在Spring MVC中，可能会看到这样的配置：

registry.addResourceHandler("/**").addResourceLocations("classpath:webapp/");

这行代码告诉Spring MVC，对于所有进入应用的请求路径（/** 表示匹配所有路径），如果请求的是静态资源，那么Spring MVC应该在类路径下的 webapp/ 文件夹中查找这些资源。

在实际的项目结构中，webapp/ 文件夹可能看起来像这样：

project-root/
|-- src/
|    |-- main/
|      |-- java/
|      |-- resources/
|        |-- webapp/
|          |-- index.html
|          |-- css/
|          |-- js/
|          |-- images/
在这个例子中，webapp/ 文件夹位于 src/main/resources/ 目录下，这是Maven或Gradle等构建工具通常用于存放资源文件的地方。当项目被构建时，webapp/ 文件夹中的内容会被复制到类路径中，使得在运行时可以通过 classpath:webapp/ 来访问这些资源。

资源处理器

1

如果资源处理器被配置为处理所有路径（/**），并且没有为动态请求路径预留空间，这通常意味着静态资源处理器会尝试去处理应用程序接收到的所有HTTP请求。在这种情况下，资源处理器实际上是指Spring MVC中用于提供静态资源（如HTML、CSS、JavaScript文件、图片等）的服务组件。

关于资源处理器，可以归纳为以下几点：

作用：资源处理器的主要作用是提供对静态资源的访问服务。在Web应用程序中，静态资源是那些不需要服务器端执行动态处理就可以直接提供给客户端的文件。

配置：在Spring MVC中，资源处理器通常通过实现WebMvcConfigurer接口并重写addResourceHandlers方法来配置。这个方法允许开发者定义URL模式到资源位置的映射。

问题：当资源处理器被设置为处理所有路径（/**）时，它会尝试服务所有的请求，包括那些本应由控制器处理的动态请求。这会导致控制器中的方法无法被正确调用，因为请求被资源处理器拦截了。

影响：此配置可能会导致动态请求（如表单提交、API调用等）无法正常工作，因为这些请求被错误地识别为对静态资源的请求。这会造成功能失效、性能问题以及潜在的安全风险。

解决方案：为了避免上述问题，最佳实践是为静态资源和动态请求定义不同的URL前缀。例如，可以为静态资源使用特定的路径前缀（如/static/），而动态请求则使用其他路径。这样，资源处理器和控制器就可以分别处理各自负责的请求，而不会发生冲突。

综上所述，资源处理器在Spring MVC中扮演着为静态资源提供服务的重要角色。然而，当它被错误地配置为处理所有路径时，可能会导致与动态请求处理的冲突，从而影响Web应用程序的正常运行。

2

如果资源处理器被配置为处理所有路径（/**），并且没有为动态请求路径预留空间，那么它可能会与由Spring MVC控制器处理的动态请求路径发生冲突。这种冲突会导致以下问题：

请求错误地映射到静态资源：当客户端发送一个应该是动态处理的请求（例如，一个需要后端逻辑处理的POST请求）时，如果这个请求的路径与静态资源的路径模式匹配，它可能会被错误地当作是对静态资源的请求。这样，控制器中的相应处理方法将不会被调用，客户端也无法得到期望的响应。

性能问题：静态资源处理器通常不涉及复杂的后端逻辑，而是直接返回文件系统中的文件。如果所有请求都通过静态资源处理器来处理，那么对于需要后端逻辑处理的动态请求，就会失去控制器中可能存在的性能优化、缓存策略、数据验证等机制。

功能错误：由于静态资源处理器不会执行控制器的逻辑，所以如果动态请求被当作静态资源处理，那么应用的功能将无法正常工作。例如，用户提交表单的数据将不会被处理，因为静态资源处理器只是简单地返回文件，而不是执行后端代码。

安全隐患：如果敏感的动态请求（如用户身份验证或数据修改操作）被当作静态资源请求处理，那么系统的安全性可能会受到威胁，因为这些请求可能没有经过适当的身份验证、授权或输入验证。

为了避免这些问题，最佳实践是为静态资源和动态请求定义不同的URL路径前缀。例如，可以为静态资源使用/static/前缀，而为动态请求使用其他前缀或没有特殊前缀的路径。这样，资源处理器和控制器就可以分别处理它们各自负责的请求类型，而不会发生冲突

3

addResourceHandler 和 addResourceLocations 是 Spring MVC 中用于配置静态资源映射的两个重要方法，通常用在实现 WebMvcConfigurer 接口的配置类中。这两个方法主要用于定义静态资源的请求URL模式与静态资源文件在服务器上的实际位置之间的映射关系。

addResourceHandler

作用：定义哪些URL模式（即客户端请求的URL）应该被映射到静态资源。
用法：addResourceHandler 方法接受一个或多个URL模式作为参数，这些模式通常使用Ant风格的路径匹配。
示例：registry.addResourceHandler(“/static/**”) 表示所有以 /static/ 开头的URL都应该被当作静态资源请求处理。
addResourceLocations

作用：指定静态资源文件在服务器文件系统中的实际位置，或者是在类路径（classpath）中的位置。
用法：addResourceLocations 方法接受一个或多个资源位置作为参数。这些位置可以是文件系统路径，也可以是类路径引用（如 classpath:/ 开头的路径）。
示例：registry.addResourceLocations(“classpath:/webapp/”) 表示静态资源文件位于类路径下的 webapp/ 目录中。
综合使用这两个方法，可以完整地定义一个静态资源的映射规则。例如，以下配置表示：所有以 /static/ 开头的URL请求，都应该从类路径下的 webapp/ 目录中查找对应的静态资源文件。

@Override  
public void addResourceHandlers(ResourceHandlerRegistry registry) {  
    registry.addResourceHandler("/static/**").addResourceLocations("classpath:/webapp/");  
}

在这个配置中，当用户请求一个以 /static/ 开头的URL时，Spring MVC会根据 addResourceLocations 指定的路径去查找并提供相应的静态资源文件。这种配置方式使得开发者能够灵活地组织和提供静态资源，而不必遵循固定的文件结构。

registry.addResourceHandler("/**").addResourceLocations("/","classpath:webapp/");

意味着正在告诉Spring MVC，对于所有的请求路径（/** 表示匹配所有路径），它应该查找静态资源的位置在项目的根目录（/）和类路径下的 webapp/ 文件夹。

然而，通常我们不会将资源处理器配置为处理所有路径（/**），因为这样可能会与控制器处理的动态请求路径发生冲突。通常，我们会为静态资源指定一个特定的前缀，例如 /static/ 或 /resources/，并只为这些前缀配置资源处理器。

例如，如果希望所有在 /static/ 下的请求都映射到类路径下的 webapp/ 文件夹，可以这样配置：

@Override  
public void addResourceHandlers(ResourceHandlerRegistry registry) {  
    registry.addResourceHandler("/static/**").addResourceLocations("classpath:webapp/");  
}

在这个配置中，只有以 /static/ 开头的请求才会被映射到 webapp/ 文件夹中的静态资源。

WebMvcConfigurer.super.addResourceHandlers(registry);，这行代码实际上是调用 WebMvcConfigurer 接口中默认实现的 addResourceHandlers 方法。在大多数情况下，这是不必要的，因为已经覆盖了该方法以提供自定义的资源处理配置。除非有特定的需求要在自定义配置之后添加额外的资源处理器，否则通常可以省略这行代码。

如果发现静态资源被拦截器拦截，很可能是因为资源处理器配置与拦截器的路径配置存在冲突。确保静态资源路径不会与动态请求路径重叠，并且正确配置了资源处理器的路径模式。同时，检查拦截器的配置，确保它不会错误地拦截静态资源请求。

拦截的方式

在Spring框架中，特别是当使用Spring MVC时，拦截器（Interceptor）是处理请求之前或之后执行特定操作的组件。如果你想在拦截器中指定哪些路径应该被拦截，而哪些路径应该被排除，你通常会在拦截器的配置中指定这些路径。

如果你正在使用WebMvcConfigurer接口来配置拦截器，并且你想要指定拦截和排除的路径，那么addPathPatterns和excludePathPatterns是最常用的方法。然而，如果你想要更细粒度的控制或者不同的配置方式，以下是一些替代方案：

自定义拦截器逻辑：
在你的拦截器中，你可以实现自定义的路径匹配逻辑。例如，你可以在preHandle方法中检查请求的URL，并决定是否继续处理该请求。

@Override  
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {  
    String requestURI = request.getRequestURI();  
    // 自定义逻辑来判断是否应该拦截该请求  
    if (shouldIntercept(requestURI)) {  
        // 执行拦截逻辑  
    } else {  
        // 不执行拦截逻辑，直接放行  
    }  
    return true; // 返回true表示继续执行后续的请求处理  
}

使用多个拦截器：
你可以定义多个拦截器，每个拦截器负责处理不同的路径模式。这样，你就不需要在单个拦截器中排除某些路径，而是让不同的拦截器处理不同的路径集。

使用注解：
如果你的控制器方法使用了Spring MVC的注解（如@RequestMapping、@GetMapping等），你可以在这些注解中直接指定路径。然后，在你的拦截器中，你可以检查处理器（handler）的类型，并基于这些信息决定是否拦截。

URL模式匹配库：
使用像AntPathMatcher这样的库来在拦截器内部执行复杂的URL模式匹配。这给了你更大的灵活性来定义哪些URL应该被拦截。

配置文件或数据库驱动的路径配置：
你可以将路径配置存储在外部配置文件或数据库中，并在拦截器中动态加载这些配置来决定是否拦截特定的请求。这种方法允许你在不修改代码的情况下更改拦截路径。

使用Spring Security的过滤器：
如果你的应用已经集成了Spring Security，并且你正在使用它来管理安全性，那么你可以利用Spring Security的过滤器链来执行类似拦截器的功能。Spring Security允许你基于URL模式来配置安全性约束。

总的来说，虽然addPathPatterns和excludePathPatterns是拦截器配置中最直接和常用的方法，但你可以根据具体需求选择其他更灵活或更动态的方法来指定拦截和排除的路径。

视图

在Spring MVC中，mav.setViewName(“index”); 是设置模型视图名称的一种方式，通常用于指示返回的视图页面的名称。例如，如果控制器方法返回一个ModelAndView对象，并设置了视图名称为"index"，那么通常意味着将会渲染名为index的视图（例如一个JSP页面）。

如果你的请求被拦截器拦截，即使你已经设置了视图名称，这通常意味着拦截器的配置或编写方式导致它会在控制器方法执行之后（也就是在视图渲染之前）仍然起作用。有几种可能的原因：

拦截器配置：在Spring MVC中，你可以通过实现HandlerInterceptor接口或使用@Async注解等方式来定义拦截器。如果你在addInterceptors方法中添加了拦截器，并且没有正确地配置排除路径，那么所有请求（包括那些意图返回视图的请求）都会被这个拦截器处理。

拦截器执行顺序：在Spring MVC中，拦截器的执行顺序是按照它们被注册到InterceptorRegistry的顺序来确定的。如果你的拦截器是在其他可能改变请求处理流程的拦截器之前执行的，那么它可能会影响到后续的处理，包括视图的渲染。

拦截器逻辑：拦截器中的逻辑可能决定了是否继续执行后续的请求处理流程。例如，在preHandle方法中，如果你返回false，则请求处理会在此停止，后续的控制器方法和视图渲染都不会执行。

视图解析：即使控制器方法已经执行并设置了视图名称，视图的解析和渲染也是在拦截器的postHandle和afterCompletion方法之后进行的。如果拦截器在这些方法中改变了模型数据或响应对象，它可能会影响最终渲染的视图。

如果你的mav.setViewName(“index”);被拦截器拦截，并且这不是你期望的行为，你需要检查以下几个方面：

确保拦截器的excludePathPatterns正确配置了不应该被拦截的路径。
检查拦截器的preHandle、postHandle和afterCompletion方法中的逻辑，确保它们不会阻止视图的正常渲染。
如果使用了多个拦截器，请检查它们的注册顺序和执行逻辑，以确保它们不会相互干扰。
总之，如果你的拦截器配置正确且逻辑没有问题，那么mav.setViewName(“index”);设置的视图应该会在拦截器处理完成后正常渲染。如果出现问题，通常是由于拦截器的配置或实现不当导致的。