Postman传JSON字符串本质是传String值，@RequestParam需用Params或Form-data并URL编码，@RequestBody必须用raw+JSON且内容为标准JSON；二者Content-Type设置和数据格式要求截然不同。
Postman 传 JSON 字符串参数，本质不是“传 JSON”，而是传一个 String 类型的字段值，其内容恰好是合法 JSON 文本。后端用 @RequestParam 或 @RequestBody 接收时，行为完全不同——搞错这个前提，90% 的 null、400、415 错误就来了。
Postman 用 Query 或 Form-data 传 JSON 字符串（@RequestParam 场景）
当后端方法形如 @PostMapping("/api") public String handle(@RequestParam String data)，你必须把整个 JSON 当作字符串塞进 URL 查询参数或表单字段里，不能选 raw + JSON 模式。
- 选
Params标签页，Key 填data，Value 填：{"name":"alice","age":28} - 如果 JSON 含特殊字符（
{、}、[、]、"），Postman 不会自动编码，必须手动 URL 编码，否则请求直接 400；例如{"id":1,"tags":["a","b"]}要变成：%7B%22id%22%3A1%2C%22tags%22%3A[%22a%22%2C%22b%22]%7D - 别在
Headers里加Content-Type: application/json——这是干扰项，@RequestParam不看这个头，只从 query 或 form 解析字符串
Postman 用 raw + JSON 传结构化 JSON（@RequestBody 场景）
后端用 @RequestBody UserDto user 接收时，Postman 必须走 Body → raw → JSON，且整个请求体就是 JSON 对象/数组，不能套在字段名里。
- Body 选
raw，右侧下拉菜单选JSON（这会自动加Content-Type: application/json） - 输入内容必须是标准 JSON：键名必须双引号包裹，不能用单引号；末尾不能有多余逗号；中文没问题，但标点必须是英文符号
- 常见错误：
{name:"alice"}（键没引号）、{"name":"alice",}（尾逗号）、user:{"name":"alice"}（多包了一层字段名）——这些都会导致后端解析失败或400 Bad Request - 如果后端接收的是
List，直接传：[{"name":"a"},{"name":"b"}]，不要包装成{"users":[...]}
后端接收 String 类型 JSON 字符串的典型写法
很多老项目或需要动态解析的接口，会把 JSON 当字符串接收，再用 FastJSON/Gson 手动转对象。这时前后端约定最关键。
- Controller 方法参数必须明确是
String，比如：public int batchInsert(@RequestParam String userDtos) - 前端传参方式只能是 Query 或 Form-data，不能用
raw；否则 Spring 会尝试按 JSON 反序列化，类型不匹配直接报错 - FastJSON 解析示例：
JSONArray.parseArray(userDtos, UserDto.class)—— 注意这里userDtos是纯字符串，不是对象 - 别在
@RequestParam上加required = false还不校验空字符串，""和null都可能进到解析逻辑里，触发 NPE
容易被忽略的兼容性细节
同一个接口，不同环境的 Spring Boot 版本对空格、换行、BOM 头敏感度不同，看似一样的 JSON 在某些机器上就 400。
- Postman 的
raw模式默认带格式化缩进，但某些旧版 Spring MVC 会把换行符当非法字符；建议粘贴前用在线工具压缩成单行 JSON - 复制 JSON 时不小心带了 UTF-8 BOM（尤其 Windows 记事本保存的），Postman 看不出，但 Jackson 会报
Unexpected character；用 VS Code 打开检查编码，存为 “UTF-8 without BOM” - 如果后端用了
@Valid校验，而 JSON 字符串里某个字段值为空字符串""，但实体类字段加了@NotBlank，校验就会失败——这不是传参问题，是校验逻辑和数据约定没对齐
