Postman判断响应是HTML登录页而非JSON，需检查Content-Type是否含html、Location头是否指向/login、响应体是否含login或DOCTYPE html，并在Tests中用断言拦截，如expect(pm.response.headers.get("Content-Type")).to.not.include("html")。
Postman怎么判断响应是HTML登录页而不是JSON数据
Postman本身不会自动识别“这是登录页”，它只按HTTP状态码和Content-Type返回原始响应。真正的问题是：你本该拿到JSON，却收到了HTML（比如重定向后的/login或/authorize页面），说明认证失败、会话过期或未携带必要凭证。关键不是“识别”，而是“提前预判并拦截”。
- 先看
Content-Type响应头：如果值是text/html或application/xhtml+xml，基本可断定不是API预期的JSON - 再看
Location响应头：若存在且指向/login、/oauth/authorize等路径，说明服务端做了302重定向——这是最典型的“被踢回登录页”信号 - 检查响应体开头：用
pm.response.text().startsWith("")或pm.response.text().includes("login")快速粗筛（注意大小写和空格） - 避免只依赖状态码：200不等于成功（HTML登录页也常返回200），401/403才是更可靠的未授权标志
Tests里写断言拦截HTML登录页
别等人工翻响应体，把检测逻辑放进Tests脚本里，让Postman自动报错。
- 用
pm.test加条件判断：比如pm.test("Response is not HTML login page", function() { pm.expect(pm.response.headers.get("Content-Type")).to.not.include("html"); }); - 检查重定向：如果接口不该跳转，就断言
pm.response.headers.has("Location") === false - 验证JSON可解析性：加一行
JSON.parse(pm.response.text())，捕获SyntaxError异常——HTML字符串解析必然失败，这时立刻fail测试 - 组合使用更稳妥：
pm.test("Should return JSON, not login HTML", function() { const body = pm.response.text(); pm.expect(body.startsWith("{") || body.startsWith("[")).to.be.true; });
为什么Pre-request Script里不能解决这个问题
前置脚本（Pre-request Script）只能准备请求，无法干预响应。HTML登录页的出现，本质是服务端对当前请求的拒绝响应，原因通常在：缺失Cookie、Authorization头、过期的token，或上一步没正确提取execution这类动态参数。
Postman 12.27.7
下载
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
-
Pre-request Script能做的只有补全请求：比如读取环境变量pm.environment.get("auth_token")，拼进Authorization: Bearer xxx - 但它无法预知服务端是否会重定向——那取决于你此刻的会话状态，而状态只在响应后才可知
- 真正的修复点在链路起点：确保上一个登录接口已成功执行，并把
token或sessionid正确存为环境变量，且当前请求的Headers里引用了它 - 常见漏点：
Set-Cookie没被Postman自动带入下个请求（需开启Automatically persist cookies）、SameSite=Lax导致跨域请求不发Cookie
容易被忽略的调试细节
很多人卡在“明明写了token，还是返回HTML”，问题往往藏在协议细节里。
立即学习“前端免费学习笔记（深入）”；
- 确认URL协议是否一致：HTTP和HTTPS混用会导致Cookie被浏览器策略丢弃，Postman虽不严格遵循，但某些网关（如Spring Security）会校验
X-Forwarded-Proto - 检查
Cookie头是否被覆盖：如果你在Headers里手动写了Cookie，它会完全替代Postman自动管理的Cookie；应改用pm.cookies.jar().set()方式注入 - 禁用Postman的“自动重定向”：在请求设置里关掉
Follow original HTTP method when redirected，否则POST被302后可能变成GET，丢失body参数 - 抓包对比：用Fiddler或浏览器DevTools看真实请求头，Postman有时会静默过滤掉某些敏感头（如
Origin），而服务端恰好依赖它做CSRF校验
