昨天遇到了一个大坑，接手一个现有的项目使用的SpringSecurity的，本地跑起来之后postman调接口 token一直认证不了，但是用相同的token在dev服务器端访问确可以通过（本地和dev环境连的同一个redis）。
原因先直接说原因：我postman调用的url不对，这个项目包含十几个微服务，都有context-path的配置，唯独这个服务没有，我postman调用时想当然的给加了context-path，实际上是404。
或许你会问，怎么连404都看不出来，然而是实际上我拿到的响应是这样的：
我可以很确定这个token有用，在dev环境试过了。所以从 SecurityFilterChain找到包含的所有过滤器，挨个进行了debug：
重点关注了ExceptionTranslationFilter、OAuth2AuthenticationProcessingFilter这两个Filter，前者是对SecurityFilterChain中发生异常的全局处理，后者则是认证token的逻辑，然而所有逻辑都正常，没有抛出任何异常。当跳过所有断点后，又来了一遍请求：
什么鬼，怎么又走了一遍/error，由于SpringSecurity默认的登录/登出url是/login和/logout，再加上postman返回的invalid_token信息，我想当然的以为是Security做的逻辑处理，这个/error是由security重定向的。因此我的思路一直在于Security为什么和Security什么时候发生的这次重定向，实在是发现不了问题。
后来我索性从DispatcherServlet开始进行debug，在org.springframework.web.servlet.resource.ResourceHttpRequestHandler#handleRequest方法中发现了问题：
这不就是404嘛。一路从org.springframework.security.web.util.OnCommittedResponseWrapper#sendError(int)debug到javax.servlet.http.HttpServletResponseWrapper#sendError(int) 再debug到org.apache.catalina.connector.ResponseFacade#sendError(int)最后到
org.apache.catalina.connector.Response#sendError(int, java.lang.String)
确实在Response的响应码被写成了404，随后，在ApplicationDispatcher中，我跟踪到了/error的请求：
