登录注册页面，录注用户点一下按钮，册仿网络请求还没回来，刷机手指又连点三下。录注结果呢？册仿要么重复注册，要么重复提交，刷机后台数据库里躺着几条一模一样的录注记录。这在真实项目里太常见了，册仿尤其在小团队、刷机没做接口幂等性设计的录注后端面前，简直是册仿灾难。

Android端的刷机“仿刷”机制，本质就一句话：把用户的录注重复操作，在前端就掐死。册仿别指望用户自觉，刷机也别指望后端每次都能帮你兜底。前端能挡住80%的无效请求，后端压力小一半，数据也干净。

最粗暴的做法是“按钮置灰”。点击后立刻把按钮设为不可用，等接口返回再恢复。但这里有个坑：如果网络慢，用户盯着灰按钮等三秒，心里会骂娘。更麻烦的是，如果接口异常直接走onError，按钮没恢复，用户就被卡死了。所以置灰必须配超时控制，比如5秒强制恢复，哪怕请求还没回来也要恢复——用户体验优先于防刷。

另一种常见方案是“时间戳拦截”。记录上次点击的System.currentTimeMillis()，如果间隔小于800毫秒，直接忽略这次点击。这个方案有个细节很多人忽略：时间戳要放在Activity或Fragment的成员变量里，别放局部变量。放局部变量等于没放，每次方法调用都重新初始化，拦截逻辑直接失效。我见过线上bug就是这么来的，开发者把时间戳写在onClick方法内，结果防刷形同虚设。

再进阶一点，用RxBinding或LiveData做“节流阀”。比如RxBinding的throttleFirst(1, TimeUnit.SECONDS)，它能在事件流层面过滤掉1秒内的重复点击。好处是不用自己管理时间戳，代码更简洁。坏处是引入额外依赖，而且如果项目里没用RxJava，为了这一个功能加整套库，不划算。

还有个细节容易被忽视——双击后显示加载动画。别光拦截点击，得给用户反馈。弹一个ProgressDialog，或者按钮上转菊花，让用户知道“我在干活，别急”。这不算防刷机制本身，但配合防刷用，体验会好很多。用户看到加载状态，自然不会再点第二次，防刷压力更小。

实际项目里，我见过最狠的做法是“登录请求串行化”。用一个boolean标志位，如果上一个请求还在进行中，新的登录请求直接return。等上一个请求结束（成功或失败），再重置标志位。这比单纯的时间戳更可靠，因为时间戳只能防“快速连点”，挡不住“网络慢导致用户等不及又点了一次”的情况。标志位直接从状态层面杜绝并发请求。

但标志位有个隐患：如果请求卡死，比如超时时间设太长，标志位一直不重置，用户就永远登不上。所以必须配合超时机制，或者用CountDownLatch做超时重置。说到底，防刷逻辑再完美，也得考虑异常场景。毕竟用户手机可能杀进程，可能断网重连，任何状态都可能被破坏。

最后说个反直觉的观察：防刷机制写太复杂，反而容易出bug。有的项目搞了个防刷策略类，里面一堆策略模式、状态机，最后发现连开发自己都搞不清哪个策略生效了。登录注册这种高频操作，防刷代码越简单越可靠。一个boolean标志位，加一个时间戳，再加一个按钮置灰，三层防御足够了。复杂方案留给支付、下单这种高风险场景，登录注册真没必要。

对了，还有种情况：用户不是手滑，是故意刷。比如用脚本自动注册。这种前端防刷根本挡不住，得上验证码、设备指纹、服务端限流。所以别指望前端解决所有问题，前端防的是“手滑”，后端防的才是“恶意”。分清楚这个，你的防刷设计就不会跑偏。

(责任编辑：探索)