最稳妥方式是用postman.getResponseCookie("sessionId").value直接提取指定Cookie值，它自动解析Set-Cookie、忽略属性干扰、不区分大小写匹配，且返回null时可判空防错；手动解析易因分号、多Cookie、URL编码等出错。
Postman里用 postman.getResponseCookie() 提取指定 Cookie 值
直接调用 postman.getResponseCookie("sessionId") 是最稳妥的方式，它专为读取响应中 Set-Cookie 头部的某个 Cookie 设计，自动解析并返回对象，.value 就是你要的会话参数值。
常见错误是误用 pm.getResponseCookie()（旧版写法已弃用）或试图手动解析整个 Set-Cookie 字符串——这容易因分号、空格、Path=Expires= 等字段干扰而截错。
-
postman.getResponseCookie("JSESSIONID")返回{key: "JSESSIONID", value: "ABC123...", domain: "...", path: "/", httpOnly: true, secure: false} - 只取值：
postman.getResponseCookie("JSESSIONID").value - 若 Cookie 不存在，该方法返回
null，需加判空，否则脚本报Cannot read property 'value' of null - 不区分大小写匹配 key，但建议按服务端实际返回的原始大小写书写，避免歧义
从 Set-Cookie 响应头手动提取时怎么避免截断错误
当 postman.getResponseCookie() 不可用（比如某些老版本 Postman 或特殊部署环境），退而求其次用 postman.getResponseHeader("Set-Cookie")，但必须小心处理格式。
Set-Cookie 是一个可能含多个值的头部（如重定向后设多个 Cookie），且每个值内部用分号分隔属性。直接 .split(";")[0] 只能取第一个 Cookie 的第一段，极易出错。
- 先用
postman.getResponseHeader("Set-Cookie")获取完整字符串，例如："sessionId=abc123; Path=/; HttpOnly; Secure" - 用正则更可靠：
const match = cookieHeader.match(/sessionId=([^;]+)/i); const sessionId = match && match[1]; - 如果服务端返回多个
Set-Cookie行（HTTP/1.1 允许），Postman 会把它们合并成一个字符串，用逗号分隔——此时需先.split(",")再逐个匹配 - 注意 URL 编码：有些 Cookie 值含特殊字符（如
+、%），需用decodeURIComponent()解码后再使用
提取后存到环境变量还是全局变量，有什么实际影响
存到 pm.environment.set("session_id", value) 更安全，除非你明确需要跨环境共享（比如多套测试环境共用同一登录态）。
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
环境变量有作用域隔离，不会被其他环境意外覆盖；而全局变量一旦被某个请求改写，所有后续请求都会继承这个值，容易在并行测试或切换环境时引发状态污染。
- 登录接口 Tests 中写：
pm.environment.set("session_id", postman.getResponseCookie("sessionId").value); - 后续请求 Header 中填：
Cookie: sessionId={{session_id}}，或直接开启 “Automatically persist cookies” 后无需手动传 - 如果服务端要求 Cookie 以
Cookie: JSESSIONID=xxx; XSRF-TOKEN=yyy形式拼接，不要只存一个值，而是用pm.environment.set("full_cookie", `JSESSIONID=${val1}; XSRF-TOKEN=${val2}`) - 别在 Pre-request Script 里重复读取和设置——Tests 是响应后执行，Pre-request 是请求前执行，顺序错了就拿不到最新值
为什么开了 “Automatically persist cookies” 还是没带 Cookie
Postman 的自动 Cookie 持久化只对同域名、同协议、路径匹配的请求生效，且前提是响应中确实返回了有效的 Set-Cookie，并且没有被拦截或拒绝。
典型失效场景不是脚本问题，而是配置或网络层面被忽略：
- 检查当前请求的 URL 协议是否一致（
http://和https://视为不同域） - 确认服务器返回的
Set-Cookie中Domain属性是否与当前请求 Host 匹配（如返回Domain=api.example.com，但你请求的是localhost:8000，就不会保存） - Postman 设置里关闭了 “Enable Cookie Jar”（Settings → General → Enable Cookie Jar），这个开关必须打开
- 某些后端框架（如 Spring Security）默认设
SameSite=Lax或Secure，本地调试时若未走 HTTPS，浏览器或 Postman 可能拒绝存储
真正麻烦的点往往不在代码怎么写，而在 Cookie 的 Domain、Path、Secure 这三个属性是否与你的请求上下文对得上——它们决定了这个 Cookie 到底“算不算属于这次请求”。
