咱们今天不聊那些枯燥的定义，直接切入正题。在Web开发的江湖里，HTTP请求方法就像是不同的“快递服务”。你寄信、寄包裹、寄易碎品，用的包装方式和处理流程都不一样。GET、POST、PUT、DELETE，这四位选手就是前端与后端沟通时的四大金刚。很多刚入行的朋友容易把它们搞混，尤其是PUT和PATCH，或者GET和POST的界限模糊。别急，我会用最生活化的例子，配合真实的代码场景，帮你把这事儿彻底理清楚。哪怕你是想教家里的小朋友理解网络请求，这套逻辑也能让他们听得津津有味。

GET：只看不摸的“查询员”

首先登场的是GET。你可以把它想象成图书馆里的借阅目录查询系统。你去查一本书，只是看看它有没有、在哪里，并不会把书拿走或者改变它的状态。

核心特征

  1. 幂等性：无论你点多少次刷新，或者发多少次相同的GET请求，结果都是一样的，服务器上的数据不会发生任何改变。
  2. 参数可见：请求参数通常拼在URL后面，比如 ?id=1001。这意味着它会被记录在浏览器历史、服务器日志甚至代理服务器的日志中。
  3. 长度限制：因为参数在URL里，而URL长度是有限制的（虽然现代浏览器放宽了限制，但HTTP协议本身对URI长度有隐含约束），所以不适合传输大量数据。

实际场景：搜索商品

假设你在做一个电商网站，用户输入“蓝牙耳机”，前端需要去后台找所有匹配的商品。这时候就该用GET了。

// 使用 fetch API 发送 GET 请求
const searchQuery = '蓝牙耳机';
const url = `/api/products/search?keyword=${encodeURIComponent(searchQuery)}&page=1`;

fetch(url, {
    method: 'GET',
    headers: {
        'Accept': 'application/json'
    }
})
.then(response => response.json())
.then(data => {
    console.log('搜索结果:', data);
    // 在这里渲染页面，显示耳机列表
    renderProductList(data.products);
})
.catch(error => {
    console.error('查找失败:', error);
});

给小朋友的解释：这就好比你去书店问：“请问有《哈利波特》吗？”店员查了一下告诉你“有，在三楼”。你并没有把书买走，也没有改变书店的库存，只是获取了一个信息。下次你再问同样的问题，店员还是会告诉你同样的答案。

注意事项

  • 永远不要用GET来提交敏感信息（如密码），因为URL明文可见。
  • 如果数据量很大，或者包含特殊字符，记得做URL编码，就像上面的 encodeURIComponent 那样。

POST：大力出奇迹的“搬运工”

如果说GET是轻声细语的查询，那POST就是扛着大包小包进门的搬运工。它的主要任务是向服务器提交数据，并期望服务器产生某种副作用（比如创建新资源）。

核心特征

  1. 非幂等性：多次发送相同的POST请求，可能会创建多个相同的资源。比如你连续点击“提交订单”十次，可能会生成十个订单（除非后端做了防重处理）。
  2. 数据隐蔽：请求体（Body）放在HTTP消息的主体部分，不会出现在URL中，因此更安全，容量也更大。
  3. 内容类型多样：可以发送JSON、表单数据、文件流等多种格式。

实际场景：注册新用户

当用户在网页上填写用户名、邮箱和密码，点击“注册”按钮时，这就是一个典型的POST请求。

const newUser = {
    username: 'xiaoming',
    email: 'xiaoming@example.com',
    password: 'securePassword123!' // 注意：实际生产中密码应在前端加密或仅通过HTTPS传输
};

fetch('/api/users/register', {
    method: 'POST',
    headers: {
        'Content-Type': 'application/json', // 告诉后端我们发的是JSON
        'Accept': 'application/json'
    },
    body: JSON.stringify(newUser) // 将对象转换为字符串
})
.then(response => {
    if (!response.ok) {
        throw new Error('注册失败');
    }
    return response.json();
})
.then(data => {
    console.log('注册成功，用户ID:', data.userId);
    alert('欢迎加入，小明！');
})
.catch(error => {
    console.error('错误:', error);
    alert('注册出错，请稍后再试');
});

给小朋友的解释：这就像是你往邮局的信箱里投一封信。你把信（数据）塞进去，邮局（服务器）收到后，会按照信里的地址进行处理（比如存到档案柜里）。如果你再投一封一模一样的信，邮局通常会再存一份新的，而不是覆盖原来的。

为什么不用GET传数据？

有人问：“GET也能带参数啊，为什么不用GET提交表单？” 想象一下，如果你用GET提交密码，URL会变成 login?user=admin&pwd=123。这个链接会被保存在浏览器历史记录里，可能被截屏泄露，甚至被中间的网络运营商记录。POST把数据藏在身体里（Body），外面看不见，安全多了。

PUT：整箱替换的“管理员”

PUT经常让人困惑，因为它听起来像是“增加”，但实际上它是“更新”或“替换”。它的关键在于幂等性——无论你做几次PUT，结果都是一样的。

核心特征

  1. 幂等性：第二次执行PUT /api/users/1 修改名字为“Bob”，和第一次执行的效果完全一样。服务器最终的状态是确定的。
  2. 全量更新：PUT通常要求客户端提供资源的完整表示。如果你想改用户的名字和年龄，你需要把整个用户对象传过去，哪怕你只想改名字。
  3. 资源存在：PUT通常用于更新已存在的资源。如果资源不存在，有些后端设计会报错，有些则会创建（但这取决于具体API设计，有时会用POST）。

实际场景：编辑个人资料

用户在个人中心修改自己的简介、头像和联系方式。

const updatedProfile = {
    id: 101,
    name: 'Alice Wang',
    bio: 'Full-stack developer and coffee lover.',
    avatarUrl: 'https://example.com/alice.jpg',
    contactEmail: 'alice.wang@example.com'
    // 即使只想改bio，通常也需要传回整个对象，或者后端支持部分字段忽略
};

fetch('/api/users/101', {
    method: 'PUT',
    headers: {
        'Content-Type': 'application/json'
    },
    body: JSON.stringify(updatedProfile)
})
.then(response => response.json())
.then(data => {
    console.log('资料已完整更新:', data);
});

给小朋友的解释：这就像是你有一张名片，上面写着“张三，工程师”。现在你要把这张名片换掉。你拿出一张全新的名片，上面写着“李四，设计师”。你把旧的名片扔掉，换上新的。不管你怎么换，最后桌子上只有一张名片。如果你再换一次，还是换成“李四，设计师”，桌子上的名片还是那张，没变。这就是“幂等”。

PUT vs PATCH

这是面试常考题。

  • PUT：我要把整个资源替换成我给你的这个样貌。
  • PATCH：我只想在原有基础上，修改几个字段。比如只改名字，其他不动。

DELETE：干脆利落的“清道夫”

DELETE的作用显而易见：删除资源。它也是幂等的。删除一次后，资源没了；再删一次，资源还是没了（可能会返回404，但状态是一致的）。

核心特征

  1. 幂等性：删除操作的结果是稳定的。
  2. 无请求体：通常DELETE请求不需要Body，资源标识符通过URL传递。
  3. 风险性：删除是不可逆的（除非有备份），所以要谨慎使用。

实际场景：注销账号或删除帖子

用户在设置页点击“永久删除我的账户”，或者博主删除了一篇过时的文章。

const userIdToDelete = 101;

fetch(`/api/users/${userIdToDelete}`, {
    method: 'DELETE',
    headers: {
        'Authorization': 'Bearer <token>' // 通常需要身份验证
    }
})
.then(response => {
    if (response.status === 204) { // 204 No Content 表示成功删除且无返回数据
        console.log('账户已删除');
        window.location.href = '/login'; // 跳转到登录页
    } else {
        throw new Error('删除失败');
    }
})
.catch(error => {
    console.error('删除出错:', error);
});

给小朋友的解释：这就像是你把纸上的画擦掉了。擦一次，画没了；再擦一次，画还是没了。你不能擦出另一张不同的画来，只能确认它不存在。

深度对比：一张表看懂区别

为了让你记忆更深刻，我们把这四个方法放在一起PK：

特性 GET POST PUT DELETE
主要目的 读取/查询数据 创建新数据 更新/替换现有数据 删除数据
参数位置 URL Query String Request Body Request Body URL Path (通常)
安全性 低 (URL可见) 中 (Body隐藏) 中 (Body隐藏) 中 (Body隐藏)
幂等性 ✅ 是 ❌ 否 ✅ 是 ✅ 是
数据大小 受限 (URL长度) 无限制 (受限于服务器配置) 无限制 通常较小
缓存 可被浏览器缓存 通常不被缓存 通常不被缓存 通常不被缓存
典型HTTP状态码 200 OK 201 Created 200 OK / 204 No Content 204 No Content / 200 OK

常见误区与最佳实践

1. “我用POST能不能实现GET的功能？”

技术上可以，但不推荐。RESTful API的设计哲学是使用不同的动词来表达不同的意图。如果用POST做查询，会导致无法利用浏览器的缓存机制，也会让API语义混乱。记住：查询用GET，增删改用POST/PUT/DELETE。

2. “PUT一定要传所有字段吗？”

这取决于后端的设计。严格来说，PUT是替换整个资源，所以应该传所有字段。但在实际工程中，为了灵活性，很多团队会使用 PATCH 来进行部分更新。如果你的后端不支持PATCH，又只想更新一个字段，你可能需要先把当前数据GET下来，修改后再PUT回去。这是一种常见的 workaround（变通方案）。

3. “DELETE真的能物理删除吗？”

在生产环境中，直接物理删除数据是非常危险的。通常的做法是“软删除”，即给数据加一个 is_deleted 标记，或者移动到回收站。对应的API可能仍然是DELETE，但后端逻辑是更新状态而非物理删除。前端调用时无需关心内部细节，但开发者要明白这一点。

4. 跨域问题（CORS）

在使用这些方法时，尤其是POST、PUT、DELETE，如果涉及复杂请求（如自定义Header、JSON Body），浏览器会先发一个 OPTIONS 预检请求。确保你的后端服务器正确配置了CORS头，允许这些方法。

# Nginx 示例配置，允许常用方法
location /api/ {
    if ($request_method = 'OPTIONS') {
        add_header 'Access-Control-Allow-Origin' '*';
        add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT, DELETE, OPTIONS';
        add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range,Authorization';
        add_header 'Access-Control-Max-Age' 1728000;
        add_header 'Content-Type' 'text/plain; charset=utf-8';
        add_header 'Content-Length' 0;
        return 204;
    }
    # 正常请求处理...
}

总结：如何像专家一样选择？

当你面对一个新的业务需求时，问自己三个问题：

  1. 我要改变服务器上的数据吗？
    • 不改，只是看 -> GET
    • 要改 -> 继续问
  2. 我是创建新东西，还是修改已有的东西？
    • 创建新东西（如注册、发帖） -> POST
    • 修改已有东西 -> 继续问
  3. 我是全量替换，还是局部修改？
    • 全量替换（或不确定） -> PUT
    • 局部修改 -> PATCH (如果后端支持)
    • 移除东西 -> DELETE

掌握了这些，你就不仅仅是在写代码，而是在设计一种清晰的通信契约。这种契约能让你的前端同事、后端同事，甚至未来的你自己，都能一眼看懂这段请求的意图。

希望这篇详解能帮你彻底理清AJAX请求方法的门道。如果有具体的业务场景拿不准，随时可以把代码片段发出来，我们一起分析。毕竟，最好的学习就是解决实际问题。