在项目中使用satoken报错：cn.dev33.satoken.exception.NotLoginException: 未能读取到有效Token

当时碰巧发现在satoken注册拦截器中将接口的请求路径放入excludePathPatterns()方法中就不会再报这个错误了

也属于瞎猫碰见死耗子，请求多了之后就加了很多，有种投机取巧的感觉，也是纠结了好长时间，之前在浏览器控制台查看发送的请求发现

token也已经放到了header中，但是后端就是会报未能获取有效token的问题，今天又尝试其他方法，发现浏览器对getUserInfo()发送了两次请求，其中有一个是 请求方法: OPTIONS，对应下图

这个请求中请求头中没有token信息，会不会是这里的问题呢，然后就对OPTIONS请求一通百度，查询到有放行OPTIONS的方法，由于之前跨域实现的WebMvcConfigurer接口，网上的例子是HandlerInterceptor接口，照着改，具体代码如下

@Configuration
public class CorsInterceptor implements HandlerInterceptor {
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) {
        response.setHeader("Access-Control-Allow-Origin", "*");
        response.setHeader("Access-Control-Allow-Credentials", "true");
        response.setHeader("Access-Control-Allow-Methods", "GET, HEAD, POST, PUT, PATCH, DELETE, OPTIONS");
        response.setHeader("Access-Control-Max-Age", "3600L");
        response.setHeader("Access-Control-Allow-Headers", "*");

        // 如果是OPTIONS则结束请求
        if (HttpMethod.OPTIONS.toString().equals(request.getMethod())) {
            response.setStatus(HttpStatus.NO_CONTENT.value());
            return false;
        }

        return true;
    }
}

然后在satoken注册拦截器中添加如下代码，将跨域拦截器放在校验拦截器之上

registry.addInterceptor(corsInterceptor).addPathPatterns("/**");

就好了，还就是瞎猫碰见死耗子，就是碰巧，或不合乎逻辑，很久之前碰到的问题，今天终于解决了