Postman里加cookie这事，说穿了就三步：打开请求，找到Headers标签，把Cookie字段填进去。但真操作起来，坑比想象中多。

我第一次用的时候，直接复制浏览器里的Cookie字符串，一长串像乱码似的东西，粘进去就发请求。结果服务器返回401，一脸懵。后来才发现，浏览器里的Cookie是加密过的，有的还带HttpOnly标记，Postman里根本用不了那套。你得用原始值——就是服务器Set-Cookie时给的那份。

更麻烦的是，有些接口的Cookie不是静态的。登录一次，服务器给你个session id，过半小时就过期。你手动复制粘贴，测试到一半突然失效，还得重新登录再复制一遍。烦不烦？烦。但有个笨办法：写个简单的登录脚本，用Postman的Tests标签页把返回的Cookie存到环境变量里，然后在下一次请求的Header中引用{ { cookie}}。这样至少能撑过一轮测试。

不过，环境变量也不是万能的。有一次我调试一个第三方支付接口，对方要求Cookie里带一个签名参数，这个签名是根据时间戳动态生成的。我存了变量，但每次请求前都得手动跑一遍登录脚本刷新签名，否则就报错。后来我干脆在Pre-request Script里写了个函数，自动计算签名并拼到Cookie里，这才算消停。

还有个容易忽略的细节：Postman的Cookie管理器（就是那个眼睛图标点开的面板）会拦截你手动设置的Cookie，如果你在Header里手动写了Cookie，同时又通过管理界面添加了Cookie，两者会合并发送。合并顺序还不一定按你写的来，有时候服务器就懵了，解析出重复的键值对。我吃过一次亏，排查了半天，最后发现是Postman自己帮我加了两个同名Cookie，一个来自手动Header，一个来自管理器。

所以我的建议是：要么完全走管理界面，要么完全走手动Header，别混着来。如果你要测试的是带登录态的接口，最省事的办法是先用Postman的Authorization标签页走一遍OAuth或Basic Auth流程，让Postman自动处理Cookie，而不是自己手动拼。但说实话，很多内部系统的接口压根不支持标准认证，就是老式的session cookie，那没办法，只能手动。

对了，还有个小技巧：在Chrome的开发者工具里，把某个请求复制为cURL格式，然后导入Postman，Cookie会自动带上。这个方式比手动复制靠谱，因为cURL格式里Cookie是经过转义的，Postman能正确识别。但注意，这种方式导入的Cookie也是静态的，过期了照样失效。

最后说个反直觉的事：有时候你加对了Cookie，请求还是失败，问题可能不在Cookie本身，而是User-Agent或Referer被服务器校验了。有些后端框架（比如老版本的Django）会检查Referer是否匹配，如果Postman默认的User-Agent太新，或者Referer为空，就直接拒绝。这时候别死磕Cookie，把浏览器里的完整请求头都搬过来，一次性搞定。

工具这东西，用久了自然摸清脾气。Postman的Cookie处理算不上优雅，但够用。记住一点：Cookie是状态，而HTTP本身是无状态的。你在Postman里手动维护状态，本质上是在模拟浏览器的行为。模拟得像，接口就通；模拟不像，就报错。就这么简单。