最初，没有人在意这个bug，这不过是一次登陆失败，一个刷新，直到，这个bug和整个系统息息相关，差点上不了线。。。
故事最开始出现在三月份，一个厂区上线后，偶尔发现登录后提示“获取菜单失败”，然后点击刷新界面，会发现实际上登陆没成功，会跳回到登录界面，但是在登陆一次，就好了。
只是一个小问题，而且是偶发的，频率不高，也就没当回事。
但是十一月份，给另外一个厂区做系统优化，发布到测试环境后问题出现了，就像一场洪水，席卷了哪个厂区所有的电脑一样，他们登录后都发现获取菜单列表失败，而且刷新后登陆仍然无效。
命运开了个玩笑，不管你死活。
一开始考虑到可能是数据库迁移的问题，之前是oracle数据库，现在全部迁移到了Postgresql数据库上面，但是查了查权限表和菜单列表配置都没问题，不会出现配对失败的问题。
于是查了代码，发现在查询菜单列表时，传过来的用户id是空的，再往上层找，发现页面一开始会通过SecurityUserHolder.getCurrentUser()来取用户id，但是取出的这个值是空值。
问题找到了，这时候判断可能是登陆失败。于是去查登录接口，发现登录正常，登陆完后再去获取SecurityUserHolder.getCurrentUser()也能获取到，方向不对！
如果登陆成功后能获取到用户信息，但是跳转后获取不到用户信息，那么很显然，在页面跳转时值丢掉了，怎么丢掉的？
我查了一下SecurityUserHolder这个类，找到了 找不到用户信息的原因 这样的搜索，貌似能解决我的问题。
查看了一下，明白了Springmvc框架在处理用户信息时的逻辑，用户登录信息本质上还是保存在HttpSession中，但是为了方便使用，SpringSecurity对HttpSession中的用户信息进行了封装，同时，我们得明白 Spring Security 中的用户信息到底是在哪里存的？SecurityContextHolder 中的数据，本质上是保存在 ThreadLocal 中，ThreadLocal 的特点是存在它里边的数据，哪个线程存的，哪个线程才能访问到。这样就带来一个问题，当不同的请求进入到服务端之后，由不同的 thread 去处理，按理说后面的请求就可能无法获取到登录请求的线程存入的数据，例如登录请求在线程 A 中将登录用户信息存入 ThreadLocal，后面的请求来了，在线程 B 中处理，那此时就无法获取到用户的登录信息。但实际上，正常情况下，我们每次都能够获取到登录用户信息，这又是怎么回事呢？
简单来说，每一个请求到达服务端的时候，首先从 session 中找出来 SecurityContext ，然后设置到 SecurityContextHolder 中去，方便后续使用，当这个请求离开的时候，SecurityContextHolder 会被清空，SecurityContext 会被放回 session 中，方便下一个请求来的时候获取。
在此感谢博主 _江南一点雨 的文章
https://blog.csdn.net/u012702547/article/details/105237938
我想，可能是页面跳转之间session丢失了，于是我在两个页面分别查询了session值，果然发现两个页面的sessionid是不一样的，后来又查到springmvc跳到下個action后session改变，上面说了是springboo下ajax的post请求的跨域问题，虽然跨域问题和我的不大，但是仍然是一片好文章，可以读一下防微杜渐
https://blog.csdn.net/shj_php/article/details/130130715
这时候其实已经陷入死路了，我大概知道是因为页面跳转session丢失造成的SecurityUserHolder丢失，但是为什么session会丢失找不到原因。这时候突然想到，在上线的时候，加强了资安扫描，为了处理一些漏洞加强了访问配置，有可能在修改策略的时候无意中改动造成的问题。
于是我查了项目里的请求头过滤，果然发现以下代码：
Cookie[] cookies = request.getCookies();
if(cookies!=null){
for(Cookie cookie : cookies){
String value = cookie.getValue();
StringBuilder builder = new StringBuilder();
builder.append("JSESSIONID=" + value + "; ");
builder.append("Secure; ");
builder.append("HttpOnly; ");
builder.append("SameSite=Strict;");
Calendar cal = Calendar.getInstance();
cal.add(Calendar.HOUR, 1);
Date date = cal.getTime();
Locale locale = Locale.CHINA;
SimpleDateFormat sdf = new SimpleDateFormat("dd-MM-yyyy HH:mm:ss",locale);
builder.append("Expires=" + sdf.format(date));
response.setHeader("Set-Cookie", builder.toString());
}
}
在传递时会将访问中Cookie取出，然后重新塞值，问题就出在塞值时第一行：
builder.append("JSESSIONID=" + value + "; ");
我查看了一下请求，发现cookies里有两个值，emp_no和JSESSIONID，获取到JSESSIONID是没问题的，关键是获取到了emp_no的值塞到JSESSIONID里，那就出问题了，会造成匹配异常的问题，于是改动了下
builder.append(cookie.getName()+"=" + value + "; ");
这时候再试，果然，cookie一致了，也能正确获取到SecurityUserHolder的值了。
问题解决了，很难说，这个问题说难不难，说简单，也花费了将近半个月时间。没想到是别的同事的好心之举，造成的一系列困扰，总的来说，这个问题的解决，很大程度上提高了系统的稳健性，以及加深了自己对springmvc架构的理解。