Postman 中 Cookie 的 Path 字段必须严格匹配服务端 Set-Cookie 响应中的 Path 值（如 /api/v2），否则 Cookie 不会被携带，导致 401 或会话丢失；留空、大小写错误、斜杠不一致均会失效。
Postman 里设置 Cookie 的 Path，不是可选项，而是必须匹配服务端要求才能生效的关键字段；填错或留空常导致 Cookie 不被携带、接口返回 401 或会话丢失。
Cookie Path 必须和后端 Set-Cookie 中的 Path 一致
服务端在响应头中下发 Set-Cookie 时，如果指定了 Path=/api/v2，那 Postman 手动添加的 Cookie 就不能只填 Path=/ 或留空——它只会被发往 /api/v2 及其子路径下的请求（比如 /api/v2/user），而不会出现在 /api/v1/login 这类请求头中。
常见错误现象：
- 手动添加 Cookie 后，后续请求 Header 里完全没出现
Cookie字段 - 登录成功了，但调用 /user/info 接口时提示未登录（实际是 Cookie 没发过去）
- Postman Cookies 面板显示该 Cookie 已存在，但点击「Cookies」标签页却看不到它被用于当前请求
解决方法：
- 先发一次登录请求，点开响应右上角的
Cookies标签页，记下服务端返回的Path值（例如/api） - 在 Cookie 管理器里添加新 Cookie 时，
Path字段必须严格填写成相同值，不能省略、不能补斜杠、不能大小写混用 - 若服务端返回多个
Set-Cookie，且 Path 不同，需分别添加对应条目，不能合并
手动添加 Cookie 时 Path 的填写规范
Postman Cookie 管理器里的 Path 是纯字符串字段，不支持通配符或正则；它只做前缀匹配，且区分大小写。
正确示例：
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
- 服务端返回
Set-Cookie: JSESSIONID=abc123; Path=/admin→ Postman 中填/admin - 服务端返回
Path=/→ Postman 中填/（不能留空，也不能填""或"root"） - 服务端返回
Path=/v3/→ Postman 中填/v3/（末尾斜杠必须保留）
错误示例：
- 填
admin（缺开头斜杠）→ 不匹配，不发送 - 填
/ADMIN（大小写错误）→ 不匹配，尤其在 Nginx 或某些 Java 容器中会被拒绝 - 填
/admin/（多加斜杠）→ 若服务端发的是/admin，则不匹配
用 Pre-request Script 动态设置 Cookie 时 Path 怎么处理
脚本方式无法直接控制 Cookie 的 Path 或 Domain 属性——pm.request.headers.add({ key: 'Cookie', value: 'xxx=yyy' }) 只是硬塞一个请求头，绕过了 Postman 的 Cookie 管理逻辑，也就失去了 Path 路径约束能力。
这意味着：
- 这种方式发出去的 Cookie 会被无条件带上所有同域请求，不管 Path 是否匹配
- 它可能干扰真实会话（比如把后台管理 Cookie 错带到前台接口）
- 无法模拟生产环境真实的 Cookie 作用域行为，测试结果不可靠
所以，除非你明确知道服务端不要求 Path 校验（比如本地开发环境），否则别用脚本伪造 Cookie 头。真要动态设置，优先用：
- 在登录请求的 Tests 脚本中用
pm.cookies.get("JSESSIONID")提取值 - 再用
pm.environment.set("cookie_value", ...)存为变量 - 回到 Cookie 管理器，手动添加一条带正确
Path和Domain的 Cookie，值设为{{cookie_value}}
Path 看似只是个字符串字段，但它背后绑定的是浏览器（及 Postman）的 Cookie 作用域模型；漏掉它、写错它、或试图绕过它，都会让会话管理失效——而这种问题往往不报错，只静默丢 Cookie。
