ps 最近和后端在交流关于幂等性的处理，本来以为表单提交之前只有前端需要做处理，原来后台post本来不具备幂等性，为了防重复创建后台这边会加一些优化来防止一些关键数据的重复创建
- 锁（redis）
- 数据库的“唯一索引”
基于对http幂等性的理解
所谓的幂等性，相同的请求执行多次和执行一次的副作用是一样的;我的理解就是客户端的重复提交请求，而后端只处理一次。
- GET请求是幂等的，多次的GET请求，不应该修改数据状态，只是查询
- Delete请求也具有幂等性，执行一次请求，删除id=1的记录，多次请求与一次请求的结果应该是一样的，最终的结果都是把id=1的记录删除。
- Post 因为每次调用都会生在后台新建资源，所以 POST不是幂等性的。
- Put 它直接把数据替换到服务器资源，多次调用它，对服务器的资源影响是相同的。 所以PUT是幂等性的。
- PATCH 请求会执行某个程序，如果重复提交，可能(注意是可能)对服务器的资源造成不同的影响。PATCH有可能是根据客户端提供的参数或者指令，动态的计算出某个值，例如每次请求后资源的某个参数减1，所以多次调用，资源会有不同的变化。所以PATCH是非幂等的
PUT 和PATCH
根据约定( Convention )，PUT 方法用于更新数据，PATCH 方法也用于更新数据，为什么 PUT 方法是幂等的而 PATCH 方法不是幂等的呢？
- PUT 用做更新操作的时候是提交一整个更新后的实体，而不是需要修改的实体中的部分属性。当 URI 指向一个存在的资源，服务器要做的事就是查找并替换。
- PATCH 请求中的实体保存的是修改资源的指令，该指令指导服务器来对资源做出修改，所以不是幂等的。
打个比方：对于存在服务器中的 A 对象有个属性 B 为 1，如果要修改 B 属性为 3，则 PUT 请求是直接将修改过 B 属性的整个新对象发送给服务器查找并替换。而 PATCH 请求是在实体中包含指令 --- 将 A 对象中 B 属性的值加 2，那么如果该请求被执行多次的话，B 属性就可能不为 3 了，而 PUT 请求不论执行多少次，B 属性永远都是 3，所以说 PUT 方法是幂等的，而 PATCH 方法不是幂等的。