这个问题由来以及，只是最近工作再次发现这个问题世纪工作中还遇到的挺多。 之前在做前端的时候，经常遇到一个问题，在点击提交按钮的时候，或是因为接口调用时间过长，或是由于网络波动，亦或是只是遇到一个没有什么耐心的客户，他不仅仅点了一次提交按钮，你要是不快点把结果页面展示出来，他能给你把按钮点烂。 那么在极短的时间里，接受了多次提交请求，你的数据还能保持正确吗？这就是幂等性接口需要面对的问题。 百度百科：在编程中一个幂等操作的特点是，其任意多次执行所产生的影响均与一次执行的影响相同。 对于工作中最常见的增删改查操作，查询和删除一般可以直接认为是幂等的，因为无论查多少次，无论删除多少次，数据都不会产生不一致。而修改和增加则会因为一些操作而产生不一致行。比如修改是处于一个循环+1的场景下，数据库表就有可能产生不一致，这和Java多线程的情况下如何保持操作的原子性颇有类似。而增加的场景就如，支付插入表数据，一次支付本来只应该扣一次款，插入一条流水记录，但是非幂等接口，有可能造成多条记录多次扣款。 防止数据不一致一般有两种方式，通过代码逻辑判断，通过token机制。 比如支付时代码判断该订单Id的支付状态位是否已经改变，从而决定是否插入下一次支付流水记录。 token的相关表述博主准备后续深入学习一下，这里先引用百度的东西： token机制实现步骤: 1. 生成全局唯一的token,token放到redis或jvm内存,token会在页面跳转时获取.存放到pageScope中,支付请求提交先获取token 2. 提交后后台校验token，执行提交逻辑,提交成功同时删除token，生成新的token更新redis ,这样当第一次提交后token更新了,页面再次提交携带的token是已删除的token后台验证会失败不让提交
token特点： 要申请，一次有效性，可以限流 注意： redis要用删除操作来判断token，删除成功代表token校验通过，如果用select+delete来校验token，存在并发问题，不建议使用