Postman中Cookie过期时间必须为GMT格式（如Wed, 01 Jan 2025 00:00:00 GMT），否则不生效；Domain和Path不匹配将导致Cookie不被发送，即使Expires正确；过期Cookie仍保留在面板但不再自动携带。
Postman 里设置 Cookie 过期时间，本质是控制它是否会在后续请求中自动携带——过期时间一到，Postman 就会直接忽略该 Cookie，不再发出去。
Postman 的 Expires 字段必须是 GMT 格式的时间字符串
Postman 不接受本地时间、相对时间（如 “+1h”）、Unix 时间戳或任意格式的日期。它只认严格符合 Expires 响应头规范的 GMT 时间字符串，例如：Wed, 01 Jan 2025 00:00:00 GMT。
常见错误现象：
- 填了
2025-01-01 00:00:00或1735689600→ Cookie 看似保存成功，但后续请求头里不出现 - 填了未来时间但时区不对（比如用了 CST 或 UTC+8）→ Postman 按 GMT 解析后实际已过期
实操建议：
- 用浏览器开发者工具里 Network 面板复制服务端返回的
Set-Cookie头中的Expires值，最保险 - 手动生成时，推荐用在线工具（如 “convert date to GMT cookie format”）转成标准格式，别手动拼
- 如果只是临时测试，可留空
Expires字段：Postman 会将其视为会话 Cookie，在当前 Postman 实例关闭前一直有效
Cookie 过期后不会自动删除，但也不会再发送
Postman 不像浏览器那样在过期时刻主动清理 Cookie 存储。它只是在每次发起请求前检查每个 Cookie 的 Expires 时间，仅对未过期的才写入请求头的 Cookie 字段。
这意味着：
- 过期的 Cookie 仍会显示在
Cookies面板里，名称、值、域名都可见，但状态灰显或标为 “Expired” - 你手动点击
Save不会刷新过期时间，必须重新编辑并填入新的Expires - 如果想彻底清掉，得点对应 Cookie 行末的
X手动删除，或点域名旁的垃圾桶图标批量清除
Domain 和 Path 设置错误会导致 Expires 完全失效
即使 Expires 填对了，如果 Domain 或 Path 与请求 URL 不匹配，Postman 根本不会把该 Cookie 加进请求头——它连“要不要检查过期”的机会都没有。
典型不匹配场景：
- 请求 URL 是
https://api.example.com/v1/users，但 Cookie 的Domain填了example.com（少了个api.）→ 不匹配 - Cookie 的
Path是/auth，但请求路径是/api/users→ 不匹配 - 填了
Domain但没填Path，Postman 默认用/；反之亦然，两者必须协同生效
验证方式：发一次请求后，点响应左上角的 Cookies 标签页，看「Sent Cookies」列表里有没有你设的那个 —— 没出现，大概率是作用域配错了。
Pre-request Script 里动态设置 Cookie 无法指定 Expires
如果你用脚本在请求前注入 Cookie（比如通过 pm.cookies.set()），这个方法只支持 key 和 value，不接受 expires、domain、path 等参数：
pm.cookies.set("JSESSIONID", "abc123"); // ✅ 可行<br>pm.cookies.set("JSESSIONID", "abc123", { expires: new Date(Date.now() + 3600000) }); // ❌ 报错，不支持对象参数
所以需要精确控制过期时间的场景，必须走 UI 的 Cookies 面板手动配置，或让服务端通过 Set-Cookie 响应头下发（Postman 会自动解析并存储所有属性）。
真正容易被忽略的是：Postman 的 Cookie 管理是“域名 + 路径 + 过期时间”三重绑定，改其中任何一个，都相当于新增一条独立 Cookie —— 旧的不会覆盖，也不会失效，除非你主动删掉。测试多账号切换或环境迁移时，这点尤其关键。
