401/403反复出现而浏览器正常，因Postman默认不自动管理Cookie（如JSESSIONID）和Token，需手动控制会话生命周期；浏览器则自动维护。

登录状态过期不是“测不出来”，而是没模拟对会话生命周期——Postman默认不维护Cookie或Token的自动刷新，必须手动控制状态流转。

为什么401/403反复出现，但浏览器能正常访问？

因为浏览器自动管理Cookie（如JSESSIONID、PHPSESSID）和Storage中的Token，而Postman每次请求默认是独立会话。你看到的“登录过期”，往往是服务端Session已销毁，或JWT的exp时间戳已过，但Postman还在用旧凭证重放。

• 检查响应头是否有Set-Cookie字段：有，说明系统依赖服务端Session；没有但返回access_token，大概率走JWT流程
• 打开Postman Console，对比浏览器Network里同一请求的Cookie头内容，看是否缺失或值不一致
• 别只看Authorization头——有些系统同时校验Cookie和Authorization，缺一不可

如何真实模拟“登录态过期”场景？

不能靠等两小时，得主动构造失效条件。关键在控制凭证的生命周期起点和验证点。

Postman 12.27.7

Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。

下载

• 对于JWT：jwt.io解码后手动修改exp字段为过去时间（如1609459200对应2021-01-01），再填入Authorization: Bearer
• 对于Session：POST登录后，立刻在Postman的Cookies管理器（Settings → Cookies）中删掉该域名下的JSESSIONID，后续请求就必然403
• 在Tests脚本里加断言：pm.test("Token should be expired", function () { pm.expect(pm.response.code).to.eql(401); });，避免误判

Pre-request Script里怎么安全复用登录态？

硬编码Token或手动复制粘贴是最大隐患——过期了还得一个个改。要用环境变量+脚本联动。

• 登录请求的Tests里存Token：pm.environment.set("access_token", pm.response.json().access_token);
• 在后续请求的Pre-request Script中注入：pm.request.headers.add({key: "Authorization", value: "Bearer " + pm.environment.get("access_token")});
• 重要：登录请求本身要勾选Automatically persist cookies（Settings → General），否则Session类系统无法延续

真正容易被忽略的是：有些接口校验iat（issued at）而非exp，或者服务端做了二次时间窗口校验（比如要求iat不能早于当前时间5分钟）。这种情况下，光伪造exp没用，得同步篡改iat，甚至配合修改系统时间（仅限本地调试）。