Postman中x-www-form-urlencoded可提交空字符串字段，只需在Value栏留空，Postman自动发送field=形式；而form-data会直接丢弃空字段，无法传递“空值”语义。
Postman 中 x-www-form-urlencoded 提交空字符串字段
Postman 默认允许在 x-www-form-urlencoded 模式下输入空值，但后端是否接受、如何解析，完全取决于服务端逻辑。很多框架（如 Spring Boot、Django）会把空字符串 "" 当作有效值，而非忽略或报错；而有些则会自动 trim 或转为 null。
实操要点：
- 在 Body →
x-www-form-urlencoded表格中，直接在Value栏留空即可（不要填null、undefined或空格） - 无需手动设置
Content-Type头——Postman 会自动添加application/x-www-form-urlencoded - 若字段名存在但值为空，请求体最终是类似
username=&password=123456的形式，这是合法且常见的 - 注意 URL 编码：空字符串不会被编码，但若误输空格（如
" "），会被编码为%20，可能触发非预期校验
form-data 模式下提交空文本字段
form-data 原本为文件上传设计，对纯文本字段的空值支持不如 x-www-form-urlencoded 直观。Postman 允许你在 Value 栏留空，但它会把该字段整个丢弃（不生成对应 part），导致后端根本收不到这个字段。
所以，如果你必须让后端收到一个“空字段”，而不是“字段缺失”，就不要用 form-data。
替代方案：
Postman 12.27.7
下载
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
- 改用
x-www-form-urlencoded—— 它能明确传递field= - 如果必须用
form-data（比如同时传文件+空文本），可在Value输入一个不可见字符，例如（零宽空格），再在后端做清洗 - 或者，用
raw+JSON，显式传{"field": ""}，前提是后端支持 JSON 解析
后端校验空字段时容易踩的坑
测试空字段不是“发出去就行”，关键看后端怎么处理。常见错误现象包括：400 Bad Request、500 Internal Server Error、或返回成功但数据库存了 NULL 而非空字符串。
排查建议：
- 检查响应体中的错误信息，比如 Spring Boot 常返回
{"timestamp":"...","status":400,"error":"Bad Request","message":"Validation failed"}，说明有 Bean Validation 拦截了空值 - 确认后端用的是
@NotBlank（拒绝空字符串）还是@Nullable+@Column(nullable = true)等组合 - 用 Postman 的
Console（底部面板）查看原始请求体，确认发送的确实是field=，而不是field（无等号）或field=null - 如果 API 文档写的是“字段可选”，但实际不允许空字符串，那属于契约不一致，需推动后端修正
批量测试多个空字段的快捷方式
手动清空每个字段效率低，尤其字段多时。Postman 本身不支持“一键清空所有 Value”，但有实用变通法：
- 复制一份原请求 → 在新请求中，全选 Body 表格 → 右键 →
Clear values（仅限桌面版 v10.20+） - 用
raw模式临时切换：粘贴一段格式化好的 key=value 字符串（如name=&email=&phone=），再切回x-www-form-urlencoded，Postman 会自动解析成空值行 - 写个简短的 Pre-request Script 自动置空（适合自动化场景）：
pm.request.body.urlencoded.clear(); pm.request.body.urlencoded.add([ {key: "username", value: ""}, {key: "password", value: ""} ])
空字段测试真正的复杂点不在 Postman 操作，而在你得清楚知道：这个空，是业务允许的“有效空”，还是协议层面不该出现的“缺失”。别只盯着能不能发出去，先盯紧接口文档里每个字段的 required 和 nullable 定义。
