post请求必须设置content-type为application/json,否则后端通常收不到json数据或将其当普通文本处理;浏览器默认用text/plain发送,而express等框架仅在该头存在时自动解析请求体为对象。

POST请求必须设置Content-Type为application/json
不设这个头,后端通常收不到JSON数据,或者把整个JSON字符串当普通文本处理。浏览器默认用text/plain发体内容,而大多数后端框架(如Express、Django、Spring Boot)只在Content-Type: application/json时自动解析请求体为对象。
实操建议:
- 务必在
headers里显式写上{ "Content-Type": "application/json" } - 不要依赖
fetch自动推断——它不会帮你设这个头 - 如果后端报
400 Bad Request或req.body为空,先检查这个头是否漏了
JSON数据必须用JSON.stringify()序列化后再传给body
fetch的body只接受string、FormData、Blob等类型,不能直接传JS对象。传对象会报TypeError: Failed to execute 'fetch': Request with GET/HEAD method cannot have body这类误导性错误(实际是序列化失败导致底层异常)。
实操建议:
- 用
JSON.stringify({ name: "Alice", age: 30 })生成字符串,再赋给body - 避免手拼JSON字符串——容易引号错乱、特殊字符没转义
- 如果数据含
Date、undefined、函数等非标准JSON值,JSON.stringify()会静默丢弃,需提前清洗
记得处理响应状态码和JSON解析异常
fetch不会因HTTP错误状态(如400、500)抛异常,response.ok为false时仍会进入then分支。同时response.json()可能失败(比如返回空体、HTML错误页、非JSON格式文本)。
实操建议:
- 先判断
if (!response.ok) throw new Error(<code>HTTP error ${response.status}) -
response.json()要包在try/catch里,或用.catch()捕获解析失败 - 不要假设后端一定返回JSON——某些错误场景下可能返回纯文本或HTML,直接
.json()会崩溃
跨域时注意credentials和CORS响应头
带凭证(如Cookie、Authorization头)的POST请求,必须设credentials: "include",否则浏览器不发Cookie;但此时后端CORS响应头必须包含Access-Control-Allow-Origin具体域名(不能用*),否则浏览器直接拦截响应。
实操建议:
- 需要登录态时,加
credentials: "include",并确认后端设置了Access-Control-Allow-Origin: https://your-domain.com - 不需要Cookie时,可省略
credentials,降低CORS配置复杂度 - 若遇到
No 'Access-Control-Allow-Origin' header错误,不是前端代码问题,而是后端漏配CORS头
大量免费API接口:立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游,为数据API应用能力赋能!











