直接在Headers中填Cookie头最简单，但Key必须为“Cookie”，Value为分号+空格分隔的name=value字符串，不可含Expires等响应属性，且需确保域名、路径、协议（HTTPS）匹配服务端校验要求。
直接在 Headers 里填 Cookie 头最简单，但必须严格遵循格式
如果你已经知道完整的 Cookie 字符串（比如从浏览器开发者工具或抓包工具里复制来的），直接在请求的 Headers 标签页里加一行是最省事的做法。
关键点不是“能不能填”，而是“怎么填才不被服务端拒绝”：
-
Key必须写成Cookie（首字母大写，不能是cookie或COOKIE） -
Value是纯字符串，多个键值对用分号 + 空格分隔：JSESSIONID=abc123; user_token=xyz789; path=/ - 不要包含
Set-Cookie响应头里的那些属性（如Expires、Secure、HttpOnly），这些是服务端下发给客户端用的，客户端发起请求时只传name=value对 - 如果值里有空格、逗号、分号等特殊字符，通常已由服务端 URL 编码过，你照搬即可，别手动解码或再编码
用 Postman 的 Cookie 管理器填，适合需要控制 domain/path/expire 的场景
当你要模拟特定域名下的会话，或者接口对 domain、path、过期时间敏感时（比如单点登录、多子域系统），用右上角 Cookies 按钮打开管理器更稳妥。
操作中容易出错的地方：
- 填
Domain时不能带http://或路径，只写主机名：正确是api.example.com，错误是https://api.example.com/或api.example.com/xxx -
Path默认是/，如果接口只认/v2/下的 Cookie，就得手动改成/v2/ -
Expires时间必须是未来时间（GMT 格式），Postman 不会自动校验，填了过去的时间等于没设——请求发出时这个 Cookie 就被忽略 - 同一个 domain+path 下，不能存在两个同名 Cookie；后添加的会覆盖先添加的
pm.cookies 脚本设置只在 Tests 或 Pre-request Script 里生效，且不走 UI 管理逻辑
如果你想在登录后自动提取并复用 Cookie，而不是手动复制粘贴，就得靠脚本。但注意：pm.cookies.set() 和 pm.cookies.jar().set() 行为完全不同。
常见误区：
Postman 12.27.7
下载
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
-
pm.cookies.set("key", "value")只在当前请求生效，且不关联 domain/path，相当于临时覆盖，后续请求不会继承 - 真正要持久化、带作用域的设置，得用
pm.cookies.jar().set()，并显式传入domain和path：
pm.cookies.jar().set("JSESSIONID", "abc123", {
domain: "api.example.com",
path: "/"
});
漏掉 domain 参数，这个 Cookie 就只对当前请求 URL 生效，换一个接口地址就丢了。
为什么填对了还是 401/403？优先检查服务端是否校验 SameSite 或 Secure
Postman 本身不实现 SameSite 语义，也不强制走 HTTPS，所以即使你把 Secure 属性写进 Cookie 字符串，Postman 仍会把它发给 HTTP 地址——而现代服务端（尤其 Spring Security、ASP.NET Core）默认拒绝这种“不安全上下文中的 Secure Cookie”。
排查顺序建议：
- 先关掉所有 Cookie 管理，只用 Headers 手动填最简
Cookie: key=value，看是否成功 - 对比浏览器成功请求的原始请求头，确认有没有漏掉
Referer、User-Agent或自定义 header - 检查响应头里是否有
Set-Cookie带SameSite=None; Secure，如果有，你必须用 HTTPS 请求，且 Postman 不能开代理拦截 HTTPS（否则证书失败导致 Cookie 不存）
最常被忽略的是：你以为在填 Cookie，其实服务端早就在用 JWT 或 Header Token 做鉴权，那个 Cookie 字段只是个摆设，或者仅用于 CSRF 防护。
