Postman 自动携带登录 Cookie 的前提是：先手动发送同域同协议的登录请求并成功获取 Set-Cookie 响应头，启用自动 Cookie 管理，且目标接口 URL 与登录接口完全一致；Pre-request Script 中用 pm.sendRequest() 登录需手动调用 pm.cookies.set() 写入 Cookie，否则不会生效。
Postman 调用需登录的接口，本质是让后续请求携带有效的会话凭证（Cookie 或 token），而不是“登录一次就永久有效”。关键在于：凭证是否被正确获取、是否在作用域内自动携带、是否随响应更新。
怎么让 Postman 自动带上登录后的 Cookie
Postman 本身具备 Cookie 管理器，只要满足「同域 + 同协议 + 同路径前缀」，它就会自动把 Set-Cookie 响应头里的值存下来，并在后续请求中自动注入 Cookie 请求头。
- 必须先手动执行一次登录请求（如
POST /login），且该请求返回了有效的Set-Cookie头（比如PHPSESSID=abc123; path=/） - 目标接口 URL 的域名、端口、协议（
http/https）必须和登录接口完全一致；若登录是https://api.example.com，而目标接口写成http://api.example.com，Cookie 就不会带过去 - 检查是否启用了「自动 Cookie 管理」：点击请求右上角的
Cookies按钮，确认列表里有刚登录返回的条目；如果为空，说明登录没成功或响应没含Set-Cookie - 不要手动在 Headers 里加
Cookie头——除非你明确要覆盖或调试，否则会干扰自动管理逻辑
Pre-request Script 登录为什么经常失效
用 pm.sendRequest() 在 Pre-request Script 里发登录请求，看似自动化，但默认情况下它的响应 Cookie 不会写入当前请求的 Cookie 管理器，后续接口依然拿不到登录态。
- 脚本中调用
pm.sendRequest()是独立 HTTP 请求，它的Set-Cookie只影响自身上下文，不注入主请求的 Cookie 存储区 - 若坚持用脚本登录，必须手动提取响应头中的
Set-Cookie，再用pm.cookies.set()写入（注意：仅支持单个键值对，复杂 Cookie 如含Path/Domain需自行解析） - 更稳妥的做法是：把登录请求单独建一个接口，运行一次后，再运行依赖它的其他接口——利用 Postman 自身 Cookie 管理器的自动行为，而非绕过它
- 常见错误：脚本里漏写
body.mode = 'urlencoded'或参数拼错（如把username写成user_name），导致登录返回 401 或空响应，却误以为“脚本跑完了就登录成功了”
手动填 Cookie 头的适用场景和风险
直接在 Headers 里加 Cookie: key1=value1; key2=value2 是最快捷的临时方案，但极易出错。
- 适用于：浏览器已登录、Fiddler/DevTools 抓到现成 Cookie 字符串，且目标接口不校验
Referer、User-Agent或时间戳等附加字段 - 注意 Cookie 值必须是原始字符串，不能带换行或注释；多个键值用分号+空格分隔（
;后必须有空格） - 风险点：Cookie 通常有时效（
Max-Age或Expires），过期后接口返回 401 却无提示；部分系统还会校验HttpOnly或Secure标志，手动填的 Cookie 无法模拟这些属性 - 如果登录接口返回的是
token（如Authorization: Bearer xxx），那就根本不用碰 Cookie——Headers 加Authorization头即可，和 Cookie 机制无关
真正容易被忽略的点是 Cookie 的作用域细节：Domain 是否带点（.example.com vs example.com）、Path 是否匹配（/api/v1 的请求拿不到 Path=/admin 的 Cookie）、Secure 标志是否强制要求 HTTPS。这些不显眼的字段，往往才是“明明登录成功了，接口却说未登录”的真实原因。
