在开发基于 Spring Boot 的 Web 应用时，使用 Session 存储验证码等敏感信息是常见的做法。然而，在调试接口时，你可能会遇到这样一个问题：第一次请求接口时存入的验证码在第二次请求时无法获取，原因往往是两个请求所使用的 Session ID 不一致。本文将详细介绍如何在 Postman 中捕获和传递 Cookie，并一步步排查 Session 不一致的问题。
一、问题背景
假设你有两个接口：
/email接口：用于发送邮件，同时在服务器端的 Session 中保存验证码和邮箱信息。/verifyCode接口：用于验证用户输入的验证码。
在实际调试过程中，如果你发现第二个接口中读取到的 Session 中验证码为 null，而且日志显示两个请求使用了不同的 Session ID，这就意味着浏览器或工具没有正确传递第一次请求返回的 Session Cookie（例如 JSESSIONID）。
在我们的日志中看到类似如下信息：
两个Session ID: B49AA3BA16FBDDE5DF31D85774CC7FEF
发送邮件成功xxx@qq.com-->yyy@qq.com
null
2[Ljavax.servlet.http.Cookie;@369be3e0
Session ID: 359048A6FEA0550838680EAD6D12536B
由此可见，第一次请求返回的 Session ID 为 B49AA3BA16FBDDE5DF31D85774CC7FEF，而第二次请求使用的 Session ID 为 359048A6FEA0550838680EAD6D12536B，这直接导致 Session 中的信息丢失。
二、问题成因与排查步骤
1. Cookie 未正确传递
原因：
Session 信息是依赖于 Cookie（如 JSESSIONID）来关联的。如果 Postman 在发送第二个请求时没有携带第一次请求返回的 Cookie，那么服务器就会认为它们是来自不同客户端，进而创建新的 Session。
排查方法：
检查 Postman 的 Cookie 管理器：
Postman 内置 Cookie 管理器会自动捕获服务器返回的 Cookie。点击 Postman 界面右上角的 “Cookies” 按钮，查看对应域名下是否有 JSESSIONID 存在。打印调试信息：
在两个接口中分别打印request.getSession().getId()，确保两个请求使用的 Session 是一致的。
2. 跨域与 CORS 配置
原因：
当前后端不在同一个域或端口下时，跨域请求默认情况下不发送 Cookie，需要额外设置 withCredentials 和正确的 CORS 配置。
排查方法：
后端 CORS 配置：
在 Spring Boot 中添加全局 CORS 配置，允许跨域并启用凭证支持。示例如下：@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOrigins("http://你的前端域名或IP:端口") .allowCredentials(true) .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS"); } }客户端设置：
如果使用浏览器，确保在请求中设置withCredentials: true。在 Postman 中，开启 Cookie 管理，或者手动指定 Cookie。
3. 服务端 Session 管理策略
原因：
有时候，后端代码中存在逻辑会提前清除 Session 或在特殊请求中总是新建 Session。
排查方法：
检查代码逻辑：
确保没有多余的调用session.invalidate()或对 Session 作不必要的操作。分布式环境：
在集群环境下使用 Session 共享（如 Redis），避免不同服务器间的数据不一致。
三、如何在 Postman 中管理 Cookie
1. 自动捕获和传递 Cookie
Postman 默认开启了自动管理 Cookie 的功能，当你发送 /email 请求时，服务器返回的 Set-Cookie（包含 JSESSIONID）会自动被保存在 Postman 中。你可以点击右上角的 “Cookies” 按钮检查是否已经获取了 JSESSIONID。
2. 手动传递 Cookie
如果自动传递存在问题，可以手动捕获 Cookie 值，然后在第二个接口请求中加入该 Cookie。
步骤如下：
捕获 Cookie 值：
在/email请求的响应头中，查找Set-Cookie字段，如：Set-Cookie: JSESSIONID=B49AA3BA16FBDDE5DF31D85774CC7FEF; Path=/; HttpOnly将
JSESSIONID的值复制下来。在第二个请求中设置 Cookie：
在/verifyCode请求的 Headers 部分添加：Key: Cookie
Value:
JSESSIONID=B49AA3BA16FBDDE5DF31D85774CC7FEF
3. 使用环境变量自动传递 Cookie
为了提高自动化程度，建议在 Postman 中使用 Tests 脚本自动提取并设置 Cookie，避免手动复制。示例代码如下：
在 /email 请求的 Tests 脚本中添加：
// 获取响应头中的 Set-Cookie 值
var cookieHeader = pm.response.headers.get("Set-Cookie");
if (cookieHeader) {
// 使用正则表达式提取 JSESSIONID
var match = cookieHeader.match(/JSESSIONID=([^;]+);/);
if (match) {
var sessionId = match[1];
// 将 sessionId 存入环境变量
pm.environment.set("JSESSIONID", sessionId);
console.log("Captured JSESSIONID: " + sessionId);
}
}
在 /verifyCode 请求中设置动态 Cookie：
在 Headers 中添加如下条目：
Key: Cookie
Value:
JSESSIONID={{JSESSIONID}}
Postman 将自动替换 {{JSESSIONID}} 为环境变量中存储的值，从而确保两个请求之间使用相同的 Session。
四、总结
遇到 Session 信息丢失问题时，首先需要确认客户端请求是否正确传递了服务器返回的 Cookie。常见问题包括：
Cookie 未自动传递或配置错误：检查 Postman 中的自动 Cookie 管理，或者手动设置 Cookie 传递。
跨域请求配置：在跨域场景下，确保后端允许凭证传输，并在客户端启用
withCredentials。服务端逻辑问题：确认后端代码中没有无意间清除或重置 Session。
通过这些详细的步骤及示例代码，你可以快速定位并解决 Session ID 不一致的问题，从而保证验证码等重要数据在后续请求中能被正确读取。希望本篇文章能够帮助你解决实际开发中遇到的难题，并提高你的接口调试效率！
读者是否在实践中也遇到类似的问题？欢迎在评论区分享你的经验或疑惑，让我们一起交流进步。