Postman中HTTP请求不带Cookie的根本原因是服务端Set-Cookie头含Secure属性，该属性强制Cookie仅在HTTPS下自动发送，HTTP请求中被协议层直接过滤，无法手动绕过。
Postman里HTTPS请求带Cookie，HTTP请求不带：Secure属性强制拦截
根本原因是服务端下发的Set-Cookie头中包含Secure属性，而Postman严格遵循HTTP协议规范——带Secure的Cookie只会在https://协议下自动发送，绝不会出现在http://请求的Cookie请求头中。
这不是Postman的bug，是浏览器和Postman共同遵守的安全契约。你看到“HTTP没Cookie”，其实是它被协议层直接过滤掉了，连尝试发送的机会都没有。
- 检查响应头里的
Set-Cookie字段是否含Secure（例如：sessionId=abc123; Path=/; Domain=example.com; Secure; HttpOnly） - 确认你发HTTP请求时，目标URL确实是
http://开头（不是误输成https://或漏写协议） - 别试图在HTTP请求里手动加
Cookie头去“绕过”——即使值对，服务端通常也会因协议不匹配拒绝会话校验
为什么Postman不警告或降级处理Secure Cookie？
因为Secure不是可选提示，而是强制语义：它声明“此Cookie仅用于加密信道”。Postman若在HTTP下偷偷发送，等于主动破坏安全边界，违背设计原则。
常见误解是“关掉SSL验证就能让Secure Cookie生效”，但这是错的：SSL certificate verification开关只影响证书校验，不影响Cookie协议行为。哪怕你关了验证、用HTTP协议、手动填了Cookie字符串，Postman依然不会把Secure标记的Cookie塞进请求头。
-
Settings > General > SSL certificate verification关闭后，仅跳过TLS握手检查，对Cookie生命周期无任何影响 - 想验证Cookie是否真被忽略？打开Postman控制台（View → Show Postman Console），发一个HTTP请求，看请求头里有没有
Cookie字段 - 如果服务端同时支持HTTP/HTTPS且允许非Secure Cookie，应由后端在
Set-Cookie中显式去掉Secure，而不是前端硬扛
测试HTTP环境时怎么让Cookie正常流转？
只有两个合法路径：要么让服务端下发非Secure的Cookie，要么把测试环境切到HTTPS。没有第三种“兼容模式”。
- 开发阶段可在SpringBoot的
application.yml中配置server.servlet.session.cookie.secure=false（注意仅限dev） - 若用Nginx反代，检查是否启用了
proxy_cookie_flags ~ secure这类强制注入规则 - 临时调试可用Postman的
Cookies管理器手动添加一条无Secure的Cookie：域名填准确（如localhost或127.0.0.1），Path设为/，不勾选Secure复选框 - 切记：手动添加的Cookie不会自动继承
HttpOnly或SameSite限制，但Secure缺失会导致它在HTTPS请求中被浏览器/Postman丢弃
同一个域名下HTTP和HTTPS共存时的Cookie隔离问题
现代浏览器和Postman都把http://example.com和https://example.com视为两个独立的Cookie作用域。就算你手动在HTTP下存了Cookie，HTTPS请求也完全看不到；反之亦然。
这意味着：你在HTTP登录接口拿到的Session ID，无法直接用于HTTPS下的后续请求——它们压根不在一个存储桶里。这种隔离不是Bug，是防止混合协议下Cookie被中间人窃取的关键机制。
- 测试跨协议流程（比如HTTP登录 → HTTPS查数据）必须走真实重定向链路，不能靠人工复制粘贴Cookie
- Postman的
Cookies面板里，http://和https://域名会分开展示，别指望滚动条拉到底就找到另一个协议的Cookie - 最易忽略的一点：本地开发常用
http://localhost:8080，但有些后端框架（如Spring Security）默认只对https启用Session Cookie，对http直接跳过Set-Cookie逻辑——此时连Cookie都没下发，更别说Secure了
