缘起

为什么突然要思考这个问题呢，原因在于之前并没有做过相对完整或者说工程化的东西，做的更多的是自己的或者说团队内部用的东西，更多的实现功能，并非实现这些周边的东西。所以，当我真正考虑到做前后端分离验证码验证方案的时候，我居然一瞬间蒙圈了。没有任何思路让我下手，问题就是如何判定请求过来的东西跟后端相匹配的呢。

疯狂思考方案

要不继续用session + cookie 的方式做，后端生成一个 sessionId，传递到前端，前端存储 cookie 。后端根据session 生成验证码保存，前端提交的时候带着 cookie 进行提交。这是一个方案，但是与目前设计不符了。因为目前的设计是采用 jwt 。如果这两个东西混合用，后面可能就容易乱了。

既然如此，我还想到了一个加密方案，就是把前端的 request 特征生成一个 key，来进行存储。但是不论我怎么想都有问题，因为变数太多。

柳暗花明

既然前端变数这么多，那么我用后端的方式考虑呢，有什么办法可以模拟一个类似于 session cookie 的场景呢。在昨晚临睡前，躺床上忘记跟我媳妇说什么了，突然就让我想明白了。我是不是可以在生成图片的时候也生成一个 key。把图片的base64 和这个 key 一起传递到前端去。前端提交的时候带着这个key 就可以了，不需要知道前后端都是谁，唯一的标识就是这个key，这个key也不用保证一个机器唯一，每次请求新图片的时候也生成一个key 就可以了。不过这里还是带来一个问题。就是后端要清理过期 key 的问题，不过这个问题就好解决了。写个定时器就可以了。

在刚才写这篇文章之前，我也查了一下网上的解决方案，发现大家的思路都一致，都是生成个key。这个key还有一个好听的名字，uuid。

总结

遇到问题不要慌，冷静想想就能解决了。