苍穹外卖Day02：JWT认证与员工分页查询实战解析-代码聚汇网

苍穹外卖Day02：JWT认证与员工分页查询实战解析

爬一手好线杆·2026-09-04·阅读 22 GEO检测（免费）

JWTThreadLocal分页查询

|难度：普通|阅读约 30 分钟

“苍穹外卖Day02”——看到这个标题点进来的朋友，大概率正在跟黑马的Java项目实战教程死磕。这套教程我前后带过不少人刷过，身边也好几个转行的朋友是靠它扛过了简历上“项目经验”这一关。Day01大家基本都从环境的泥潭里爬出来了，到了Day02，项目才真正开始进入“有点东西”的阶段：员工端的登录认证、JWT令牌、ThreadLocal存取当前用户、分页条件查询、启用禁用员工状态。这一天的内容密度很高，而且是后面所有管理端功能的地基。网上那句“Java也是瓦”的梗，放在这里挺应景——这天的代码要是地基没浇透，后面做菜品、订单模块时返工的风险可不小。

2. 员工登录与JWT身份认证：这天的核心地基

Day02的第一个重头戏是员工登录接口。表面上就是接收用户名密码、查库、返回个success，但真正的技术含量在于登录成功之后如何维护这个会话状态。苍穹外卖在这块用的是JWT加拦截器的组合方案，这也是当前前后端分离项目中最主流、面试也最爱问的一类设计。

2.1 为什么选JWT而不是传统Session

如果你之前只写过传统的单体Web应用，这里需要先转个弯。传统Session方案是服务端在内存或Redis里存一份会话数据，给浏览器回一个sessionIdcookie；客户端再请求时带上cookie，服务端查一下会话还在不在。前后端不分离时这套完全够用，但现在的管理端项目基本都是前后端分离的，前端在浏览器里跑，后端只是纯接口服务。前端发请求时带上cookie受跨域策略的限制，处理起来麻烦，而且后端服务如果拆成多实例部署，Session的共享又是一个问题。

JWT的思路是把这个会话凭证直接交给客户端保管。登录成功后，服务端把“当前用户是谁、角色是什么、有效时间是多少”这些信息用密钥签名后生成一串很长的字符串，交给前端存起来；前端之后每次请求都把它放在请求头的Authorization字段里带过来，后端只需要拿密钥验证这串令牌没被篡改、还没过期，就放行。整个过程不需要在服务端保存任何会话记录，天然的分布式友好、天然跨域支持。

注意：JWT不等于加密浏览器里的数据。它只是做了签名防篡改，只要密钥不泄露，token内容改一个字符都会被校验拦下来。它里面包含的用户名、userId等信息是Base64编码，不是加密，所以千万不要往token里塞密码之类的敏感字段。

2.2 JWT的结构和生成校验关键点

JWT本身是一长串由点号分隔的三段字符串，格式为Header.Payload.Signature。Header里声明了签名算法（教程里常用HS256），Payload里放自定义的业务数据，比如员工id、用户名、过期时间，Signature则是拿前两段加密钥做HMAC-SHA256算出来的签名。

苍穹外卖在这天的教程里通常会引入jjwt这个库。0.9.x版本和0.11.x版本的API风格差异比较大，如果你用的项目版本是教程配套的0.9.1，写出来的代码会长这样：

java复制// 生成JWT令牌
JwtBuilder builder = Jwts.builder()
        .setSubject("苍穹外卖员工")
        .claim("empId", empId)
        .claim("name", username)
        .setExpiration(new Date(System.currentTimeMillis() + 7200000)) // 2小时有效期
        .signWith(SignatureAlgorithm.HS256, secretKey);
String token = builder.compact();

校验解析时的代码对应这样：

java复制Claims claims = Jwts.parser()
        .setSigningKey(secretKey)
        .parseClaimsJws(token)
        .getBody();
Long empId = claims.get("empId", Long.class);

需要注意一个坑：如果你用的是0.11.x以上版本，signWith(SignatureAlgorithm.HS256, secretKey)这种传字符串密钥的写法已经被废弃了，必须换成Keys.hmacShaKeyFor(secretKey.getBytes())来生成合适的SecretKey对象。很多人在版本配错之后编译报错找半天原因，其实就是jjwt版本API变动导致的。教程给了什么版本就坚持用什么版本，千万别自己随便升级依赖。

另外一个经验是密钥长度。HS256要求密钥至少256位，也就是32个字节。如果你随手写了signWith(SignatureAlgorithm.HS256, "sky")这种密钥，部分旧版本jjwt能跑通，但新版本运行时会直接抛一个WeakKeyException异常。项目如果打算长期维护，建议直接定义一段足够长的密钥常量，不要用太短太简单的字符串。

2.3 登录流程整体串一遍

我见过不少学员卡在登录模块搞不清Controller、Service、Mapper之间的调用关系。其实这个流程非常标准，Day02的整个登录接口无非就是四步：

Controller接收前端提交的LoginDTO，DTO里只带username和password两个字段。
Service层拿username去数据库查员工记录。这里有个隐藏细节，数据库里的密码字段存的是MD5加密后的密文，并不是明文，教程里初始化SQL脚本里那条默认密码就是一段MD5摘要。所以Service层要先把前端提交的明文密码做一次MD5转换，再去和库里的密文比对，不能拿明文直接查库。
比对结果不一致，直接抛异常；一致则说明密码正确，但还要检查员工状态，如果status为0（已禁用），同样要抛业务异常。
验证全部通过后，根据当前员工的id和用户名生成JWT，把token封装到LoginVO返回给前端。

这段逻辑写完之后别急着往下走，建议先手工验证一个细节：库里员工状态改成禁用后再登录，确认接口能阻挡。很多人做到后面启用禁用功能时才发现登录那里压根没做状态校验，返回去补，其实这个状态判断本来就应该放在登录环节做掉。

密码用MD5处理是教程里的简化设计。放在真实企业项目里，密码哈希至少会用BCrypt这种带盐的慢哈希算法，MD5撞库风险太大，纯属为了教学方便才这么用。你在项目文档里能看到这个模块就足够了，面试时被问到可以提一句“生产环境密码存储建议升级为BCrypt”，这是加分项。

2.4 拦截器与ThreadLocal：登录状态怎么在请求链路里传递

JWT生成好之后，后端不能每个接口都手动写一遍“解析token、校验、取出用户id”。苍穹外卖的设计是定义一个JwtTokenAdminInterceptor拦截器，注册进WebMvc配置里，让它统一拦截/admin/**路径下的请求。拦截器内部先取请求头里的token，调用JWT工具类校验，校验失败直接返回401状态码，前端收到这个状态码就知道用户登录过期了，会跳到登录页。

真正有设计含量的地方在拦截器校验通过后的这一步：把解析出来的员工id存到ThreadLocal里。

为什么需要ThreadLocal？因为后续业务层的很多操作都和“当前操作人是谁”强相关。比如管理员新增一个菜品，数据库里的create_user字段需要记录到底是哪个管理员干的；修改员工信息时，update_user也要跟着变。如果没有ThreadLocal，你就得在Controller每个方法里手动把userId作为参数层层往下传，Service接口和方法签名全部要被这个userId污染，代码会变得非常丑。

ThreadLocal可以理解为给每个请求线程准备的一个私有储物柜。请求进来时，拦截器往里面放一份用户id；同一个线程后续执行的Controller、Service、Mapper代码都可以通过ThreadLocal的静态方法把这份数据取出来。等请求结束，整个线程被归还到Tomcat线程池之前，必须把这个储物柜清空。如果不清理，Tomcat线程池里的线程是复用的，上一次请求存进去的数据可能被下一个请求读到，这就是典型的内存串号Bug，排查起来非常恶心。

苍穹外卖教程里通常有两种实现方式。一种是定义一个BaseContext工具类，内部持有ThreadLocal<Long>静态变量，提供setCurrentId和getCurrentId两个方法。另一种是直接在JWT拦截器中暂时保存，但缺少统一的上下文类。我个人建议你把BaseContext这种统一上下文类的方案练熟，这不仅是这天的代码逻辑，后面做菜品、套餐、订单模块时，公共字段填充全靠它。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

3. 员工分页查询：第一个完整的前后端联调功能

登录认证这块搞通了，接下来Day02正式进入业务功能开发，第一个就是员工分页查询。这个功能看起来不复杂，但它是整个管理端第一个从前端页面到后端接口完整打通的功能，页面长什么样、接口字段叫什么、参数怎么传，都从这里定下基调。你要理解的不只是代码怎么写，更是这套前后端协作的契约是怎么定义的。

3.1 需求拆解

先看业务诉求：管理端的员工列表页需要支持分页展示，每页显示10条；姓名那一栏还要支持模糊查询；查询结果按照更新时间倒序排列。这三个条件就是分页查询接口的全部需求。前端页面把当前页码、每页大小、需要过滤的姓名这三个参数提交给后端，后端返回数据总数和当前页的员工集合。

前端实际传参的字段名是page和pageSize，都对应后端PageQuery对象；name是可选参数，不传即查全部。请注意，姓名的地方用的是模糊查询，但SQL里不能直接拼，要用like关键词加concat('%', name, '%')这种写法，既防止SQL注入，又能兼容MySQL的字符串拼接逻辑。

3.2 从Controller到Mapper的编码链路

Controller层的代码是标准的三层写法：

java复制@GetMapping("/page")
@ApiOperation("员工分页查询")
public Result<PageResult> page(EmployeePageQueryDTO employeePageQueryDTO) {
    log.info("员工分页查询，参数：{}", employeePageQueryDTO);
    PageResult pageResult = employeeService.pageQuery(employeePageQueryDTO);
    return Result.success(pageResult);
}

Service层这里有个教学项目里很常用的分页插件——PageHelper。用它的代码非常简洁：

java复制public PageResult pageQuery(EmployeePageQueryDTO dto) {
    PageHelper.startPage(dto.getPage(), dto.getPageSize());
    Page<Employee> page = employeeMapper.pageQuery(dto.getName());
    return new PageResult(page.getTotal(), page.getResult());
}

这里有个很多初学者容易踩的坑：PageHelper的startPage方法必须在紧接着的下一行Mapper查询之前调用，中间一旦插入其他数据库操作，分页就可能被干扰。原理是PageHelper用拦截器动态改写你接下来执行的那条SQL，在SQL后面临时拼接limit语句。如果你在startPage之后又去执行了别的查询，分页就会加错对象，查出来的数据完全对不上。

在Mapper层，你需要写一个带动态SQL的查询方法。如果用注解形式，写法大概是：

java复制@Select("<script>" +
        "select * from employee" +
        "<where>" +
        "  <if test='name != null and name != \"\"'>" +
        "    and name like concat('%', #{name}, '%')" +
        "  </if>" +
        "</where>" +
        "order by update_time desc" +
        "</script>")
Page<Employee> pageQuery(String name);

这里如果返回类型用Page<Employee>，配合PageHelper才能把总数和列表一起拿到。如果你习惯XML映射文件，动态SQL的写法本质一样，写在XML里反而更清晰。需要注意的是<if>标签的动态条件经常拼出多余的“and”，所以外层要用<where>标签包裹，MyBatis会自动把开头的and去掉。

提示：name字段的判空建议同时判断null和空字符串。前端的输入框只要被提交过又清空，传过来的就是一个空字符串而不是null，如果只判断null，空字符串条件照样会拼进SQL，导致查不出任何数据。

3.3 分页结果里密码字段的隐藏

数据库的employee表里存了MD5密文密码，但这个字段一定不能返回到前端页面上。一般的处理思路是在实体类字段上加@JsonIgnore注解。这个注解是Jackson序列化时忽略指定字段最直接的方式。效果就是后端返回JSON时自动跳过password，哪怕查询结果里带着这个字段，也不会被传输。

这个小细节我建议你提高到安全意识层面来看：任何接口都不要把不必要的敏感字段返回给前端。分页接口只返回员工列表界面需要展示的数据，一般包含id、用户名、姓名、手机号、状态、创建时间和更新时间就足够了。你可以为分页查询专门建立一个employeeVO，只封装必要的展示字段，别图省事直接拿实体类去返回。

3.4 前端页面与接口联调时容易踩的坑

这部分很多人是第一次接触Vue管理后台页面，最容易出的问题是前端明明传了分页参数，后端却报“Required request parameter 'page' for method parameter type Integer is not present”。原因通常有两个：一个是前端参数名写错了，比如变量名叫pageNum，后端接口字段要求page；另一个是前后端约定的Content-Type不对，GET请求的参数是拼在URL后面或者是表单参数，你得看教程里Axios请求是怎么封装的。

还有一类问题是分页数据正常返回到浏览器Network面板了，但表格就是渲染不出数据。别急着怀疑后端，先看返回结果的data结构。苍穹外卖统一返回Result对象，分页数据是放在Result的data字段里面的，data的结构是包含total和records两个属性的PageResult对象。前端表格绑的是records，总数控件绑的是total。搞不清这个层级关系，数据自然显示不出来。

4. 启用禁用员工：动态SQL与状态变更的处理细节

分页查询搞定之后，Day02的收尾功能是启用禁用员工账号。这是一个典型的状态更新接口，业务逻辑不复杂，但把SQL更新操作的各种细节都串起来了，而且它最能检验你对“接口幂等”“用户友好提示”“状态变更边界”这些基础概念的掌握程度。

4.1 业务约束和实现思路

员工的status字段有两个取值：1代表启用，0代表禁用。被禁用的员工账号登录时会被拦截，前面登录模块那块提到的状态校验就是为这个功能准备的。

Controller提供的是一个POST接口，路径形如/admin/employee/status/{status}，status用路径变量方式传参，员工id通过请求参数employeeId传过来。前端点击“启用”或“禁用”按钮时，会把目标状态和员工id一起提交过来。Controller在拿到这两个参数后调用Service层执行更新。

Service层要考虑一个边界情况：如果接口收到的是对同一个员工、相同状态的重复提交，比如员工已经处于禁用状态，又收到一个禁用请求，正常来说直接返回成功即可，不需要报错，接口保持幂等性。但如果某个接口设计成重复请求会叠加计数或重复扣减库存，那就必须考虑幂等保护。

真正需要做状态判断的地方在于，当前登录的管理员不能操作自己的账号，尤其是不能把自己禁用了。教程里可能会提示你判断一下操作目标和当前登录用户是否相同，但这块很容易被忽略。更严重的案例是系统里仅剩一个可用管理员时还要强行禁用，业务上会造成自己把自己锁在门外的尴尬。真实项目会把“至少要保留一个启用的管理员”作为前置校验，Day02可以不写这段逻辑，但你应该知道真实场景会有这类限制。

4.2 动态更新开启字段为null不覆盖

这个功能的数据层实现很简单，但有一个很重要的通用性设计：Mapper层要用动态SQL去更新非空字段，而不是把整个实体类的所有字段都更新一遍。这里我用XML写法做示例：

xml复制<update id="update" parameterType="Employee">
    update employee
    <set>
        <if test="name != null">name = #{name},</if>
        <if test="username != null">username = #{username},</if>
        <if test="status != null">status = #{status},</if>
        <if test="updateTime != null">update_time = #{updateTime},</if>
        <if test="updateUser != null">update_user = #{updateUser},</if>
    </set>
    where id = #{id}
</update>

通过<set>标签配合<if>判断，只有传入的实体类里非null字段才会出现在update语句中。这样做的意义在于：修改自己的基本信息时，不会把一个status为null的字段不小心覆盖成NULL；把更新逻辑抽成一个通用方法，新增和修改可以共用。

这里有个细节，凡是做update操作，update_time和update_user这两个公共字段一定要在Service层手动set进去。update_time当然是用当前时间，update_user就要在ThreadLocal里取当前登录管理员的id。有些学员图省事不更新这两个字段，过两天天天查数据时发现排序结果不对，又跑回来补，这种基础功夫早晚是要还的。

4.3 前后端交互：请求参数怎么传才能不出错

完成功能之后要试着从前端页面上点一下。点击员工列表里“禁用”按钮时，前端通常发的是一个POST请求，但URL和参数形式在不同版本里可能略有差异。需要特别留意的是，有些前端框架的请求方法体默认以JSON格式提交，而有些版本则是表单提交。如果后端Controller接收的是普通参数而不是@RequestBody，前端用JSON格式提交就会碰壁——后端拿到的employeeId是null。

解决思路是在Controller接口上加上参数日志，把请求路径和所有参数都打出来，用Postman或直接在浏览器Network面板里看前端实际发的请求体格式，再对症下药。我在带新手的时候，遇到状态更新接口调不通，一半以上是这种参数类型对不上的问题，而不是后端SQL写错。

5. 我对这一天的学习建议与后面几天的衔接准备

Day02的内容学到这里，你应该对JWT认证流程、ThreadLocal传值、分页查询开发模式、动态SQL这些核心技能有了完整的实操体验。接下来往后走，Day03开始的内容都会依赖这天的地基，我提前剧透几个关联点，方便你有针对性地预习。

第一，公共字段自动填充。这个功能在后面的菜品、套餐、分类模块会非常常用，凡是涉及创建人和更新人的字段，总不能每个insert语句都手动写一遍createUser和updateUser。最终你会用MyBatis提供的自定义拦截器，在SQL执行前把当前登录用户的id和当前时间自动set到实体对象里，一劳永逸。这个功能依赖的正是今天ThreadLocal里存的empId。所以如果你今天没把BaseContext那个类写明白，后面拿到需求会卡很久。

第二，文件上传与阿里云OSS的接入。菜品管理需要上传图片，那一天会引入对象存储服务的概念。你如果已经理解了JWT拦截器、Controller接收参数、Service层调用这些基础链路，那么OSS上传其实只是在Service层里面多调一个第三方SDK的问题，本质没有新增复杂度。

第三，理解前端路由与token存储。后面频繁切换到商户端小程序时，你会发现管理端的登录态和小程序的登录态是两套独立的体系。但核心思路完全一致——后端发一个token凭证，前端所有请求带上它。只要你把今天管理端这条链路捋通了，再去看小程序端的wx.login和JWT签发，基本可以举一反三。

再说几条实操层面的建议。每天跟着视频敲完代码后，不要急着进入下一天的课程，花二十分钟做三件小事：回头在Postman里把你的分页查询接口跑一遍，验证一下name模糊查询是否真的生效；试着把JWT的有效时间改成几秒钟，手动体验一次token过期后的401流程，观察前端页面会不会按预期跳回登录页；把员工的数据库记录状态改一下再去登录，看看登录接口是否按预期拦截。这三个小实验做完，你对今天的代码才算真正吃透，而不只是“敲过一遍”。

提示：有条件的话，建议把这几天项目的代码从最开始就放进Git管理，每完成一个功能就提交一次。后面开发过程中代码写乱了、功能调不回去了，随时能用Git对比找回，这个习惯在进入真实项目后会受益很多。

最后说一个我在带新人时反复强调的观点：苍穹外卖这套教程真正的价值不只是让你学会了Spring Boot、MyBatis、JWT这些技术栈，更重要的是它把你带进了一套前后端分离项目的完整协作流程——接口怎么设计、公共字段怎么处理、异常怎么统一管理、登录状态怎么流转。Day02是这套流程第一次完整运转起来的一天，值得你把每一行代码都吃透再往后走。基础打牢了，后面即便加需求、写新的业务模块，心里也会更有底气。