Postman提交表单返回400主因是请求构造与后端注解不匹配：@RequestParam需Body中x-www-form-urlencoded格式，@RequestBody需JSON且配Content-Type；Params仅用于URL参数，非表单提交；Content-Type可能被Postman隐藏头干扰；混用注解、CSRF拦截等亦致400。
Postman 提交表单返回 400，大概率不是后端代码问题，而是请求构造方式与后端接收逻辑不匹配 —— 尤其是 @RequestParam、@RequestBody 这两类注解对参数来源的硬性要求，踩中就直接 400。
Postman 的 Params 和 Body 标签根本不是一回事
很多人误以为在 Postman 的 Params 标签里填 key-value 就等于“提交表单”，其实完全相反：Params 是拼在 URL 后面的查询参数（?a=1&b=2），只适用于 GET 或极少数允许 URL 参数的 POST 接口。而 Spring 默认的 @RequestParam 在 POST 中只认 application/x-www-form-urlencoded 或 multipart/form-data 类型的请求体，不认 URL 参数。
- 用
Params发POST→ 请求体为空，URL 带参 → Spring 认为“你声称是 POST，却没传任何 body 表单数据”，直接 400 - 用
Body → x-www-form-urlencoded→ 请求体含键值对，Content-Type: application/x-www-form-urlencoded头自动带上 → 匹配@RequestParam预期 - 用
Body → raw → JSON→ 请求体是 JSON 字符串，但没加@RequestBody注解或后端没配 JSON 解析器 → 400 或空对象
Content-Type 头被 Postman 自动隐藏又悄悄改掉
Postman 默认会根据你选的 Body 类型自动设置 Content-Type，但这个头在 Headers 标签里是“hidden”状态 —— 如果你手动勾掉 Host 或其他系统头，有时会连带影响 Content-Type 的自动注入，导致它根本没发出去。后端收不到该头，或收到一个空/错的值，就会拒绝解析。
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
- 检查 Headers 标签右上角是否显示
Headers are automatically set；如果不显示，点右侧「×」清空所有手动添加的头，让 Postman 自主管理 - 如果必须手动加头，务必显式写入：
Content-Type: application/x-www-form-urlencoded（对应表单）或Content-Type: application/json（对应 JSON） - 特别注意：Spring Boot 2.6+ 默认禁用
spring.mvc.throw-exception-if-no-handler-found=true，但某些网关或过滤器仍会因缺失Content-Type直接拦截并返回泛化 400
@RequestParam 和 @RequestBody 别混用，否则必 400
这是最隐蔽也最常被忽略的坑：同一个接口方法，如果同时写了 @RequestParam String name 和 @RequestBody User user，Spring 会尝试从不同位置取参，一旦冲突或缺失，就抛 HttpMessageNotReadableException → 400。
-
@RequestParam只从查询参数（URL）或表单字段（x-www-form-urlencoded/multipart）取值，不读 JSON body -
@RequestBody只从原始请求体（raw body）反序列化，要求Content-Type: application/json，且 body 必须是合法 JSON - 常见错误写法：
@PostMapping("/login") public String login(@RequestParam String u, @RequestBody LoginReq req)→ 400 几乎必然发生 - 验证方式：把接口改成纯
@RequestParam，用 PostmanBody → x-www-form-urlencoded发；或改成纯@RequestBody，用raw → JSON发，分别测试
CSRF 和 Filter 拦截会静默转成 400
某些框架（如 Yii2、Spring Security 默认配置）会在请求进入 Controller 前做预校验。如果 CSRF Token 缺失、IP 不在白名单、或自定义 Filter 主动 reject，它们往往不返回 403，而是伪造一个 400 —— 因为从协议层看，“缺少必要安全凭证”也算客户端请求不完整。
- Yii2 中
$enableCsrfValidation = true时，POST 表单必须带_csrf隐藏字段，否则直接 400 - Spring Security 若配置了
http.csrf().disable()以外的策略，且未在 Postman 中携带X-CSRF-TOKEN头，也可能 400 - 排查建议：临时关闭相关 Filter 或中间件，或在 Filter 中加日志打印
request.getRequestURL()和request.getHeaderNames()，确认是否被提前截断
真正卡住人的从来不是“会不会写接口”，而是 Postman 界面里那些灰色小字、自动勾选、隐藏头和注解语义之间的微妙错位。多看一眼 Content-Type 是否真实发出，少信一句“我明明填了”，问题通常就解了一半。
