企业官网建设流程全解析

php做网站的公司有哪些,国内永久免费crm系统破解版,网络营销方案3000字,开源企业网站建设系统今天我们分享一个项目开发中的出现操作某个业务时候#xff0c;出现闪退的经典问题#xff0c;针对老旧的Spring MVC系统#xff0c;要系统性地跟踪会话#xff08;Session#xff09;生命周期和Cookie的携带情况#xff0c;我们需要一套清晰的、从浏览器到服务器的排查方…今天我们分享一个项目开发中的出现操作某个业务时候出现闪退的经典问题针对老旧的Spring MVC系统要系统性地跟踪会话Session生命周期和Cookie的携带情况我们需要一套清晰的、从浏览器到服务器的排查方案。以下是详细的跟踪步骤和方法。当然这个排查步骤和方法也适合基本SpringBoot开发的系统但是服务端的排查需要大家根据实际情况修改后端排查日志、拦截器等方法整体排查思路我们的目标是验证以下三个环节是否正常登录成功时服务器是否正确生成了Session并返回了包含正确/* by 01130.hk - online tools website : 01130.hk/zh/htaccess2nginx.html */ JSESSIONID的Cookie给浏览器。浏览器端浏览器是否成功接收并存储了该Cookie。后续请求浏览器在执行查询等操作时是否始终在请求头中携带了这个Cookie。第一步浏览器端跟踪客户端验证这是最直接、最容易操作的第一步可以由开发或运维人员在问题电脑上进行。一、跟踪会话标识Cookie的接收与存储开启浏览器开发者工具使用出现问题的浏览器如奇安信、Chrome按/* by 01130.hk - online tools website : 01130.hk/zh/htaccess2nginx.html */ F12打开开发者工具。切换到Network/网络面板勾选Preserve log(保留日志)​ 复选框防止页面跳转时日志被清空。清空Cookie可选为了纯净的测试在开发者工具的Application应用或Storage存储标签页下找到Cookies选中当前系统地址的Cookie将其删除。这可以模拟一次全新的登录。执行登录在地址栏输入系统单节点地址如http://10.15.9.106/...进行登录。在Network面板中找到登录请求通常是login或j_spring_security_check之类的POST请求。重点查看登录请求的响应点击这个登录请求查看Response Headers响应头。你应该能看到一个Set-Cookie头内容类似于JSESSIONIDABCD1234...; Path/; HttpOnly。记录下这个JSESSIONID的值。验证Cookie存储切换到Application/应用标签页。在左侧找到Cookies-http://10.15.9.106。检查是否存在一个名为JSESSIONID的Cookie其值是否与刚才在响应头中看到的一致。至此我们验证了环节1和2。如果这里就出问题那么根源在服务器响应或浏览器安全策略上。二、跟踪后续请求的Cookie携带情况进行正常操作登录成功后在系统内进行一些不会触发闪退的简单操作比如点击菜单。观察请求在Network面板中观察这些操作触发的Ajax或页面请求。检查请求头随机点击几个后续请求查看它们的Request Headers请求头。必须找到一个Cookie:头其内容应包含JSESSIONIDABCD1234...即登录时设置的那个值。确保每个请求都携带了这个Cookie。触发闪退关键步骤进行那个已知会引发闪退的查询操作。密切观察Network面板在点击“查询”按钮后瞬间发出的请求。重点检查触发闪退的那个特定查询请求情况A正常该请求的Request Headers里正常携带了JSESSIONID但服务器返回了一个302 Found状态码Location指向登录页或者直接返回了登录页的HTML状态码200。这说明问题出在服务器端服务器主动废弃了会话。情况B异常该请求的Request Headers里没有​Cookie头或者JSESSIONID的值变成了空、错误或一个新的值。这说明问题出在浏览器端Cookie在发送前丢失了。第二步服务器端跟踪代码与日志层面如果浏览器端跟踪指向了“情况A”Cookie携带正常但服务器返回登录页那么问题根因在服务器内部。一、启用详细日志记录最有效的方法如果这个老系统可能日志不全我们需要临时增加会话跟踪日志。1.在web.xml中配置Session监听器创建一个类实现HttpSessionListener和HttpSessionAttributeListener接口并部署到生产环境。这个类可以记录Session的创建、销毁和属性变化。import javax.servlet.http.HttpSessionEvent; import javax.servlet.http.HttpSessionAttributeListener; import javax.servlet.http.HttpSessionBindingEvent; import java.util.logging.Logger; // 或使用Log4j、Slf4j public class SessionDebugListener implements HttpSessionListener, HttpSessionAttributeListener { private static final Logger logger Logger.getLogger(SessionDebugListener.class.getName()); Override public void sessionCreated(HttpSessionEvent se) { logger.info( Session被创建: ID se.getSession().getId() 时间 new java.util.Date()); } Override public void sessionDestroyed(HttpSessionEvent se) { // 这是最关键的信息会话何时、为何被销毁 logger.info( Session被销毁: ID se.getSession().getId() 时间 new java.util.Date() 。 最后访问时间: new java.util.Date(se.getSession().getLastAccessedTime())); // 可以在这里打印堆栈信息看是哪个线程触发了销毁 Thread.dumpStack(); } Override public void attributeAdded(HttpSessionBindingEvent event) { if (user.equals(event.getName())) { // 监听用户登录属性 logger.info( 用户登录成功User对象被存入Session。 SessionID event.getSession().getId() , User event.getValue()); } } Override public void attributeRemoved(HttpSessionBindingEvent event) { if (user.equals(event.getName())) { // 监听用户登出属性 logger.info( 用户登出User对象从Session移除。 SessionID event.getSession().getId()); } } }在web.xml中注册listener listener-classcom.yourcompany.SessionDebugListener/listener-class /listener2.在过滤器中记录请求在一个全局的Filter中如果已有则修改它记录每个请求的Session状态。public class SessionTrackingFilter implements Filter { Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { HttpServletRequest req (HttpServletRequest) request; HttpServletResponse res (HttpServletResponse) response; String sessionId req.getRequestedSessionId(); boolean sessionValid req.isRequestedSessionIdValid(); logger.info(请求进入: URI req.getRequestURI() , SessionID sessionId , Session是否有效 sessionValid); chain.doFilter(request, response); // 请求处理后再次检查Session状态 sessionValid req.isRequestedSessionIdValid(); logger.info(请求离开: URI req.getRequestURI() , Session是否有效 sessionValid); } }部署这些监听器和过滤器后重现闪退问题。然后立即查看服务器日志寻找 Session被销毁这条关键日志。它会告诉你Session被销毁的精确时间结合堆栈信息就能定位到是哪个代码路径或配置触发了销毁。二、分析服务器线程栈如果怀疑是会话锁超时需要在闪退发生时立刻获取服务器的线程堆栈快照jstack pid。分析快照看是否有线程长时间持有Session锁状态为RUNNABLE且正在执行查询SQL而其他线程在等待这个锁状态为BLOCKED。总结跟踪流程一览表步骤跟踪点方法期望结果异常结果与含义1​浏览器接收Cookie​F12 - Network - 查看登录请求的Set-Cookie响应头收到正确的JSESSIONID未收到服务器响应问题2​浏览器存储Cookie​F12 - Application - Cookies存储了正确的JSESSIONID未存储浏览器安全策略阻止3​后续请求携带Cookie​F12 - Network - 查看查询请求的Cookie请求头携带了登录时的JSESSIONID未携带/值错误浏览器端Cookie丢失4​服务器处理请求​查看服务器日志/监听器日志Session有效请求正常处理日志显示Session被销毁服务器端主动废弃会话5​服务器并发情况​分析线程堆栈快照 (jstack)无长时间锁等待有线程因等待Session锁而阻塞会话锁超时问题请按照这个流程进行操作很大概率能直接定位到问题发生的具体环节。先从浏览器端跟踪开始这通常能给出最直接的线索。