post 相比get 有很多优点，为什么现在的HTTP通信中大多数请求还是使用get？
Post 相比 Get 有很多优点，比如数据安全性更高、传输数据量更大、可以传输任意类型的数据等等。按理说，在需要发送敏感信息或大量数据时，我们应该优先选择 Post 请求。那么，为什么在日常的 HTTP 通信中，我们仍然看到绝大多数请求是 Get 请求呢？这背后其实有几个非常现实和重要的原因。
首先，我们需要明确 Get 和 Post 这两种 HTTP 方法最核心的设计理念和应用场景。
GET 方法： 从字面意思理解，GET 就是“获取”。它的主要目的是从服务器上检索（读取）数据。当你在浏览器地址栏输入一个网址并回车，或者点击一个链接时，你实际上就是在向服务器发送一个 GET 请求，告诉服务器“我想获取这个 URL 对应的资源”。
POST 方法： POST 的含义更像是“提交”或“发送”。它的主要目的是向服务器发送数据，通常是为了创建新的资源，或者修改服务器上已有的资源。比如你在网站上填写一个注册表单，或者上传一张图片，这些操作背后通常是 POST 请求。
那么，为什么看起来 Post 更强大、更灵活，用得却不如 Get 广泛呢？主要有以下几个原因：
1. 语义化和设计初衷：
HTTP 协议的设计者最初就把 GET 定义为“安全且幂等”的方法。
安全（Safe）： 指的是 GET 请求不会对服务器上的数据产生副作用（side effect）。也就是说，发送一个 GET 请求不应该改变服务器的状态。你每次请求同一个 URL，服务器上的数据都应该是相同的（除非其他原因导致数据变化，但不是你的 GET 请求本身引起的）。这就像你去图书馆借书，你只是拿走了书，并没有改变书本的内容或让它消失。
幂等（Idempotent）： 指的是同一个请求，无论执行多少次，服务器上的状态都不会发生改变。发送一次 GET 请求获取数据，和发送一百次 GET 请求获取数据，结果应该是一样的，服务器的状态不变。
POST 请求则不具备这两个特性。POST 请求可以改变服务器的状态（例如，创建新用户），并且多次发送同一个 POST 请求可能会产生不同的结果（例如，多次提交同一个订单，可能会生成多个订单）。
为什么这会影响使用频率？
浏览器和中间件（如缓存服务器、代理服务器）在处理 HTTP 请求时，会根据请求方法的语义进行优化。
缓存： 缓存机制主要针对 GET 请求。因为 GET 请求是获取数据的，并且是幂等的，所以服务器可以将响应缓存起来。当用户再次请求相同的数据时，浏览器可以直接从缓存中读取，速度更快，也减轻了服务器的压力。如果 POST 请求也能被缓存，那么缓存的数据就可能不是最新的，甚至可能导致数据错误。
可重试性： 由于 GET 是安全的、幂等的，浏览器或网络基础设施在遇到网络问题时，可能会尝试重新发送 GET 请求，而不会担心产生不良后果。而对于 POST 请求，自动重试就非常危险，因为它可能导致意外的数据创建或修改。
地址栏和书签： GET 请求的参数会直接附加在 URL 后面，这使得 URL 本身就包含了请求的所有信息。你可以方便地将这些带有参数的 URL 复制、分享、添加到书签，或者在地址栏直接输入。而 POST 请求的数据是放在请求体中的，无法通过 URL 直接看到和传递。
2. URL 的限制和易用性：
虽然说 POST 可以传输大数据，但 GET 方法在实际应用中，其参数传递方式也决定了它的主要用途。
URL 长度限制： 浏览器和服务器对 URL 的长度都有一定的限制（虽然这个限制通常很大，但不是无限的）。这意味着 GET 请求能携带的参数量是有限的。因此，GET 主要适用于传递少量、简单的数据，比如查询条件（如 `?id=123&page=2`）。
易于理解和调试： 对于前端开发者来说，通过 URL 参数传递数据直观易懂，也更容易在浏览器开发者工具中查看和调试。
3. 很多操作本质上就是“获取”：
我们日常的网络浏览，大部分时间都在“获取”信息。
浏览网页： 加载 HTML、CSS、JavaScript 文件、图片、视频等，都是 GET 请求。
搜索： 输入搜索词，然后提交，本质上是告诉服务器“我想获取包含这些关键词的结果”，这也是 GET 请求（虽然有时为了简洁，一些搜索引擎也会用 POST）。
API 调用： 调用很多只读型 API，比如获取用户信息、产品列表、文章详情等，都应该使用 GET。
什么时候我们“必须”或“更应该”使用 POST？
尽管 GET 请求如此普遍，但当涉及到以下情况时，POST 方法是不可替代或更优的选择：
发送敏感数据： 密码、银行卡信息等不应该出现在 URL 中，POST 将这些数据放在请求体中，比 GET 更安全（但请注意，这只是相对的，HTTPS 才是加密传输的根本保障）。
传输大量数据： 比如上传文件、提交大量表单数据，这些数据量可能远超 URL 的长度限制。
修改服务器状态： 任何会改变服务器数据（创建、更新、删除）的操作，都应该使用 POST（或 PUT、DELETE 等方法），而不是 GET。因为 GET 的语义不允许修改服务器状态。
发送复杂数据结构： 比如 JSON、XML 等格式的数据，放在请求体中传输更方便。
总结一下：
虽然 POST 在某些方面（如数据安全性和传输量）有着明显的优势，但 GET 请求之所以在绝大多数 HTTP 通信中占据主导地位，主要是因为：
1. 语义化和设计初衷： GET 是设计用来“获取”数据，并且被定义为安全、幂等的，这使得它能被浏览器和中间件有效地缓存和重试，极大地提高了效率和用户体验。
2. URL 的易用性： GET 参数附加在 URL 上，方便分享、书签和调试。
3. 多数网络操作的本质： 大部分网络交互是读取信息，这天然符合 GET 的用途。
可以理解为，GET 方法更像是一种“轻便、通用的信息查询工具”，而 POST 方法更像是一种“具有特定目的、需要谨慎处理的数据提交工具”。在没有明确需要修改服务器状态或传输敏感/大量数据时，使用 GET 是更符合 HTTP 协议设计理念、也更高效的选择。我们应该根据操作的性质来选择合适的 HTTP 方法，而不是盲目追求某一种方法的“强大”。
首先，我们需要明确 Get 和 Post 这两种 HTTP 方法最核心的设计理念和应用场景。
GET 方法： 从字面意思理解，GET 就是“获取”。它的主要目的是从服务器上检索（读取）数据。当你在浏览器地址栏输入一个网址并回车，或者点击一个链接时，你实际上就是在向服务器发送一个 GET 请求，告诉服务器“我想获取这个 URL 对应的资源”。
POST 方法： POST 的含义更像是“提交”或“发送”。它的主要目的是向服务器发送数据，通常是为了创建新的资源，或者修改服务器上已有的资源。比如你在网站上填写一个注册表单，或者上传一张图片，这些操作背后通常是 POST 请求。
那么，为什么看起来 Post 更强大、更灵活，用得却不如 Get 广泛呢？主要有以下几个原因：
1. 语义化和设计初衷：
HTTP 协议的设计者最初就把 GET 定义为“安全且幂等”的方法。
安全（Safe）： 指的是 GET 请求不会对服务器上的数据产生副作用（side effect）。也就是说，发送一个 GET 请求不应该改变服务器的状态。你每次请求同一个 URL，服务器上的数据都应该是相同的（除非其他原因导致数据变化，但不是你的 GET 请求本身引起的）。这就像你去图书馆借书，你只是拿走了书，并没有改变书本的内容或让它消失。
幂等（Idempotent）： 指的是同一个请求，无论执行多少次，服务器上的状态都不会发生改变。发送一次 GET 请求获取数据，和发送一百次 GET 请求获取数据，结果应该是一样的，服务器的状态不变。
POST 请求则不具备这两个特性。POST 请求可以改变服务器的状态（例如，创建新用户），并且多次发送同一个 POST 请求可能会产生不同的结果（例如，多次提交同一个订单，可能会生成多个订单）。
为什么这会影响使用频率？
浏览器和中间件（如缓存服务器、代理服务器）在处理 HTTP 请求时，会根据请求方法的语义进行优化。
缓存： 缓存机制主要针对 GET 请求。因为 GET 请求是获取数据的，并且是幂等的，所以服务器可以将响应缓存起来。当用户再次请求相同的数据时，浏览器可以直接从缓存中读取，速度更快，也减轻了服务器的压力。如果 POST 请求也能被缓存，那么缓存的数据就可能不是最新的，甚至可能导致数据错误。
可重试性： 由于 GET 是安全的、幂等的，浏览器或网络基础设施在遇到网络问题时，可能会尝试重新发送 GET 请求，而不会担心产生不良后果。而对于 POST 请求，自动重试就非常危险，因为它可能导致意外的数据创建或修改。
地址栏和书签： GET 请求的参数会直接附加在 URL 后面，这使得 URL 本身就包含了请求的所有信息。你可以方便地将这些带有参数的 URL 复制、分享、添加到书签，或者在地址栏直接输入。而 POST 请求的数据是放在请求体中的，无法通过 URL 直接看到和传递。
2. URL 的限制和易用性：
虽然说 POST 可以传输大数据，但 GET 方法在实际应用中，其参数传递方式也决定了它的主要用途。
URL 长度限制： 浏览器和服务器对 URL 的长度都有一定的限制（虽然这个限制通常很大，但不是无限的）。这意味着 GET 请求能携带的参数量是有限的。因此，GET 主要适用于传递少量、简单的数据，比如查询条件（如 `?id=123&page=2`）。
易于理解和调试： 对于前端开发者来说，通过 URL 参数传递数据直观易懂，也更容易在浏览器开发者工具中查看和调试。
3. 很多操作本质上就是“获取”：
我们日常的网络浏览，大部分时间都在“获取”信息。
浏览网页： 加载 HTML、CSS、JavaScript 文件、图片、视频等，都是 GET 请求。
搜索： 输入搜索词，然后提交，本质上是告诉服务器“我想获取包含这些关键词的结果”，这也是 GET 请求（虽然有时为了简洁，一些搜索引擎也会用 POST）。
API 调用： 调用很多只读型 API，比如获取用户信息、产品列表、文章详情等，都应该使用 GET。
什么时候我们“必须”或“更应该”使用 POST？
尽管 GET 请求如此普遍，但当涉及到以下情况时，POST 方法是不可替代或更优的选择：
发送敏感数据： 密码、银行卡信息等不应该出现在 URL 中，POST 将这些数据放在请求体中，比 GET 更安全（但请注意，这只是相对的，HTTPS 才是加密传输的根本保障）。
传输大量数据： 比如上传文件、提交大量表单数据，这些数据量可能远超 URL 的长度限制。
修改服务器状态： 任何会改变服务器数据（创建、更新、删除）的操作，都应该使用 POST（或 PUT、DELETE 等方法），而不是 GET。因为 GET 的语义不允许修改服务器状态。
发送复杂数据结构： 比如 JSON、XML 等格式的数据，放在请求体中传输更方便。
总结一下：
虽然 POST 在某些方面（如数据安全性和传输量）有着明显的优势，但 GET 请求之所以在绝大多数 HTTP 通信中占据主导地位，主要是因为：
1. 语义化和设计初衷： GET 是设计用来“获取”数据，并且被定义为安全、幂等的，这使得它能被浏览器和中间件有效地缓存和重试，极大地提高了效率和用户体验。
2. URL 的易用性： GET 参数附加在 URL 上，方便分享、书签和调试。
3. 多数网络操作的本质： 大部分网络交互是读取信息，这天然符合 GET 的用途。
可以理解为，GET 方法更像是一种“轻便、通用的信息查询工具”，而 POST 方法更像是一种“具有特定目的、需要谨慎处理的数据提交工具”。在没有明确需要修改服务器状态或传输敏感/大量数据时，使用 GET 是更符合 HTTP 协议设计理念、也更高效的选择。我们应该根据操作的性质来选择合适的 HTTP 方法，而不是盲目追求某一种方法的“强大”。
网友意见
既然get请求有这么多缺点为什么不抛弃它，反而大量使用呢？ 是因为get更节省资源吗？
类似的话题
本站所有内容均为互联网搜索引擎提供的公开搜索信息，本站不存储任何数据与内容，任何内容与数据均与本站无关，如有需要请联系相关搜索引擎包括但不限于百度，google,bing,sogou 等
© 2025 tinynews.org All Rights Reserved. 百科问答小站 版权所有