哎呀，现在的登录鉴权真的是让人头大！

说实话， 搞开发这么多年，最让我头疼的除了产品经理变需求，就是这该死的用户登录鉴权了！真的，每次看到那些弱密码，什么“123456”啊，“admin”啊，我就想撞墙。这简直是在给黑客送大礼嘛！而且用户也是动不动就忘记密码，然后点“找回密码”，流程长得能绕地球一圈，用户体验差到爆！所以啊，咱们必须得换个思路，短信验证码登录才是王道！配合上腾讯云短信服务，再加上那个快得飞起的Redis，简直就是绝配！今天我就要跟大家唠唠， 怎么把这个，真香！

平安性真的太重要了。我们不能只想着功能实现，还得想着怎么防住那些无处不在的黑客。传统的Session模式在分布式环境下简直就是个噩梦，同步Session？别逗了性能差得要死。所以Token鉴权机制横空出世，拯救了我们这些苦逼的程序员。而Redis， 作为那个基于内存的键值对数据库，它的读写速度快得惊人，简直就是为这种高频访问的场景量身定做的。把验证码和Token扔进Redis里既平安又高效，何乐而不为呢，别纠结...？

为什么我非要选腾讯云短信不可？

市面上做短信服务的厂商一大堆，阿里云、华为云、甚至还有各种不知名的小厂商。为什么我偏偏要选腾讯云呢？其实也没什么特别的原因，就是觉得它稳！真的， 以前用过某家的短信服务，经常延迟，用户等了半天收不到验证码，直接就把APP卸载了那叫一个心痛啊！腾讯云的到达率还是挺高的，而且接入文档虽然写得有点...嗯...一言难尽，但是好歹能看懂。而且它的API调用起来也挺方便的，虽然有时候会报一些莫名其妙的错误，但大部分时间还是靠谱的。

我的看法是... 为了让大家更直观地了解， 我特意做了一个市面上主流短信服务商的对比表格，大家看看就明白了选择腾讯云其实是有道理的，虽然它也不完美。

绝绝子... 看到了吧？虽然价格上没什么优势，但是稳定性和到达率才是王道啊！用户收不到验证码，你做得再花里胡哨也没用。所以听我一句劝，选大厂，准没错！虽然钱包会痛一下但是总比被用户骂强，对吧？

Redis在这个系统里到底扮演了什么角色？

说到Redis，我真的是又要爱又要恨。爱的是它的速度， 恨的是它有时候太吃内存了如果不小心设置了个无限循环的Key，服务器内存瞬间就被爆满，然后...然后你就等着被运维大哥吊打吧。在这个登录鉴权系统里Redis主要干两件事：存验证码和存Token，累并充实着。。

先说说验证码这东西，生命周期短，而且访问频率高。你总不能把验证码存MySQL吧？那MySQL还不被你搞挂了？就算不挂，查询速度也跟不上啊。Redis就不一样了上次发的还没过期，直接驳回，省得浪费短信钱。

来日方长。 然后就是Token了。用户登录成功后 我们生成一个Token，存到Redis里Key是Token，Value可以是用户信息或者手机号。以后每次请求，带上这个Token，我们去Redis里查一下存在就放行，不存在就踢出去。这种方式比Session灵活多了 而且天然支持分布式，只要Redis是同一个，不管你请求打到哪台服务器，都能鉴权成功。是不是很机智？我觉得我简直是个天才。

代码实现环节，看着乱别介意！

最终的最终。 好了废话不多说直接上代码吧。我知道你们最想看的就是这个。虽然我的代码风格可能有点...随性，但是能跑起来才是硬道理，对吧？这里我用Java写的，毕竟Java还是企业级开发的老大哥，稳得一匹。

先说说是发送验证码的逻辑。这里要注意，验证码得随机生成，别搞什么“888888”这种固定码，除非是测试环境。 呵... 生成完之后调用腾讯云的接口发出去，然后顺手扔进Redis里设置个5分钟有效期。这操作行云流水，一气呵成。

public String sendSmsCode {
    // 随机生成一个6位数的验证码， 虽然简单，但是够用了
    String code = .nextInt + 100000) + "";
    // 这里省略了调用腾讯云短信接口的具体代码，太长了写起来累
    // 假装这里调用了 sendTencentCloudSms;
    // 重点来了存Redis！key要带个前缀， 免得跟别的数据冲突
    // 有效期5分钟，单位是秒，别搞错了搞错了用户收不到验证码会骂人的
    .set;
    return "验证码已发送，请查收，别催！";
}

接下来是登录逻辑。用户输入手机号和验证码，我们得先校验一下。从Redis里把之前存的验证码取出来跟用户输入的比对一下。如果不对，或者Redis里根本没有，直接抛异常，告诉用户“验证码错误或已过期”。 我整个人都不好了。 别给太详细的错误提示，不然容易被黑客利用。如果对了那就生成一个Token，再存进Redis，这次有效期可以长一点，比如30分钟？或者7天？看你自己心情了。

public String login {
    // 先去Redis里捞一把
    String redisCode = .get;
    // 判空， 还要比对字符串，equals别忘了不然空指针异常等着你
    if ) {
        throw new RuntimeException;
    }
    // 验证Token，UUID就行，简单粗暴
    String token = .toString;
    // Token也存Redis，关联上手机号，方便后面查
    // 这里的有效期我设了30分钟，其实可以更长，看业务需求
    .set;
    return token;
}

双重拦截模式，平安感的来源

光有登录还不够，我们得保护我们的接口，不能谁都能调。这就用到了拦截器。我这里设计了一个双重拦截模式，听起来是不是很高大上？其实就是两个拦截器一前一后配合工作，这是可以说的吗？。

第一个拦截器，叫它“鉴权拦截器”吧。它的作用就是看你的请求里带没带Token，带的Token对不对。如果没带或者Token在Redis里找不到，直接返回401未授权，想都别想进系统。这就好比小区门口的保安，没有门禁卡一律不让进，这是可以说的吗？。

public class AuthInterceptor implements HandlerInterceptor {
    @Override
    public boolean preHandle {
        // 从Header里拿Token， 一般都叫Authorization
        String token = ;
        // 判空，还要去Redis查一下存在不存在
        if .get == null) {
            // 给个401状态码，前端就知道要跳登录页了
            ;
            return false;
        }
        // 一切正常，放行！
        return true;
    }
}

第二个拦截器，叫“刷新Token拦截器”。这个拦截器比较贴心，它主要是为了解决用户正在操作，突然Token过期了然后被强制踢下线的尴尬情况。它的逻辑是：如果Token快过期了我就悄悄地给它续个命，再延长30分钟。这样用户只要一直在用，就不会掉线，体验感瞬间拉满，共勉。！

public class RefreshInterceptor implements HandlerInterceptor {
    // 定义个阈值， 比如5分钟，剩下的时间少于这个值就刷新
    private static final long REFRESH_THRESHOLD = 5 * 60; 
    @Override
    public boolean preHandle {
        String token = ;
        // 查一下这个Token还能活多久
        Long expire = ;
        // 如果剩余时间小于阈值，那就给它续命！
        if  {
            ; // 再续30分钟
        }
        // 这个拦截器不拦截请求， 只做幕后英雄
        return true;
    }
}

为了让大家更清楚这两种拦截模式的区别，我又做了一个表格，真的是操碎了心啊。

关于JWT和Redis的那些爱恨情仇

吃瓜。 很多人可能会问，现在不都流行用JWT吗？无状态，多方便，为什么还要用Redis存Token？这个问题问得好！我也纠结过。JWT确实不错，信息都编码在Token里了不用查库，看起来很美。但是！JWT一旦发出去，就很难作废。比如用户点了“退出登录”，或者管理员封禁了用户，JWT还是有效的，直到它自己过期。这就很尴尬了平安隐患很大啊！

而且，JWT的Payload如果存太多信息，Token会变得很长，传输起来也费劲。所以综合考虑，我还是选择了Redis存Token。虽然每次请求都要去Redis查一下 多了一次网络IO，但是Redis多快啊，这点延迟完全可以忽略不计。换来的是可控的会话管理，随时可以让Token失效，这波不亏！真的，别为了赶时髦盲目用JWT，适合自己业务的才是最好的。

一下 虽然啰嗦但是干货满满

洋洋洒洒写了这么多，其实核心就那点东西：腾讯云发短信，Redis存验证码和Token，拦截器做鉴权和刷新。这套方案虽然看起来有点传统， KTV你。 甚至有点“老土”，但是它稳啊！它平安啊！它好用啊！对于大部分中大型互联网应用这套架构完全够用了。

欧了！ 未来 我们还可以在这个基础上加更多东西，比如OAuth2.0第三方登录，或者多因子认证，让系统更平安。但是万丈高楼平地起，先把这套基础的搞扎实了才是正经事。希望我这篇啰里啰嗦的文章能帮到大家，如果觉得写得烂，别骂我，我尽力了；如果觉得好，那就点个赞。 技术这条路，就是不断踩坑、不断填坑的过程，大家加油吧！