HTTP协议里，两种GET和POST是请求两种最常用的请求方法，但它们的两种区别远不止“GET传参在URL里，POST在请求体里”这么简单。请求一个最直观的两种例子：你在浏览器地址栏输入网址并回车，那一定是请求GET请求——页面刷新、书签收藏、两种链接分享，请求全都依赖GET的两种“幂等”特性。而提交一个表单，请求比如登录、两种注册、请求支付，两种那通常是请求POST，因为你会希望这次操作产生“副作用”，两种比如在服务器上创建一条订单记录。

GET请求的参数会暴露在URL中，这既是它的软肋，也是它的特点。假如你通过GET提交密码，那密码会直接出现在浏览器历史、服务器日志、甚至路由器缓存里——这几乎等于把密码写在便利贴上贴在电脑屏幕前。但换个场景，比如搜索“Python教程”，你反而希望参数能留在URL里，这样你可以把链接发给朋友，对方点开就能看到同样的搜索结果。这种可共享、可收藏的特性，是POST做不到的。

POST请求则把参数藏在请求体里，URL只保留路径，看起来干净不少。但这不意味着POST天生更安全——它只是不把数据暴露在URL上，如果不用HTTPS，请求体照样会被抓包工具一览无余。真正让POST更可靠的是它的语义：它告诉服务器“我要修改数据，请处理”，而不是“我要获取数据，请给我”。所以，删除一条记录、更新一条记录、上传一个文件，这些操作都该用POST，哪怕你只是传一个ID。

还有个常被忽略的细节：GET请求在浏览器里是有长度限制的，虽然HTTP协议本身没规定，但服务器和浏览器都有实际限制，比如老版IE限制在2083个字符左右。这意味着你想通过GET传一大段文本，比如一篇文章的内容，大概率会被截断报错。POST则没有这种限制，请求体的大小只受服务器配置约束，上传几MB的文件都没问题。我见过不少新手在写搜索接口时，把筛选条件全塞进GET参数，结果条件一多，URL长得像乱码，还时不时报错——这时候就该换成POST，但很多人又嫌POST不能分享链接，其实折中方案也有，比如把筛选条件压缩成短码放在URL里，但那是另一个话题了。

还有一点，GET请求是“可缓存的”，浏览器会把GET响应存下来，下次访问相同URL时直接读缓存，省去网络请求。POST则默认不缓存，每次都得重新请求。这直接影响了性能：一个图片列表页用GET，第二次打开可能瞬间加载；如果用POST，每次都得等服务器返回。反过来，POST请求可以支持“部分更新”，比如只提交一个字段，而GET通常是完整响应——虽然这更多是设计习惯，但确实影响了接口风格。

最后说个实际观察：很多开发者把GET和POST当成“传参方式”来选，而不是按语义来选。结果就是，有人用GET去删除数据，导致爬虫抓到链接就触发删除；有人用POST做纯查询，浪费了缓存和分享能力。我的建议很简单——如果操作不改变服务器状态，用GET；如果会改变状态，用POST。别管参数多长、数据多敏感，先想清楚这个请求是“读”还是“写”。读用GET，写用POST，这个原则能省掉你后续一大半的调试麻烦。