Postman中Cookie只发给匹配Domain和Path的URL；Domain须以点开头（如.example.com）才匹配子域名，Path需精确匹配或为父路径，且Cookie按域名字符串硬绑定，不随环境变量自动切换。
Postman里Cookie到底发给哪个URL？看Domain和Path字段
Postman不是“看到请求URL就无脑塞Cookie”，而是严格按RFC 6265规范匹配Domain和Path两个属性。哪怕你只差一个点、多一个斜杠，Cookie就不会被带上。
常见错误现象：你在Cookies管理面板里明明添加了JSESSIONID=abc，但发https://api.example.com/v1/user时抓包发现Header里根本没有Cookie头——大概率是Domain填成了example.com（少了一个点），而实际响应返回的Set-Cookie里写的是Domain=.example.com。
-
Domain必须以点开头（如.example.com）才能匹配子域名；不加点（如example.com）只匹配精确域名，不匹配api.example.com -
Path默认是/，但如果填了/v1，那请求/v1/user能带Cookie，/v2/order就不会带 - Postman不会自动补全或修正你手输的
Domain值，输错就失效
为什么改了环境变量，Cookie还在发给旧域名？
Postman的Cookie是按“域名字符串”硬绑定存储的，和环境变量无关。你把环境变量从{{base_url}}改成https://staging.example.com，但Cookie仍存放在https://prod.example.com这个域下，它根本不会迁移到新域名。
使用场景：做灰度测试时，想用同一套Collection在prod和staging间快速切换，但登录态总串号——问题不在环境变量，而在Cookie没清理干净。
- 每次切换域名前，先打开
Cookies面板，手动删掉旧Domain条目（比如prod.example.com） - 不要依赖“清空所有Cookies”按钮，它只清当前会话，不保证跨标签页/跨Collection生效
- 如果用Runner批量跑，每个请求的Cookie作用域是独立的，需确保每个请求的URL解析出的域名和已存Cookie的
Domain完全一致
怎么确认某个请求实际带了哪些Cookie？
别猜，直接看。Postman提供了两处真实出口：一个是发出去的请求头，一个是响应里的Set-Cookie回写记录。
操作很简单：发完请求后，点击响应区域左上角的Cookies标签页，这里列出的是“本次请求**实际发送出去**的Cookie”，包括名称、值、Domain、Path，且按匹配优先级排序（最宽泛的排最后）。
- 如果列表为空，说明没有Cookie满足当前URL的
Domain+Path条件 - 如果列表有内容但接口报未登录，检查
Value是否过期（看Expires时间是否早于当前时间） - 右侧
Set-Cookie标签页显示的是服务器这次返回的新Cookie，不是你发出去的——别混淆这两块
Pre-request Script里手动设Cookie，为什么没生效？
因为pm.cookies.set()只是往当前请求的Cookie Jar里写入，但它不绕过Domain/Path校验。如果你写的Domain和当前请求URL不匹配，Postman依然会忽略它。
典型错误代码：pm.cookies.set("auth_token", "xyz", { domain: "example.com" });，而请求URL是https://api.example.com/login——这里domain必须写成.example.com才匹配。
- 脚本中设置Cookie时，
domain参数必须和请求URL的域名部分完全对齐，建议用pm.request.url.getHost()动态获取 -
pm.cookies.jar().set()支持更细粒度控制，但参数结构复杂，容易漏掉path或expires导致立即失效 - 脚本设的Cookie不会出现在
Cookies面板里，调试时只能靠console.log(pm.cookies)或抓包验证
真正麻烦的不是“怎么加Cookie”，而是“为什么它没出现”。每一次看似随机的缺失，背后都是Domain拼写、点号、大小写或Path斜杠的细微偏差。盯着Cookies面板右上角那个小图标点开看，比反复重发请求快得多。
