Postman中参数为空与不传是两种不同HTTP行为：填空字符串（如user_id=""）会拼成?user_id=发送，后端视为传空值；完全不填则URL中无该key，后端视为未提供，常走默认值或缺失校验。
参数为空和不传在 Postman 里是两种完全不同的 HTTP 行为，后端通常会按不同逻辑处理，不能混用。
Postman 中 params 栏填空字符串 vs 完全不填
在 Params 标签页里：
- 填了 key 但 value 是空字符串（比如 user_id → ""），Postman 会拼成 ?user_id= 发出去；
- 完全不填这一行，user_id 就不会出现在 URL 查询串里。
常见错误现象：
- 后端把 ?user_id= 当作“传了空值”，走空字符串校验分支（比如报“user_id 不能为空字符串”）；
- 而 ?user_id（无等号）是非法语法，Postman 不会生成，但手写 URL 或脚本误发时，某些服务会当成 user_id=null 处理；
- 真正的“不传”，URL 里压根没这个 key，后端可能走默认值、忽略或报“缺失必填参数”。
- GET 请求必须靠这个区分“空值”和“未提供”
- POST 的
application/x-www-form-urlencoded行为同理，body里有user_id=和没这行，语义不同 - JSON body 里写
"user_id": ""和不写user_id字段，也是两个分支
application/json 中字段为 null 或空字符串的处理差异
JSON body 里："user_id": null、"user_id": ""、根本不写 user_id，三者在后端解析后通常是三个对象状态：
-
null：明确传了，值为 null，常触发空指针检查或特殊兜底逻辑 -
""：非 null 字符串，长度为 0，可能被 trim 后判空，也可能直接进业务校验（如手机号不能是空串） - 字段缺失：Jackson/Gson 默认忽略，字段值为类型默认值（如 String 为 null，int 为 0），但若加了
@NotNull注解，反序列化就直接失败
Postman 里要测这三种，就得手动改 raw 内容，不能依赖 form-data 或 urlencoded 自动转换。
测试空参数时容易漏掉的边界场景
空参数不是只测 ""，真实接口常要覆盖这些组合：
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
- 参数含空格：
" "（前后空格）、"\t\n"（不可见字符） - 参数是数字类型却传空字符串：
{"age": ""}，后端 JSON 解析可能直接报错 400 - 数组字段传空数组：
"tags": []vs 字段缺失 vs"tags": null - 多级嵌套中某层为空：
{"profile": {"name": ""}}，比顶层空更难发现 - URL 编码干扰：
?q=%20（空格编码）会被 decode 成空格，不是空字符串
Postman 的 Pre-request Script 可以动态生成这些变体，比如用 pm.variables.set("empty_str", " ") 配合模板变量注入，避免手工反复改。
空参数测试最麻烦的点不在 Postman 操作，而在于你得清楚后端用的是什么框架、怎么反序列化、有没有全局 trim、字段是否 mandatory——否则光看响应码 200，可能已经悄悄跳过关键校验了。
