Fetch API实战指南：从基础到高级应用

1. 为什么Fetch API是现代前端开发的必备技能

作为一名经历过jQuery时代的开发者，我至今还记得第一次接触Fetch API时的震撼。相比传统的XMLHttpRequest，Fetch提供了更简洁、更强大的异步请求能力。但很多开发者（包括曾经的我）在使用时常常陷入一些看似简单却影响深远的陷阱。

Fetch API基于Promise设计，这意味着我们可以告别回调地狱。但它的强大远不止于此——从简单的GET请求到复杂的文件上传，从JSON处理到二进制数据流，Fetch都能优雅应对。然而，正是这种表面上的简单性，让很多开发者忽略了其底层机制，导致在实际项目中频频踩坑。

2. JSON数据处理的正确姿势

2.1 Content-Type的重要性

在前后端分离的架构中，JSON已经成为数据交换的事实标准。但很多开发者发送JSON请求时常常忽略一个关键点：Content-Type头。

javascript复制// 错误示范 - 缺少Content-Type
fetch('/api/user', {
  method: 'POST',
  body: JSON.stringify({name: '张三'})
})

这样的请求看似简单，却隐藏着严重问题。服务器无法自动识别请求体的格式，很可能返回415 Unsupported Media Type错误。

2.2 正确的JSON请求方式

javascript复制// 正确做法
fetch('/api/user', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    name: '张三',
    age: 25
  })
})

这里有几个关键点需要注意：

1. Content-Type必须明确设置为application/json
2. 数据必须经过JSON.stringify序列化
3. 即使数据很简单，也不应该省略这些步骤

提示：在后端开发中，Express需要使用app.use(express.json())中间件来解析JSON请求体，而Spring Boot则需要@RequestBody注解。

2.3 常见错误排查

当JSON请求出现问题时，可以按照以下步骤排查：

1. 检查开发者工具中的Network面板，确认请求头是否包含Content-Type: application/json
2. 确认请求体确实是字符串化的JSON，而不是JavaScript对象
3. 检查后端是否配置了正确的JSON解析中间件

我曾经遇到过一个棘手的bug：前端发送的JSON请求在某些浏览器上工作正常，但在另一些浏览器上却失败。经过仔细排查，发现是某个浏览器插件修改了Content-Type头。这个经历让我明白，永远不要假设运行环境是完美的。

3. 请求参数的正确传递方式

3.1 GET请求的参数处理

GET请求的参数应该通过URL的查询字符串传递。很多开发者会犯两个常见错误：

1. 试图在GET请求中使用body传递参数
2. 手动拼接URL导致编码问题

javascript复制// 错误示范 - 手动拼接URL
fetch(`/api/search?q=${keyword}`) // 可能引发编码问题

// 正确做法 - 使用URLSearchParams
const params = new URLSearchParams({
  q: '前端开发',
  page: 1,
  size: 10
})
fetch(`/api/search?${params}`)

URLSearchParams会自动处理特殊字符的编码问题，避免URL格式错误。

3.2 POST请求的表单数据

当需要发送表单数据时，应该使用FormData对象而不是JSON：

javascript复制const formData = new FormData()
formData.append('username', '李四')
formData.append('password', '123456')

fetch('/api/login', {
  method: 'POST',
  body: formData
})

这种情况下，浏览器会自动设置Content-Type为multipart/form-data，并生成正确的请求体格式。

注意：当使用FormData时，不要手动设置Content-Type头，浏览器会自动处