Postman中Cookie的Expires必须为RFC 7231规定的GMT格式（如“Tue, 01 Jan 2025 00:00:00 GMT”），否则会静默丢弃；推荐用new Date().toUTCString()生成或优先使用Max-Age字段。
Postman 里手动添加的 Cookie 显示“已过期”或根本没生效，大概率是 Expires 时间格式写错了，而不是你复制漏了值。
Postman 的 Expires 必须是 GMT 格式，不是本地时间也不是 ISO 8601
Postman 解析 Expires 字段时只认 RFC 7231 定义的固定格式：Tue, 01 Jan 2025 00:00:00 GMT。它不接受以下任何写法：
-
"2025-01-01T00:00:00Z"（ISO 8601，Postman 直接忽略该字段） -
"Wed, 01 Jan 2025 00:00:00 CST"（非 GMT 时区，会被当作无效值） -
"2025-01-01 00:00:00"（无星期、无时区，解析失败） - 时间早于当前系统时间（哪怕只早 1 秒），Postman 就不会存入 Cookie 管理器
验证方式：在 Postman 的 Cookie 管理器里添加一条带 Expires 的 Cookie 后，点 Save，再立刻刷新列表 —— 如果那条 Cookie 消失了，基本就是 Expires 格式或时间非法。
用 new Date().toUTCString() 生成安全的 Expires 值
前端 JS 生成 GMT 字符串最稳的方式是调用原生方法，别手写。比如要设 24 小时后过期：
const expires = new Date(Date.now() + 24 * 60 * 60 * 1000).toUTCString(); console.log(expires); // "Wed, 05 Nov 2026 21:27:00 GMT"
注意：toUTCString() 输出固定含星期、空格分隔、末尾是 GMT，Postman 能正确识别。别用 toISOString() 或 toLocaleString() 替代。
优先用 Max-Age，绕过时间格式和时区陷阱
如果你控制得了服务端响应头，或者在 Postman 的 Tests 脚本里动态设置 Cookie，直接用 Max-Age 更可靠：
-
Max-Age=86400表示 24 小时后过期，浏览器按秒数计算，不依赖客户端时间精度 - Postman Cookie 管理器支持
Max-Age字段，填数字即可（不用加引号） - 当同时存在
Expires和Max-Age时，现代浏览器以Max-Age为准 - 对跨国用户或系统时间不准的设备，
Max-Age是更鲁棒的选择
Postman 界面里填 Max-Age 时，只要输入纯数字（如 300），不要写 Max-Age=300 —— 它是独立字段，不是键值对的一部分。
真正容易被忽略的是：Postman 的 Cookie 管理器不会报错提示“Expires 格式错误”，它只会静默丢弃整条记录。你得靠“保存后是否还在列表里”来反推问题，而不是等请求发出去才发现没带上。
