最近琢磨一下我们项目里的请求方式，特别是这个 GET 方法，真是让人又爱又恨。以前也没太在意，但后来碰到的事儿多，就觉得这 GET 方法有时候真是个坑。
为啥要这么干？
你看那长长的网址后面，带一大串东西，啥玩意儿都可能在里面。一开始觉得方便，调试起来直接看地址栏就行。但后来发现，这玩意儿太不安全。
特别是搞登录、传些个人信息啥的，比如用户的身份标识、一些敏感的号码，就这么明晃晃地挂在地址栏，谁都能看见。随便哪个环节，比如浏览器历史、服务器日志，甚至就是旁边路过的人瞄一眼，都可能漏出去。你想想，这多吓人。
而且GET 请求很容易被缓存，有些代理服务器也会记下来。要是传的是些不该记的东西，那风险就更大。还有就是，这 URL 长度也是有限制的，传的东西多也不方便。
因为这些原因，我就觉得，不能再随便用 GET ，尤其是在处理一些关键数据的时候。
具体咋弄的？
后来我就下决心，在咱们自己做东西的时候，得立个规矩：凡是涉及到用户隐私、密码、或者一些重要的业务数据，一律不准用 GET。你想提交数据、修改状态，那就老老实实用 POST 或者其他更合适的方法。
这事儿我也跟团队里的人叨叨过好几次。有些人图省事，或者没意识到风险，还是习惯用 GET。我就得一遍遍说，举例子，有时候还得在代码审查的时候给指出来，强制改掉。
是强调安全意识，让大家都知道 GET 的风险在哪儿。
然后就是在制定接口规范的时候，明确规定哪些场景绝对不能用 GET。
再就是在代码审查环节，把这个作为一个检查点，看到不合适的 GET 请求就打回去修改。
有时候，为省事，我们会统一配置一些框架层面的东西，看能不能从根上限制一下，不过这个得看具体技术栈，有时候也不是那么容易。
主要还是靠大家的自觉和互相监督。形成习惯就好。
的效果
现在基本上大家都有这个意识，敏感操作自然就用 POST 或者其他更安全的方法。虽然不能说百分百杜绝所有问题，但至少把这个明显的口子给堵上，心里能踏实不少。
禁止 GET 方法在某些场景下的调用，算是我实践中一个挺重要的安全习惯。毕竟做开发，不光是实现功能，安全这根弦，得时刻绷紧。一点小小的改动，可能就避免一个大窟窿。