如何追踪SpringBoot系统会话过期及浏览器标识响应存储与携带？

今天我们分享一个项目开发中的出现操作某个业务时候，出现闪退的经典问题，针对老旧的Spring MVC系统，要系统性地跟踪会话（Session）生命周期和Cookie的携带情况，我们需要一套清晰的、从浏览器到服务器的排查方案。以下是详细的跟踪步骤和方法。 当然这个排查步骤和方法，也适合基本SpringBoot开发的系统，但是服务端的排查需要大家根据实际情况修改后端排查日志、拦截器等方法 整体排查思路 我们的目标是验证以下三个环节是否正常： 登录成功时：服务器是否正确生成了Session并返回了包含正确 JSESSIONID的Cookie给浏览器。 浏览器端：浏览器是否成功接收并存储了该Cookie。 后续请求：浏览器在执行查询等操作时，是否始终在请求头中携带了这个Cookie。 第一步：浏览器端跟踪（客户端验证） 这是最直接、最容易操作的第一步，可以由开发或运维人员在问题电脑上进行。 一、跟踪会话标识（Cookie）的接收与存储 开启浏览器开发者工具：使用出现问题的浏览器（如奇安信、Chrome），按 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头，内容类似于 JSESSIONID=ABCD1234...; Path=/; HttpOnly。 记录下这个 JSESSIONID的值。 验证Cookie存储： 切换到 Application/应用标签页。 在左侧找到 Cookies-> http://10.15.9.106。 检查是否存在一个名为 JSESSIONID的Cookie，其值是否与刚才在响应头中看到的一致。 至此，我们验证了环节1和2。如果这里就出问题，那么根源在服务器响应或浏览器安全策略上。 二、跟踪后续请求的Cookie携带情况 进行正常操作：登录成功后，在系统内进行一些不会触发闪退的简单操作，比如点击菜单。 观察请求：在Network面板中，观察这些操作触发的Ajax或页面请求。 检查请求头：随机点击几个后续请求，查看它们的 Request Headers（请求头）。 必须找到一个 Cookie:头，其内容应包含 JSESSIONID=ABCD1234...（即登录时设置的那个值）。 确保每个请求都携带了这个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的创建、销毁和属性变化。