Postman中判断字符串布尔值需用=== "true"而非=== true，因JSON解析不自动转换类型；应先console.log(typeof)确认类型，再用显式字符串比较或strToBool函数处理。
Postman 里 JSON 响应中的 isRetail、enabled 这类字段，如果后端返回的是字符串 "true" 或 "false"（带引号），而不是原生布尔值 true/false，那么在 Postman 测试脚本里用 === true 判断一定会失败——这不是你脚本写错了，是数据类型根本对不上。
如何判断响应里的布尔字段其实是字符串
先确认问题根源：打开 Postman 的 Tests 标签页，加一行调试输出：
console.log(typeof pm.response.json().data.users[0].isRetail);
如果输出 string，说明后端返回的是 "true"；如果输出 boolean，那才是真正的布尔值。常见错误就是没做这步验证，直接按“理应是布尔”去写判断逻辑。
- 后端用 Java 的
String.valueOf(boolean)、Python 的str(bool)或前端 JSON.stringify() 错误序列化，都会导致布尔变字符串 - 某些低版本 Spring Boot 默认把布尔字段转成字符串（尤其用了
@JsonSerialize自定义序列化器时） - Postman 自身不会自动转换类型，它只忠实解析 JSON 文本——引号包着的就是字符串
Postman 脚本中安全判断字符串布尔值
别用 === true，改用显式字符串比较或类型归一化：
- 最直白：用
=== "true"或=== "false"（注意大小写，JSON 规范要求小写） - 更健壮：先转成布尔再比，比如
pm.response.json().data.users[0].isRetail === "true"或封装成函数strToBool(val) { return val === "true"; } - 避免隐式转换陷阱：不要写
if (val)，因为"false"字符串在 JS 中是 truthy，会误判为真
示例（正确提取 ID）：
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
const res = pm.response.json();
res.data.users.forEach(user => {
if (user.isRetail === "true") {
pm.globals.set("UserId", user.id);
} else if (user.isRetail === "false") {
pm.globals.set("orgUserId", user.id);
}
});
后端修复建议：让布尔值真正是布尔
如果能改后端，优先从源头解决。不同语言典型修复点：
- Java（Jackson）：检查是否误用了
@JsonSerialize(using = ToStringSerializer.class)；确保字段类型是Boolean或boolean，且没配错序列化器 - Python（Pydantic/FastAPI）：确认模型字段声明为
bool，而非str；禁用Config.json_encoders对布尔的自定义处理 - Node.js（Express + jsonwebtoken 等）：避免手动拼接 JSON 字符串，始终用
res.json()发送原生对象
加个简单验证：用 curl 或 Postman 发请求，看原始响应体里字段有没有引号——"isRetail": true ✅，"isRetail": "true" ❌。
为什么不能依赖 Postman 自动转换
Postman 的 pm.response.json() 是标准 JSON.parse() 封装，它严格遵循 JSON 规范：只有不带引号的 true/false 才解析为布尔，其余全是字符串。没有中间层做“智能类型猜测”，也不会读取 Swagger/OpenAPI 定义来修正类型。所以一旦后端发错，客户端必须自己兜底。
最容易被忽略的一点：同一个 API，在测试环境返回布尔、生产环境返回字符串——可能只是配置差异或中间件（如 Nginx 重写、网关过滤）悄悄做了 toString 处理。上线前务必用原始响应体交叉核对。
