今天在使用招商银行的【掌上生活】app时，碰到这样一个情况，某个业务场景，需要输入手机号，填写下发的验证码。或许是网络原因，验证码几分钟没到，作为用户，肯定会多按几次，这是非常正常的操作行为。然而，坑爹的事情发生了，试了两三次，几分钟过去了，在某次请求后，验证码来了，但输入后是错的，大概过了30秒，又来了一条，我再次输入，还是错的。使用返回再进入，又重新获取了一次，来信息了，但还是错的，瞬间心好累。
为什么会出现这个情况？因为他们的验证码下发机制没有考虑到一些特殊场景，例如网络延误，短时间内多次下发的输入等。他们的机制很简单，就是请求一次，生成一个不一样的验证码，需要输入最新的，或许有最大下发次数保护机制，这个是另外的话题，这里不发散说。然而，不知道是哪边服务器的原因，延误的验证码不是连续来，而是隔十几秒来一个，还要让人在当前页面等到最新的验证码进行输入才是正确的，想到就心好累。
这里就引出了一个问题：验证码的下发是否应该使用相同的验证码？
在一定时间内（10-30分钟），向同一个手机号下发相同的验证码会比较好，超过一定时间，下发不同的验证码。这样在短时间内，用户看到多个相同的验证码，不会出现疑虑，对需要输入的验证码非常明确，若短时间内的验证码不同，就会产生“哪个才是我需要输入的？”这个疑问烦恼，可能产生多次输入的试错成本。
那么，如果在迭代需求中，需要描述这个功能，怎么说比较好呢？
用户发起一个验证码请求时，去库里查该账号/ID最近一次下发验证码和下发时间，若在30分钟内，则把该验证码再下发一次，并进行记录（30分钟是否需要重新计时，根据各个业务的情况自行调整，没有标准答案），若是超过30分钟，则重新生成新的验证码进行下发。
小结
虽然只是一个触发验证码的动作，里面也涉及到很多小细节，这里主要是讲述的是验证码多次下发的使用场景。在整个流程当中，其实还涉及什么时候触发下发请求的相关问题，倒计时控制连续下发验证码的时间问题，每个功能都需要多思考，尽可能的严谨和人性化，这些细节不一定能让产品带来飞跃性的成功，但肯定能提高产品的下限。