Postman自动携带登录Cookie需开启Cookies设置并确保域名路径匹配；表单提交须用x-www-form-urlencoded格式、正确设置Content-Type及Referer/CSRF Token；Token认证则需通过环境变量存储并在Headers中添加Bearer Token。
Postman 怎么自动携带登录后的 Cookie 提交表单
只要后端用的是基于 Cookie 的会话机制（比如 Set-Cookie 响应头），Postman 默认就能维持登录态——前提是别关掉 Cookie 管理。
常见错误现象：登录请求返回了 200 OK，但后续表单提交仍被重定向到登录页或返回 401。大概率是 Cookie 没传过去。
- 确认登录请求的响应头里确实有
Set-Cookie（在 Postman 响应面板的 Headers 标签页里找） - 检查 Postman 右上角齿轮图标 → Settings → Cookies → 确保 “Enable cookies for all domains” 已勾选
- 不要手动清空 Cookie：点击请求右上角的
Cookie按钮后，别点 “Remove All Cookies” —— 这会把刚登录拿到的 session cookie 一并删掉 - 注意域（domain）和路径（path）匹配：如果登录接口是
https://api.example.com/login，而表单提交地址是https://example.com/form，跨域会导致 Cookie 不发送（浏览器同源策略限制，Postman 同样遵守）
用 x-www-form-urlencoded 提交表单时，Header 必须设对
表单提交不是发 JSON，Content-Type 错了服务器根本不会解析 body 里的字段，直接当无效请求处理。
典型场景：登录后访问订单页，再 POST 提交退单表单，参数是 orderId=123&reason=quality。
- Body 选项卡选
x-www-form-urlencoded，逐行填 key-value，别用raw - Headers 里必须有：
Content-Type: application/x-www-form-urlencoded - 如果后端依赖 Referer 或 User-Agent，也得手动补上（比如从浏览器 F12 Network 里复制过来）
- 别漏掉
Accept: application/json（如果期望 JSON 响应），否则某些 Spring Boot 接口可能返回 HTML 登录页
Token 认证下怎么让表单请求带上 Authorization
如果登录返回的是 token 字段（如 JWT），那 Cookie 就没用了，所有后续请求都得靠 Header 传 token。
Postman Mac版是一款专为macOS设计的API开发与测试工具，凭借简洁的界面和强大的功能，深受开发者喜爱。它支持发送各种HTTP请求（GET、POST、PUT等），轻松管理接口集合、环境变量和模拟服务器。Mac用户可享受原生性能、快捷键优化及与系统无缝集成的体验，适用于接口调试、自动化测试和文档生成。无论是个人项目还是团队协作，Postman for Mac都能提升API开发效率，是ma
容易踩的坑：用环境变量存了 authToken，但在表单请求里忘了加 Authorization 头，或者格式写错。
- 登录请求的 Tests 脚本里，确保正确提取并保存：
var jsonData = pm.response.json();<br>pm.environment.set("authToken", jsonData.token); - 表单请求的 Authorization 标签页，选
Bearer Token，Token 输入框填{{authToken}}（注意双大括号） - 或者手动在 Headers 添加：
Authorization: Bearer {{authToken}}—— 这种写法更可控，尤其当后端要求大小写敏感或带前缀时 - 如果 token 过期，表单提交会失败；建议在 Tests 里加断言：
pm.expect(pm.response.code).to.be.within(200, 299);，失败时立刻知道要重登
为什么有些表单提交总被拦截？重点看 Referer 和 CSRF Token
不少 Web 应用（尤其 Django、Spring Security）会对表单提交校验 Referer 或要求带 X-CSRF-Token，光有 Cookie 或 Token 不够。
这类拦截不会报明显错误，而是静默拒绝或跳转回首页，排查起来最耗时间。
- 先用浏览器 F12 抓一个真实成功的表单提交，对比 Headers 里有没有
Referer、X-CSRF-Token、X-Requested-With等字段 - 如果存在
X-CSRF-Token，它通常在登录成功后的响应头、HTML meta 标签，或某个单独的/csrf-token接口里返回，需要额外请求一次并提取 - Referer 必须和登录域名一致；Postman 发请求时默认不带 Referer，需手动在 Headers 加：
Referer: https://your-app.com/ - CSRF Token 一般是一次性的，用完即失效，不能复用——这意味着每次表单测试前，都得先跑一遍获取 Token 的请求
真正麻烦的从来不是“怎么发”，而是“发出去之后服务器认不认”。Cookie 域名、CSRF 时效性、Header 大小写、token 过期时间——这些细节不核对清楚，表单看着发出去了，其实根本没进业务逻辑层。
