1. 先搞清楚Content-Type到底在干嘛
做Web开发的人，几乎每天都在跟Content-Type打交道，但真要问一句“它到底是什么、每种类型之间差在哪”，能讲清楚的人还真不多。我在项目里见过太多因为Content-Type设置不对导致的线上事故：前端明明传的是JSON，后端却按表单解析，结果字段全是null；上传文件没设multipart/form-data，服务端收到一个损坏的文件；响应头漏了charset，浏览器直接乱码。这些问题看起来都很低级，但根子上都是对Content-Type的理解糊里糊涂。
Content-Type的本质，是HTTP协议里用来描述“消息体（body）里装的是什么类型的数据”的字段。它既出现在请求头中，告诉服务器“我发给你的数据是什么格式”，也出现在响应头中，告诉客户端“你收到的数据应该怎么解释”。说得直白一点，如果HTTP报文是快递包裹，那Content-Type就是包裹上的物品清单——没有这张清单，收件人根本不知道该拿它当文件、当文本还是当图片来处理。
这篇文章不打算讲枯燥的RFC文档，而是从实际开发角度出发，把最常见的几类Content-Type挨个拆开，说清它们的格式差异、适用场景、前后端如何配合，再把面试和踩坑时最容易出问题的几个点单独拿出来讲。无论你是刚入行的前端、做接口的后端，还是写脚本的测试/运维，这篇内容应该都能帮你在处理数据格式时少走几个弯路。
2. 常见Content-Type全景拆解：每一种的格式与用途
2.1 text/plain、text/html与text/css：文本家族的三兄弟
text/plain是最朴素的文本类型，表示“这是一段没有格式的普通文字”。浏览器遇到它时，通常不会做任何解析，直接把内容当作纯文本展示在页面上。你写一个简单的记事本接口，返回值用的是text/plain，前端拿到后就是一段字符串，不存在任何额外的处理逻辑。
text/html则是浏览器的“母语”。服务器返回页面时，响应头里必须标注text/html，浏览器才会把内容当作HTML文档解析渲染。如果这个类型设置错了——比如返回HTML却标成了text/plain——浏览器就会把一堆标签原封不动地显示出来，看起来就像乱码的网页源码。反之，如果一个纯文本接口错误地标成text/html，标签会被浏览器解释，可能产生意料之外的UI效果。
text/css专门用于样式表文件，通常由<link>标签加载时浏览器自动识别。不过在实际接口开发中，这个类型一般只出现在静态资源服务器上，后端业务接口很少直接返回CSS内容。倒是有一点值得注意：text/*这一大类都支持charset参数，比如text/plain; charset=utf-8，用来声明文本的编码方式。如果漏掉charset，不同系统环境下的编码推断可能不一致，这在跨语言、跨平台联调时容易埋下乱码的隐患。
2.2 application/json：当前后端接口的“通用语”
application/json应该是现在最常被提到的Content-Type了。它的格式就是JSON字符串，支持嵌套的对象、数组、数字、布尔值等结构化数据。相比表单键值对，JSON的表达能力强一大截，这也是为什么RESTful接口默认都推荐JSON的原因。
JSON在请求中使用时，服务器需要按照JSON语法解析请求体。这里有一个非常关键的细节：JSON规范本身是Unicode编码，虽然理论上也允许其他编码，但实际开发中几乎统一约定使用UTF-8。所以你在设置application/json时，一般不用特意追加charset参数，默认就是UTF-8。
从前后端协作的角度看，JSON还有一个隐性的好处——它自描述性强。请求体里直接能看到层级结构，对接方不需要额外查文档就能猜到数据结构。但要注意，JSON对格式的要求是严格的：多一个逗号、少一个引号，整个解析都会失败。这也是为什么很多后端框架在解析JSON格式错误的时候，直接抛出一个400或415错误，而不是安静地返回null。
2.3 application/x-www-form-urlencoded：传统表单的默认格式
application/x-www-form-urlencoded是HTML表单<form>默认的提交格式（如果不显式指定enctype的话）。它的数据格式是key1=value1&key2=value2，和URL查询参数长得一模一样。在这个格式下，所有key和value都要做URL编码——空格变成+、中文变成%XX、特殊字符变成对应的十六进制编码。
这种格式的最大优点是简单、通用，任何HTTP客户端都能轻松构造。但它有两个明显的短板：一是无法表达嵌套结构，数组和对象只能靠约定（比如items[]=1&items[]=2这种模拟方式）；二是不适合传输大体积的二进制内容，效率低且容易出问题。
在实际开发中，这种格式最常见的使用场景是传统的登录表单、搜索框参数提交，以及某些老系统的回调接口。很多后端框架对它的解析支持非常成熟，Spring里的@RequestParam、Koa里的koa-bodyparser，都能直接把这种格式解析成普通的键值对象。不过我还是建议，除非是维护老项目，否则新接口尽量采用JSON，表达能力和可读性都好太多。
2.4 multipart/form-data：文件上传的唯一正解
multipart/form-data是专门为“表单里包含文件”设计的格式。它的特殊之处在于：不会对二进制内容做URL编码，而是用一段随机生成的boundary分隔符把不同字段和文件块切开。请求体的格式结构大致是这样的：
POST /upload HTTP/1.1 Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxk ------WebKitFormBoundary7MA4YWxk Content-Disposition: form-data; name="username" zhangsan ------WebKitFormBoundary7MA4YWxk Content-Disposition: form-data; name="file"; filename="a.png" Content-Type: image/png <二进制文件内容> ------WebKitFormBoundary7MA4YWxk--这个格式在HTTP报文中看起来比较复杂，但好在各种语言框架都对它做了封装，开发者平时手写它的机会不多。不过理解它的结构很重要——尤其是boundary字段的随机性。也就是说，每次请求的Content-Type头里都会带一个不同的boundary值，服务端靠这个值来切分数据块。如果你在代码里硬编码了一个固定的boundary去拼报文，极大概率会解析失败。
和application/x-www-form-urlencoded相比，multipart适合传文件的根本原因是它不进行URL编码，直接以原始二进制形式传输，文件的体积和完整性都能得到更好的保障。但要注意，multipart格式的报文体积会比纯文本大一些，因为每个字段都增加了额外的头部信息，所以在非文件上传场景下，用它显得有点杀鸡用牛刀。
2.5 application/xml与text/xml：老牌系统的最爱
XML在Web开发里的地位虽然大不如前，但很多企业级老系统、金融行业的接口协议仍然以XML为主。application/xml和text/xml两种标注在语义上几乎等价，区别在于：text/xml更强调人类可读，application/xml则强调机器处理的二进制或数据语义。实际开发中，后端解析这两种类型时通常没有明显区别。
XML相比JSON的优点在于：自带Schema定义能力，可以做强校验；支持注释；扩展样式表等附加处理。但缺点也很突出——冗长、解析慢、前端处理麻烦。我在实践中遇到较多的是第三方的开放接口，比如某些支付网关的回调报文就是XML格式，这就需要在服务端写一个XML解析器，把报文转换成对象后再进入业务逻辑。
如果你要设计新的接口，我不会推荐XML，除非有强制兼容需求。但如果工作中碰到XML格式的接口，别慌，只要按规范解析，它和JSON的难度差距并没有想象中大。
2.6 application/octet-stream与其它二进制类型
application/octet-stream是“未知二进制数据”的兜底类型，翻译成人话就是“这是一坨字节流，具体是什么你看着办”。浏览器遇到它时，通常会触发下载行为，而不是尝试在页面内展示。后端接口如果返回文件流，就可以用这个类型。比如导出Excel、下载压缩包、生成PDF这类需求，响应头里设置成application/octet-stream能避免浏览器误操作。
除了兜底的二进制类型，还有一批专用的二进制类型：图片有image/jpeg、image/png、image/gif、image/webp；音视频有audio/mpeg、video/mp4；办公文档有application/pdf、application/msword、application/vnd.openxmlformats-officedocument.spreadsheetml.sheet（Excel的xlsx）。这些类型在静态资源、附件上传、文件预览场景中非常常见。
我见过不少人在做文件下载接口时，为了省事所有文件一律返回application/octet-stream，这样做确实能下载，但用户体验很差——PDF明明可以在线预览，却变成了下载任务；图片明明可以直接在页面展示，也变成下载。所以，文件下载接口最好根据文件的实际类型动态设置Content-Type，这只是一个响应头的事，但带来的体验提升非常明显。
3. 核心类型对比：几组最容易搞混的选择
3.1 JSON vs x-www-form-urlencoded：谁更适合你的接口
这两者是最常被放在天平上比较的。表单格式以扁平键值对为核心，构造直观，发请求时几乎不用额外处理；JSON则能表达嵌套结构，可读性和扩展性更好。从服务端看，表单格式解析非常轻量，JSON解析会多一层反序列化的开销，但这个开销在现代硬件上几乎可忽略不计。
我总结了一套简单实用的选型逻辑：如果接口字段固定、平铺、无嵌套，且对接方是传统的HTML表单、老系统或硬件设备，优先application/x-www-form-urlencoded；如果数据结构有嵌套、有数组、有动态字段，或者对接方是前后端分离的现代Web应用，闭眼选JSON。
还有一个容易被忽视的点：JSON接口的自描述性更好，接口文档里可以直接贴上JSON示例，对方一目了然。表单接口则必须用字段字典来说明每一个key的含义，沟通成本更高。当然，标准RESTful架构里，JSON基本是唯一默认选择。
3.2 form-urlencoded vs multipart/form-data：别小看文件上传的格式选型
同样是表单，涉及到文件时就不能再用application/x-www-form-urlencoded了。根本原因在于：URL编码会把二进制内容转换成文本表示，文件体积大时这个过程既慢又容易出错，而且很多特殊字节在URL编码后的处理不统一。multipart格式则按二进制原样传输，文件内容不会失真。
具体项目实践中的选择标准也很简单：只有普通文本字段时用application/x-www-form-urlencoded或JSON；只要包含文件字段，比如头像、附件、导入Excel，就必须用multipart/form-data。有些场景是文本和文件混在一起，比如表单里既有用户名，又有头像文件，这种情况下整个请求体都必须使用multipart/form-data，让文件块和文本字段一起分割在同一个body里。
值得提一句的是，有些前端开发者图省事，把文件转成Base64字符串然后塞进JSON里发给后端。这种方式在小文件时能用，但文件一变大，Base64编码会让体积膨胀约33%，而且JSON接口的传输效率也不理想，整体算不上最佳实践。能传原始二进制就传原始二进制，这是文件传输的基本原则。
3.3 text/plain vs application/octet-stream：看似都能“传文件”，天差地别
text/plain和application/octet-stream都能传输原始内容，但语义完全不同。前者是“文本数据”，数据内容必须有字符编码，接收方拿到的是一个字符串；后者是“字节数据”，接收方拿到的是原始字节流，不做任何字符解码。
举个例子：接口要返回一段CSV内容，如果设置text/plain; charset=utf-8，浏览器或前端拿到后就是一个字符串，可以按行、按逗号去解析。如果设置成application/octet-stream，前端把它当作下载文件处理，保存后是.csv文件，打开方式取决于本机关联程序。
有些后端接口会返回“JSON字符串”但设置成text/plain，这种情况前端也能拿到文本，但缺少JSON的语义提示。虽然JavaScript里手动做JSON.parse也能处理，但多了一步操作，且不符合惯例。所以除非有特殊理由，宁可返回application/json，也不要把JSON硬塞进text/plain。
4. 前后端联调中的实操指南
4.1 前端如何正确设置Content-Type
先说XMLHttpRequest和fetch。现代前端项目里，主流选择是通过Axios或原生fetch发送请求。Axios的处理比较智能：如果你传的是普通对象，Axios不会自动设置Content-Type，而是让浏览器根据数据格式猜测；但如果你手动指定了Content-Type: application/json，Axios会在内部把对象序列化成JSON字符串。我用过的版本中，Axios的默认行为是：data是字符串时设置application/x-www-form-urlencoded，data是对象时设置application/json（实际是按数据格式决定）。这导致很多团队在联调时出现“我明明传了对象，后端却收到字符串”的困惑。稳妥的做法是显式声明类型。
// axios 发送 JSON axios.post('/api/user', { name: '张三', age: 18 }, { headers: { 'Content-Type': 'application/json' } }); // axios 发送表单 const params = new URLSearchParams(); params.append('name', '张三'); params.append('age', 18); axios.post('/api/user', params, { headers: { 'Content-Type': 'application/x-www-form-urlencoded' } }); // axios 发送文件 const formData = new FormData(); formData.append('file', fileInput.files[0]); formData.append('username', 'zhangsan'); axios.post('/api/upload', formData); // 注意：FormData 不需要手动设置 Content-Type原生fetch也一样，区别在于它默认不会自动序列化。你传字符串就发字符串，传对象需要手动JSON.stringify并设置JSON的Content-Type。之所以强调这一点，是因为很多新手第一次用fetch时，直接把对象传给body，结果后端收到的是[object Object]，这个坑几乎每届新人都踩一遍。
FormData场景有一个关键点：不要手动设置Content-Type为multipart/form-data。浏览器会自动生成边界标记并将其附加到Content-Type头中。如果你手动设置了，很可能会丢掉boundary参数，导致服务端无法正确解析。这个坑非常隐蔽，我在团队里至少帮人排查过三次。
4.2 后端如何根据Content-Type解析请求体
后端框架通常已经内置了类型解析能力，但了解背后的机制有助于排查问题。以Node.js的Express环境为例，express.json()中间件会解析application/json请求体，express.urlencoded({ extended: false })解析application/x-www-form-urlencoded，而文件上传需要引入multer来处理multipart/form-data。
如果你在Express项目中没有安装对应的中间件，或者中间件配置错误，请求体就无法被解析，req.body会是undefined或空对象。这种问题在排查时，第一步就是检查请求头里的Content-Type到底是什么——很多人会忽略这个最基础的信息。
Java的Spring Boot处理方式更自动化：@RequestBody注解自动处理JSON、XML等类型，@RequestParam处理表单字段，@ModelAttribute则会根据multipart/form-data自动绑定到实体对象。Spring Boot有一个特性容易坑到人：如果客户端发送的是application/json，但Controller方法只写了@RequestParam，参数永远接不到值；反之，客户端发表单格式，服务端用@RequestBody接，也会因为解析失败报异常。所以遇到参数接不到的问题，先确认“发送格式”和“后端接收方式”是否匹配。
我在实际联调中还会用Postman或Apifox做快速验证。这两个工具允许你显式选择请求体格式——有none、form-data、x-www-form-urlencoded、raw、binary几种选项，切换时工具会自动设置对应的Content-Type。如果你怀疑前端代码里的Content-Type设置有问题，可以先用这些工具发一个相同结构的请求，对比一下后端是否正常。这个方法能帮你快速定位问题到底出在前端还是后端。
4.3 编码与字符集：被忽略的乱码元凶
Content-Type里还有一个容易被忽略的参数——charset。只有文本类媒体类型（text/*、application/json、application/xml等）才有这个参数，它表示文本数据使用的字符编码。常见值有utf-8、gbk、iso-8859-1。
乱码问题的根源，绝大多数情况下是发送端的编码和服务端解析的编码不一致。举个例子：前端用JS发送fetch请求，body是JSON.stringify({ name: '张三' })，如果没有指定字符编码，浏览器一般会使用UTF-8编码传输；后端如果用的是request.setCharacterEncoding("GBK")，按GBK解析UTF-8数据，肯定乱码。
避免乱码的方法是规范统一：新项目一律使用UTF-8；所有接口的请求和响应都显式声明charset=utf-8；数据库连接串里也统一characterEncoding=utf-8；老项目如果要改成UTF-8，需要同时改页面编码、后端的字符过滤器、数据库连接参数，不能只改一处。这些要在项目启动时就约定好，等线上出了乱码再改，排查成本非常高。
5. 请求响应中的Content-Type差异与浏览器行为
5.1 请求头里的Content-Type与响应头里的Content-Type
可能有人会误以为请求和响应里的Content-Type是同一个东西，其实它们是两个独立的字段，语义也不同。请求头里的Content-Type由客户端（浏览器、App、curl等）设置，表示“我发给你的数据格式”；响应头里的Content-Type由服务器设置，表示“我返回给你的数据格式”。
实际开发中的一个常见错误是，前端在发请求时设置了Content-Type: application/json，就以为响应也一定是JSON，这完全不对。响应的Content-Type是后端代码控制的，和请求头没有绑定关系。有些后端接口无论请求是什么格式，响应统一返回application/json，这是合理的；但也有的后端接口偷懒，响应头里标text/html或干脆不标，导致前端response.json()报错——这种时候你需要和后端沟通，让他在响应头里正确设置，而不是在前端做workaround绕过。
服务端因此要注意一个规范性问题：HTTP/1.1协议规定，如果响应包含消息体，那么响应头里必须包含Content-Type；如果响应没有消息体（比如204 No Content），则不应该发送Content-Type。很多框架会自动帮你遵守这个规则，但如果手写原生HTTP响应，就需要注意别在204响应里额外塞一个Content-Type。
5.2 响应头里的Content-Type如何影响浏览器渲染与下载
浏览器对响应内容的处理策略，跟Content-Type和Content-Disposition两个字段都有关。正常情况下，浏览器是根据Content-Type决定如何展示内容：text/html渲染成页面，image/png展示图片，application/pdf唤起内置PDF阅读器或下载工具，application/octet-stream触发下载。
如果你希望强制用户下载某个文件，而不是在浏览器里直接打开，就需要额外设置Content-Disposition: attachment。这个字段的优先级高于Content-Type的展示语义。反过来，如果接口返回的是CSV或PDF预览，但没设置Content-Type或设置错误，浏览器可能直接下载一个没有扩展名的文件，用户根本无法正常使用。
我处理过一个具体案例：某个报表导出接口，后端返回Excel的二进制数据，但响应头写的是text/plain。结果就是浏览器打开一个新标签页，显示一堆乱码的二进制字符，用户体验非常差。修改方案很简单：把Content-Type改成Excel对应的MIME类型（application/vnd.openxmlformats-officedocument.spreadsheetml.sheet），同时加上Content-Disposition: attachment; filename="report.xlsx"，问题直接解决。这类问题本质上就是对Content-Type的语义理解不到位。
6. 常见问题与排查技巧实录
6.1 请求发出去了，后端却收不到参数
这是Content-Type相关的高频问题。表现形式通常是：前端打印data有值，请求也发出去了，但后端日志里request参数为空或全为null。
排查顺序我一般这样走：
第一步，打开浏览器开发者工具的Network面板，点击请求，查看Request Headers里的Content-Type值。
- 如果没显示Content-Type，说明浏览器用的是默认的
text/plain;charset=UTF-8，而服务端不会自动解析这种格式，参数自然接收不到。 - 如果是
application/x-www-form-urlencoded但实际发送的是JSON字符串，后端按字段解析时只能解析出第一层。 - 如果是
application/json但请求体是URL编码格式的query string，后端JSON解析器直接报错。
第二步，检查请求体的实际内容。可以在Network面板里切换到Payload或Request标签，看body原始内容。这里能直观看到请求体到底长什么样。
第三步，检查服务端是否加载了对应的解析中间件/配置。比如Spring项目里没有加@RequestBody注解，Koa项目里没有ctx.request.body相关的bodyParser配置。
这个排查流程速度很快，能定位九成以上的参数接收问题。
6.2 415 Unsupported Media Type错误的含义与解法
415状态码的官方含义是“服务器无法处理请求中携带的媒体格式”。简单说，就是请求的Content-Type不在服务端支持的范围内。
出现415时，优先检查后端接口是否限制了Content-Type。比如某个接口明确只接受application/json，你发了一个text/plain，后端直接抛415。解法很简单：把Content-Type改成后端支持的格式。如果后端接口本身没有做限制，那问题就出在框架层——比如Spring MVC的@PostMapping(consumes = "application/json")，只接受JSON格式请求，其它格式一律415。
排查415时，我建议先看一下后端框架返回的响应体里是否包含更详细的错误信息。有些框架会提示“Supported media types: application/json”之类的文字，直接告诉你该用哪种类型，照着改就行。
6.3 文件上传后打开损坏、下载的文件没后缀
文件上传后损坏，最常见的两个原因：一是前端没用multipart/form-data格式，而是把文件塞进JSON或form urlencoded里传输，二进制内容在传输过程中发生了截断或转义；二是上传过程中对文件做了不必要的字符串处理，比如手动做了JSON.stringify，把二进制文件内容转换成了字符串。
文件下载后没有后缀名或打开方式错误，原因也基本锁定在响应头Content-Type不正确（返回为application/octet-stream或漏掉）以及缺少Content-Disposition的文件名参数。文件名里如果有中文，还需要特别注意Filename的编码问题——如果直接返回filename="中文.xlsx"，某些浏览器会乱码，更稳妥的做法是同时提供filename*=UTF-8''编码后的文件名。
下面整理一份快速排查速查表，适合贴在工位上：
| 现象 | 优先检查项 | 常见根因 |
|---|---|---|
| 后端参数为null | 请求头Content-Type | 发送格式与后端解析方式不匹配 |
| 请求报415 | 后端接口consumes配置 | 请求类型不被接口接受 |
| 页面乱码 | Content-Type的charset | 发送端与服务端编码不一致 |
| 文件下载乱码 | 响应Content-Type | 文本类型错误地用于二进制数据 |
| PDF/图片变成下载 | 缺少Content-Disposition | 未使用inline语义或类型不匹配 |
| 文件上传后损坏 | 请求格式 | 未使用multipart/form-data |
| 浏览器显示源码 | 响应Content-Type | HTML被标为text/plain |
提示：排查任何Content-Type问题，第一件事永远是打开开发者工具看实际请求和响应的原始报文，而不是靠猜。纸上谈兵永远不如看真实数据。
6.4 老项目中的兼容性与“隐性”坑
老项目里，最常见的两类坑都和“历史包袱”有关。
第一类是编码不统一。某些老系统的数据库用GBK，页面是GBK编码，但新接入的前端用UTF-8，两侧数据一交汇就乱码。这个问题的经典场景是：网页上提交中文，后端存进数据库后不是乱码，但如果通过接口直接查数据库、再用JSON返回给前端，可能就乱码了。因为中间的传输层、连接串、JSON序列化这几个环节，任何一处没统一成UTF-8都会出问题。
第二类是一些框架对Content-Type处理行为的差异。比如某些老版本的框架对application/json请求体解析有BUG，或对multipart/form-data的boundary格式识别不严格。排查这类问题时，可以把版本升级到稳定的较新版本，或者在框架层面加一个统一的消息转换器来兜底。但从架构角度看，老项目的债务如果不主动清理，这类“隐性”坑会一直埋伏着，每次联调都可能踩到。
7. 内容协商：Content-Type之外的Accept头
聊到这里，有必要顺带提一个和Content-Type紧密相关的字段——Accept。很多人把它们搞混，但其实分工完全不同：Accept是客户端告诉服务器“我希望收到什么格式的响应”，Content-Type是发送方告诉接收方“我现在的数据是什么格式”。一个是期望，一个是声明。
HTTP的内容协商机制（Content Negotiation）就是基于这两类头字段展开的。客户端请求时带上Accept: application/json，服务端根据这个偏好返回对应类型的响应。Spring Boot中可以通过@GetMapping(produces = "application/json")指定响应格式，当客户端的Accept不符合时，服务端会返回406 Not Acceptable。
实际开发中，如果你做的是一个对外提供多格式支持的API，比如同一个数据既可以返回JSON也可以返回XML，那么Accept和Content-Type的配合就显得格外重要。客户端通过Accept声明想要的格式，服务端通过Content-Type声明实际返回的格式。如果两者对不上，客户端解析时大概率会出问题。
这个机制我推荐大家在设计API时主动使用，尤其是公开API的场景。用Accept做协商，比在URL里传?format=json或者?format=xml这种参数要规范得多，语义也更清晰。
8. 最后的几点实践经验
写到这里，关于Content-Type的内容基本都覆盖到了。我个人在项目里积累了几条判断和处理相关问题的原则，分享出来供参考：
第一，永远不要依赖“默认”。无论是前端框架还是后端框架，尽量显式设置Content-Type。虽然框架可以自动适配，但一旦出问题，排查成本远高于手动写明类型那几行代码。
第二，团队内部要有一个统一约定：新接口一律JSON，文件上传一律multipart，导出文件按真实MIME类型设置响应头。这种约定不需要多复杂，但在跨组协作时能省掉大量无效沟通。
第三，排查问题时从最原始的报文看起。很多看起来高深莫测的Bug，只要打开Network面板看一眼前后端“实际发送/返回的Content-Type和body内容”，答案立刻浮出水面。不要靠猜，不要靠记忆，要看真实数据。
第四，定期用抓包工具或接口测试客户端检查一下线上接口的实际响应头信息。有时候Nginx网关或安全网关会篡改或剥离Content-Type头，这种问题在本地开发环境永远重现不了，只有线上环境才暴露，一旦发现要立刻修复网关配置。
Content-Type并不是一个高深的概念，但它贯穿整个HTTP交互过程，值得每个开发者花点时间吃透。希望这篇整理对你有一些帮助，也欢迎你在实际踩坑后有新的心得再去补充完善它。
