JMeter使用CSV Data Set Config进行负载测试报Unsupported Media Type错误

415错误和CSV Data Set Config组件本身没有直接关系，核心原因是服务端无法识别你发送请求的媒体类型格式，按以下优先级逐一排查即可：

• 第一优先级核对HTTP信息头管理器配置：不要写自定义的content头，必须使用标准的Content-Type请求头，值要和接口要求完全匹配：
  • 传JSON参数的接口固定填application/json;charset=UTF-8
  • 普通表单提交接口填application/x-www-form-urlencoded;charset=UTF-8
  • 带文件上传的接口才填multipart/form-data
    拼写错误（比如写成小写content-type、漏写charset、值和接口要求不匹配）是触发这个错误的最高频原因。
• 核对请求体格式和声明的Content-Type是否一致：如果声明了JSON类型，请求体必须是严格合法的JSON结构，尤其注意从CSV读取的参数如果带未转义的引号、换行、多余空格，会直接破坏JSON结构，导致服务端解析失败。建议添加「察看结果树」监听器，查看实际发出的请求原文，和Postman/前端调通的正常请求逐字对比。
• 检查HTTP信息头管理器的作用域：如果线程组下不同层级加了多个信息头管理器，子请求的配置会覆盖父级配置，要确认报错请求实际生效的Content-Type值没有被覆盖。
• 检查HTTP请求配置项：如果接口是普通JSON/表单提交，不要勾选POST请求下的Use multipart/form-data for POST选项，勾选后会强制修改请求格式，和手动设置的Content-Type冲突直接触发415。
• 排查CSV文件本身问题：将CSV文件另存为UTF-8无BOM格式，避免编码异常导致参数值带不可见特殊字符，破坏请求结构；排查时可以先设置1线程1次循环，确认单请求跑通后再逐步提高并发和循环次数。

快速定位技巧：先把已经调通的正常请求（比如Postman调试成功的请求）的头、请求体原封不动复制到JMeter，不使用参数化先跑通，再逐个替换为CSV读取的参数，每替换一步执行一次，很快就能定位到配置错误点。

内容的提问来源于stack exchange，提问作者vincent