Postman完全忽略SameSite属性，不校验、不执行其策略，所有Cookie均原样发送；它无第一方/第三方上下文概念，不模拟Secure/HttpOnly/SameSite行为，无法复现浏览器真实跨站Cookie限制场景。

Postman根本不解析SameSite属性

Postman对Set-Cookie响应头里的SameSite字段完全无视。它既不校验、也不按该规则决定是否发送Cookie，更不会在请求时主动过滤掉“本不该发”的Cookie。浏览器则严格遵循RFC 6265：遇到SameSite=Strict或Lax的Cookie，在跨站上下文中（比如从https://a.com跳转到https://b.com发起的请求）会直接跳过携带。这就是为什么你在浏览器里点个链接访问接口失败，而Postman一发就通——不是Postman“更强”，是它压根没执行这层逻辑。

Postman不区分第一方/第三方上下文

浏览器会根据当前页面URL、触发请求的方式（链接点击、表单提交、fetch调用）、目标URL三者关系，动态判断请求是否属于“跨站”，进而应用SameSite策略。Postman没有“当前页面”这个概念，所有请求都是孤立发起的，也就不存在“站内”或“站外”的语境。它只认你填的URL和手动加的Cookie头。这意味着：

• 即使服务端设置了SameSite=Lax，Postman仍会把Cookie原样带上
• 你无法用Postman复现“用户从微信内嵌页访问导致Cookie不发送”的真实问题
• 测试结果不能替代真实浏览器链路验证，尤其涉及登录态穿透、分享页跳转等场景

手动添加Cookie时，Postman只认value，不认metadata

你在浏览器开发者工具里看到的完整Set-Cookie头可能是这样的：
sessionId=abc123; Path=/; Domain=api.example.com; Secure; HttpOnly; SameSite=Lax

Postman的Cookie管理器（Cookies → Manage Cookies）能识别Domain和Path用于自动匹配，但Secure、HttpOnly、SameSite这三个属性它全部忽略。你手动在Headers里写Cookie: sessionId=abc123，它就照发；你用Cookie管理器导入，它也只存sessionId=abc123这部分。所以：

CDP浏览器大师

CDP浏览器大师：通过Chrome DevTools Protocol驱动已登录浏览器实现自动化任务，解决反爬封号、选择器失效、SPA路由难导航、固定sleep不准四大痛点。核心能力包括UA伪装、WebGL/Canvas指纹混淆、智能等待、动态选择器以及可视化调试。

下载

• 别指望Postman模拟Secure标志带来的HTTPS-only行为
• HttpOnly在Postman里毫无意义——它本来就不跑JS
• 如果你的后端逻辑依赖SameSite值做业务判断（比如拒绝SameSite=None的请求），Postman永远测不出来

真正需要关注的，是服务端怎么读取Cookie

Postman和浏览器行为差异的根源，不在客户端“怎么发”，而在服务端“怎么收”。很多团队误以为只要Postman能通，Cookie就一定没问题，结果上线后大量用户报“未登录”。实际排查时应重点确认：

• 后端框架是否强制校验Origin或Referer头，并据此拒绝非预期来源的Cookie？
• 反向代理（如Nginx）是否因SameSite字段格式不标准（如大小写、空格）而丢弃了整个Cookie头？
• CDN或WAF是否拦截了带SameSite=None但缺少Secure的Cookie？

这些环节，Postman都绕过去了，但它绕过去的，恰恰是你线上用户每天真实撞上的墙。