真正意义上的，GET请求和POST请求的区别

让我们来看一看大众意义上的区别

GET	POST
后退按钮/刷新无害	数据会被重新提交(浏览器应该告知用户数据会被重新提交)
书签可收藏	书签不可收藏
能被缓存	不能缓存
编码类型application/x-www-form-url	编码类型encodedapplication/x-www-form-urlencoded 或 multipart/form-data,为二进制数据使用多重编码
历史参数保留在浏览器历史中	参数不会保存在浏览器历史中
对数据长度有限制，当发送数据时，GET 方法向 URL 添加数据	无限制
只允许 ASCII 字符	没有限制
安全性较差，因为所发送的数据是 URL 的一部分	数据不会显示在 URL 中

以上大部分都是错误的

GET	POST
GET和POST本质上就是TCP链接，并无差别。但是由于HTTP的规定和浏览器/服务器的限制，导致他们在应用过程中体现出一些不同。	GET和POST本质上就是TCP链接，并无差别。但是由于HTTP的规定和浏览器/服务器的限制，导致他们在应用过程中体现出一些不同。
GET产生一个TCP数据包(对于GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200（返回数据）； )	POST产生两个TCP数据包(而对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据）)

这样就结束了么

GET	POST
安全的	不安全的
幂等的	不幂等的
可缓存的	不可缓存的

Safe-安全
这里的「安全」和通常理解的「安全」意义不同，如果一个方法的语义在本质上是「只读」的，那么这个方法就是安全的。客户端向服务端的资源发起的请求如果使用了是安全的方法，就不应该引起服务端任何的状态变化，因此也是无害的。 此RFC定义，GET, HEAD, OPTIONS 和 TRACE 这几个方法是安全的。但是这个定义只是规范，并不能保证方法的实现也是安全的，服务端的实现可能会不符合方法语义，正如上文说过的使用GET修改用户信息的情况。引入安全这个概念的目的是为了方便网络爬虫和缓存，以免调用或者缓存某些不安全方法时引起某些意外的后果。User Agent（浏览器）应该在执行安全和不安全方法时做出区分对待，并给用户以提示。
Idempotent-幂等
幂等的概念是指同一个请求方法执行多次和仅执行一次的效果完全相同。按照RFC规范，PUT，DELETE和安全方法都是幂等的。同样，这也仅仅是规范，服务端实现是否幂等是无法确保的。引入幂等主要是为了处理同一个请求重复发送的情况，比如在请求响应前失去连接，如果方法是幂等的，就可以放心地重发一次请求。这也是浏览器在后退/刷新时遇到POST会给用户提示的原因：POST语义不是幂等的，重复请求可能会带来意想不到的后果。
Cacheable-可缓存性
顾名思义就是一个方法是否可以被缓存，此RFC里GET，HEAD和某些情况下的POST都是可缓存的，但是绝大多数的浏览器的实现里仅仅支持GET和HEAD。关于缓存的更多内容可以去看RFC7234。