Postman中参数被当成字符串是因HTTP规范及配置所致，并非Postman缺陷；需严格匹配后端期待的类型与接收方式，通过正确设置Body格式、Content-Type、参数位置及脚本逻辑来保障类型准确传递。
Postman 里参数被当成字符串，不是 Postman 的 bug，而是你没告诉它“这个值不该当字符串用”——比如后端期待的是数字、布尔或 JSON 对象，但你在 Params 或 Body 里直接填了 123 或 true，Postman 默认全当字符串发出去，后端一解析就出错。
Query 参数传数字/布尔时被转成字符串
GET 请求的 URL 参数（pm.request.url.query）本质是键值对，所有值都以字符串形式存在。即使你输入 page=2，后端收到的也是字符串 "2"，而非数字 2。某些强类型后端（如 .NET/WebAPI、Spring Boot）若用 [FromQuery]int page 接收，会静默失败或返回默认值。
- 确认后端是否要求原始类型：查接口文档，看参数标注的是
int、boolean还是string - 不要依赖 Postman UI 输入框“看起来像数字”：哪怕你输
0或false，它仍作为字符串发送 - 如果后端必须接收非字符串，改用
Body → raw → JSON发送，把参数包进 JSON 对象里（此时{"page":2,"active":true}中的2和true才是真实类型） - 实在只能走 Query，且后端不兼容字符串数字，需联系开发加一层类型转换逻辑，Postman 侧无法强制改变 URL 参数的字符串本质
Body 选错格式导致 JSON 字段被当纯文本
常见错误：在 Body → raw 里写了 {"id": 123}，但右侧 Content-Type 下拉菜单没选 JSON，而是留空或选了 Text。结果请求头没带 Content-Type: application/json，后端按普通文本解析，123 还是字符串。
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
- 务必检查右上角
raw右侧的下拉框：必须显式选JSON（它会自动加Content-Type: application/json） - 如果选了
Text或留空，即使内容是合法 JSON，Postman 也不会设 header，后端大概率当text/plain处理 - 用
form-data或x-www-form-urlencoded时，所有字段值**必然**是字符串——这是 HTTP 规范决定的，无法绕过；这类格式只适合表单类接口，不适合需要结构化数据的 API
Pre-request Script 里拼接参数时意外字符串化
写脚本动态设参数时，容易忽略 JavaScript 隐式类型转换。例如：pm.request.url.query.add("page=" + pm.variables.get("page_num"))，如果 page_num 是数字 5，拼出来仍是 page=5（字符串），没问题；但若你用 JSON.stringify() 包了一层，或误拼成 "page=" + JSON.stringify(5)，就会变成 page="5"（带引号），后端收到的就是字符串 "\"5\""。
- 避免无意义的
JSON.stringify()：Query 参数不需要 JSON 编码，直接拼原始值即可 - 从环境变量取值后，用
parseInt()或Boolean()显式转换再参与逻辑，但注意最终拼到 URL 上的仍是字符串形式 - 调试时用
console.log(typeof pm.variables.get("page_num"), pm.variables.get("page_num"))确认变量真实类型
后端接收方式与 Postman 发送方式不匹配
最隐蔽的问题：你以为自己发的是 JSON，其实 Postman 没发成；或你以为后端用 @RequestParam 接，其实它用的是 @RequestBody。典型表现是——参数填对了、格式也对了，但后端日志里压根没收到那个字段。
- 打开 Postman 的
Console（View → Show Postman Console），点 Send，看发出的完整请求：确认Headers里有Content-Type，且值符合预期；确认Body内容和编码与你选择的格式一致 - 对照后端代码：.NET 看有没有
[FromBody]或[FromQuery]；Java Spring 看是@RequestBody还是@RequestParam；Node.js Koa/Express 看用的ctx.query还是ctx.request.body - 一个硬核验证法：用 curl 模拟相同请求，绕过 Postman UI 干扰，例如：
curl -X GET "https://api.example.com/list?page=2&size=10"，对比响应是否一致
参数类型错位的问题，根源不在 Postman 而在于前后端约定没对齐。真正要盯住的不是“怎么让 Postman 发数字”，而是“后端到底想收什么格式”，然后让 Postman 严格照做——UI 输入、Body 格式、Header 设置、脚本拼接，四个环节任何一处脱节都会导致字符串化失效。
