Postman中清除指定Cookie需用pm.cookies.set()将其expires设为过去时间并匹配原path/domain，而非unset()或clear()；后者仅影响当前请求上下文或内存副本，无法删除Cookie Jar中持久化条目。
Postman 中如何用 Pre-request Script 清除指定 Cookie
Postman 本身不提供直接删除某个 Cookie 的 API，pm.cookies 对象只支持读取和设置（覆盖），不能调用 delete 或 remove。想“删除”一个 Cookie，本质是把它设为过期（expires 过去的时间）并确保 path 和 domain 匹配原值，否则浏览器或 Postman 内部不会清除它。
常见错误是只调用 pm.cookies.unset("CookieName") —— 这个方法实际只在当前请求上下文中移除内存副本，并不发送清除指令给服务端，下次请求仍可能携带旧 Cookie。
- 必须用
pm.cookies.set()显式覆盖目标 Cookie，expires设为过去时间（如new Date(0)） -
path和domain参数要和原始 Cookie 一致；若不确定，可先用pm.cookies.get("name")查看（但注意：Postman 不返回原始path/domain，只能靠经验或服务端文档推测） - 示例脚本（清除名为
session_id的 Cookie）：pm.cookies.set("session_id", "", { expires: new Date(0), path: "/", domain: "api.example.com" });
为什么 pm.cookies.clear() 不总管用
pm.cookies.clear() 确实会清空当前请求中所有已加载的 Cookie，但它只影响「本次请求发出前」的 Cookie 集合，不修改 Postman 全局 Cookie Jar 中持久化的条目。也就是说，如果你在 Cookie Manager 里手动添加过 auth_token，哪怕运行了 clear()，下一次发请求时它仍会自动注入。
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
- 该方法适用于临时绕过当前请求的 Cookie，比如测试无认证场景
- 但它对 Cookie Jar 中保存的长期 Cookie 无效；真正要清理持久化 Cookie，必须进 Manage Cookies → Delete 手动删，或用 Collection Runner 的 “Clear cookies before run” 选项
- 脚本中调用
pm.cookies.clear()后，再调用pm.cookies.get()可能仍返回值——这是因 Postman 的异步加载机制导致读取的是缓存快照，不是实时状态
Pre-request Script 中安全清理多个 Cookie 的写法
批量清理容易漏掉 path 或 domain 不匹配的问题，尤其当接口部署在子路径（如 /v2/）或泛域名（如 .example.com）时。硬编码路径风险高，建议优先用服务端返回的 Set-Cookie 头反推，或统一约定路径为 /。
- 不要循环调用
unset()，改用多次set()覆盖： ["session_id", "csrf_token", "user_prefs"].forEach(name => { pm.cookies.set(name, "", { expires: new Date(0), path: "/" }); });- 如果 Cookie 带
Secure或HttpOnly标志，脚本无法清除它们——Postman 不允许 JS 操作HttpOnlyCookie，Secure则要求请求必须是 HTTPS，否则设置会被忽略 - 测试时记得关掉 “Automatically persist cookies”（Settings → General），否则每次请求后 Cookie 又被自动存回 Jar
Cookie Jar 持久化数据与脚本的边界在哪
Postman 的 Cookie Jar 是独立于脚本运行环境的存储层。脚本里的 pm.cookies 是一个代理对象，读写操作最终同步到 Jar，但同步有延迟且不可控。这意味着你不能依赖脚本执行完就立刻看到 Jar 里对应 Cookie 消失——它可能还在，直到下一次请求触发刷新。
最稳妥的清理方式永远是组合使用：脚本清除本次请求上下文 + 手动清空 Cookie Jar + 关闭自动持久化。特别是做登录态隔离测试（比如 A 用户登出后立刻切 B 用户），单靠脚本大概率失败。
