Postman填域名必须去掉http和端口，只填纯域名（如example.com、localhost、127.0.0.1），否则Cookie不生效；Path需设为/才能覆盖全路径，Expires须为未来GMT时间，Headers硬写Cookie会绕过自动管理且无法更新。
Postman里填域名必须去掉http和端口
Postman的Cookie管理器只认纯域名，http://、https://、端口号（比如 :8080）、路径（比如 /api）全都不能带。填错会导致Cookie完全不生效。
常见错误现象：127.0.0.1:8085 或 localhost:3000 会被拒绝；https://example.com 保存后直接消失；请求发出但服务端收不到 Cookie。
- 正确写法：
example.com、localhost、127.0.0.1（注意：Mac 上localhost和127.0.0.1被视为不同域） - 开发常用场景：本地调试时用
localhost；联调测试环境用test-api.company.com；正式环境用api.company.com - 如果接口地址是
http://dev.example.com:9000/login，域名只填dev.example.com，端口和协议一律忽略
添加Cookie时path和Expires字段不是可选而是关键控制项
很多人点“Add Cookie”后只填 Name 和 Value 就点 Save，结果后续请求没带上——问题往往出在 Path 和 Expires 上。
Postman 12.27.7
下载
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
-
Path默认是/才能覆盖整个域下所有接口；如果填了/auth，那只有请求/auth/xxx才会携带该 Cookie -
Expires必须是未来时间（GMT 格式），例如Tue, 19 Jan 2038 03:14:07 GMT；填空、填过去时间、或格式错误（如用本地时区或 ISO 格式），Postman 会静默丢弃该条 Cookie -
Domain字段留空即可，Postman 会自动绑定到你前面输入的域名；手动填.example.com可能导致子域失效（除非你明确需要通配）
Headers里硬写Cookie和Cookie管理器行为完全不同
在 Headers 标签页手动加一条 Cookie key，值为 sessionid=abc123; token=xyz789，看起来最省事，但它绕过了 Postman 的 Cookie 生命周期管理。
- 这种方式不会被自动更新：登录接口返回新
Set-Cookie头时，Headers 里的硬编码值不会变 - 不会按 domain/path 匹配：它会在**所有请求头里无条件出现**，哪怕发给完全无关的域名
- 调试困难：响应里的
Cookies标签页看不到这条 Cookie，也无法编辑或删除 - 适合场景：仅用于一次性验证、绕过登录态的临时调试；长期维护的集合建议统一走 Cookie 管理器
Mac版Postman的localhost和127.0.0.1被视为两个独立域
这是 macOS 用户最容易踩的坑：你在 localhost 下添加了 JSESSIONID，但接口地址实际是 http://127.0.0.1:8080/api，Cookie 就不会自动带上。
- 解决方案只有一个：在 Cookie 管理器里分别添加
localhost和127.0.0.1两条域名记录，并各自设置对应 Cookie - 检查方式：发一次请求后，点响应左上角的
Cookies标签页，看有没有显示「Sent」状态的 Cookie；没有就说明域名不匹配 - 进阶提示：若后端设置了
Domain=127.0.0.1，那localhost域名下的 Cookie 永远不会被发送——浏览器和 Postman 都严格遵循 RFC 6265 的域匹配规则
