PUT需设method、含ID的URL、Content-Type头及JSON.stringify后的body；DELETE只需method和含ID的URL，通常无body，注意CORS预检与手动检查res.ok。
用 fetch 发起 PUT 和 DELETE 请求和 GET/POST 类似，关键在于正确设置 method 选项，并根据需要配置 headers 和 body。
PUT 请求：更新资源
PUT 通常用于**全量更新**某个已存在的资源，需提供完整数据体（如 JSON），并指定目标 URL（含 ID）。
- 必须设置
Content-Type: application/json头（除非后端明确支持其他格式） -
body需是字符串，用JSON.stringify()转换对象 - 确保后端路由支持 PUT 方法，且路径包含唯一标识（如
/api/users/123）
示例：
fetch('/api/posts/5', {
method: 'PUT',
headers: {
'Content-Type': 'application/json'
},
body: JSON.stringify({
title: '新标题',
content: '更新后的内容'
})
})
.then(res => res.json())
.then(data => console.log('更新成功:', data));
DELETE 请求：删除资源
DELETE 一般只需 URL（含 ID），不带请求体。大多数 RESTful API 通过路径参数标识要删除的资源。
- 通常不需要
body，也不建议传（部分服务端可能忽略或报错） - 如有认证需求（如 token），仍需在
headers中携带（如Authorization） - 注意：DELETE 是幂等操作，重复调用结果一致（资源不存在时返回 404 或 204 均属合理）
示例：
fetch('/api/comments/88', {
method: 'DELETE',
headers: {
'Authorization': 'Bearer abc123xyz'
}
})
.then(res => {
if (res.ok) {
console.log('删除成功');
} else {
throw new Error(`HTTP ${res.status}`);
}
});
常见注意事项
- CORS 问题：跨域时，浏览器会先发 OPTIONS 预检请求。确保后端正确响应预检（允许对应 method 和 headers）
-
错误处理别只靠
catch：fetch只在网络失败时 reject；HTTP 错误码（如 404、500）仍会进入then，需手动检查res.ok或res.status -
避免空 body 的 PUT/DELETE 被拦截：某些代理或旧版服务器对无 body 的 PUT 敏感，若必须空体，可显式传
body: null或留空字符串（但 DELETE 更推荐完全省略body）
