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，甚至配合修改系统时间（仅限本地调试）。
