一、知识回顾（读完直接做下面的实践题）#

1. 登录校验的两件事：登录标记——登录成功之后，在后续的每一次请求中都可以获取到该标记（靠会话技术）；统一拦截——在请求进业务之前统一检查（靠过滤器 Filter / 拦截器 Interceptor，83、84 篇）
2. 会话与会话跟踪 + 三种方案：会话是”用户打开浏览器访问资源、会话建立，直到有一方断开连接”的过程，一次会话可包含多次请求和响应；会话跟踪是一种维护浏览器状态的方法——服务器要识别多次请求是否来自同一浏览器，以便在同一次会话的多次请求间共享数据；三种方案是 Cookie（客户端会话跟踪技术）、Session（服务端会话跟踪技术）、令牌技术（课程选的主流方案）
3. Cookie 的原理与优缺点：原理是响应头 Set-Cookie: name=value 写标记、之后请求头 Cookie: name=value 自动带上；优点：HTTP 协议中支持的技术；缺点：移动端 APP 无法使用、不安全（用户可以自己禁用 Cookie）、不能跨域（跨域区分协议、IP/域名、端口三个维度）
4. Session 的原理与优缺点：底层基于 Cookie——服务器创建 Session 后返回 Set-Cookie: JSESSIONID=…，浏览器之后带着它，服务器按编号找到自己那格 Session；优点：存储在服务端，安全；缺点：服务器集群环境下无法直接使用（负载均衡到另一台机器就找不到），以及 Cookie 的那些缺点
5. 令牌方案的优缺点：优点——支持 PC 端与移动端、解决集群环境下的认证问题、减轻服务器端存储压力；缺点——需要自己实现
6. JWT 的三段结构与各自内容：Header（头）记录令牌类型、签名算法；Payload（有效载荷）携带自定义信息与默认信息（如 exp 过期时间）；Signature（签名）防止 Token 被篡改——把 header、payload 融入并加入指定秘钥，用指定签名算法计算而来
7. Base64 是什么、为什么不能放敏感信息：Base64 是基于 64 个可打印字符（A-Z a-z 0-9 + /）表示二进制数据的编码方式（不是加密）；本机实测把令牌中段解开就能看到 {"id":1,"username":"shinaian","exp":…}，所以令牌里不能放密码等敏感信息，JWT 防的是篡改不是偷看
8. 生成与解析的写法：依赖 io.jsonwebtoken:jjwt:0.9.1；生成 Jwts.builder().signWith(SignatureAlgorithm.HS256, 秘钥).addClaims(claims).setExpiration(日期).compact()；解析 Jwts.parser().setSigningKey(秘钥).parseClaimsJws(token).getBody()
9. 什么情况解析失败、本机实测证据：被篡改或过期失效；秘钥必须与生成时配套（不配套或被改 → SignatureException）；本机实测解析课程里 2024 年生成的旧令牌报 io.jsonwebtoken.ExpiredJwtException: JWT expired at 2024-11-24T17:16:18Z.（换了新生成的令牌就正常）
10. 登录成功后生成令牌：把 id、username 放进 claims → 调工具类 JwtUtils.generateToken(claims)（HS256、12 小时过期）→ 随 LoginInfo 的第四个参数返回，最终落在响应 data.token 里

二、裸写题#

• 2-1 写一个”生成令牌”的工具方法 需求：写一个静态方法，接收一个 Map（里面是自定义信息，比如 id、username），生成并返回一个令牌字符串。要求：用 HS256 算法签名（秘钥自己定一个字符串常量），带上自定义信息，并且12 小时后过期。 （练习文件 test_82_JWT生成与解析.java 的题目2-1 里给了写作区，pom 依赖片段也在素材里。）

  提示（先自己想，实在想不出再点开）

  一级 · 思路：引入 JWT 的库之后，用官方的构造器一步步”拼”出令牌——声明算法与秘钥 → 放自定义信息 → 放过期时间 → 打包成字符串 二级 · 方法：Jwts.builder().signWith(SignatureAlgorithm.HS256, 秘钥).addClaims(claims).setExpiration(new Date(System.currentTimeMillis() + 12*60*60*1000)).compact()；日期用 java.util.Date；秘钥写成一个 private static final String 常量 三级 · 骨架：public static String generateToken(Map<String, Object> ____) { return Jwts.builder().signWith(SignatureAlgorithm.____, ____).addClaims(____).setExpiration(new Date(System.currentTimeMillis() + ____)).____(); }

  参考答案（做完再点开）

  1
  public class JwtUtils {
  2
  
  3
      private static final String SECRET_KEY = "aXRoZWltYQ=="; // 秘钥
  4
      private static final long EXPIRATION_TIME = 12 * 60 * 60 * 1000; // 12小时
  5
  
  6
      /**
  7
       * 生成JWT令牌
  8
       * @param claims 令牌中包含的信息
  9
       * @return 生成的JWT令牌字符串
  10
       */
  11
      public static String generateToken(Map<String, Object> claims) {
  12
          return Jwts.builder()
  13
                  .signWith(SignatureAlgorithm.HS256, SECRET_KEY)
  14
                  .addClaims(claims)
  15
                  .setExpiration(new Date(System.currentTimeMillis() + EXPIRATION_TIME))
  16
                  .compact();
  17
      }
  18
  }

  显示更多显示更少

  检查点：① compact() 不能漏——它才是真正”打包出字符串”的那一步；② 过期时间是 new Date(System.currentTimeMillis() + 毫秒数)，别把参数写成”当前时间”（那就立刻过期了）；③ 秘钥是一段 Base64 字符串（jjwt 0.9.1 对 String 形态的秘钥有这个要求），解析时必须用同一段。

• 2-2 写一个”解析令牌”的工具方法 需求：写一个静态方法，接收一个令牌字符串，解析并返回里面的自定义信息。另外回答两个问题： ① 解析时什么情况会失败、分别抛什么异常？ ② 本机解析一个 2024 年生成的旧令牌时报了 ExpiredJwtException，这说明什么？ （练习文件 test_82_JWT生成与解析.java 的题目2-2 里给了写作区。）

  提示（先自己想，实在想不出再点开）

  一级 · 思路：解析是生成的反过程——拿到解析器、告诉它用哪把秘钥去核签名、解析、把有效载荷取出来 二级 · 方法：Jwts.parser().setSigningKey(秘钥).parseClaimsJws(token).getBody()；返回值类型是 Claims（本质上还是个 Map，get("id") 能取值）；签名校验和有效期校验都在 parseClaimsJws 这一步发生 三级 · 骨架：public static Claims parseToken(String token) throws Exception { return Jwts.parser().setSigningKey(____).____(token).____(); }

  参考答案（做完再点开）

  1
      /**
  2
       * 解析JWT令牌
  3
       * @param token 要解析的JWT令牌字符串
  4
       * @return 包含令牌信息的Claims对象
  5
       * @throws Exception 如果令牌无效或已过期，则抛出异常
  6
       */
  7
      public static Claims parseToken(String token) throws Exception {
  8
          return Jwts.parser()
  9
                  .setSigningKey(SECRET_KEY)
  10
                  .parseClaimsJws(token)
  11
                  .getBody();
  12
      }

  ① 两种失败：令牌被篡改（内容改了任何字符）或秘钥不配套 → 签名校验对不上，抛 SignatureException；令牌过期失效 → 抛 ExpiredJwtException。 ② 说明那枚令牌的 exp 时间点已经过去，JWT 库在解析时主动做了有效期校验并把过期当成异常抛出来（原文：io.jsonwebtoken.ExpiredJwtException: JWT expired at 2024-11-24T17:16:18Z.）——所以课程里硬编码的那个旧 token 一跑就报错，换成刚生成的令牌就好。这也意味着”过期”这件事不需要自己判断，解析通过就说明令牌还在有效期内。

• 2-3 让登录成功后自动生成并返回令牌 需求：登录成功（用户名密码对得上）时，生成一枚令牌——令牌里带上这个员工的 id 和用户名；再把 id、用户名、姓名、令牌四样东西组装成登录结果返回。生成令牌的活儿交给 2-1 写的工具方法；秘钥、过期时长都在工具类里。 （练习文件 test_82_会话技术与JWT.java 的题目2-3 里给了写作区。）

  提示（先自己想，实在想不出再点开）

  一级 · 思路：在”查到员工之后、返回之前”插两步——① 准备自定义信息（Map，放 id、username）；② 调工具方法生成令牌 二级 · 方法：Map<String, Object> claims = new HashMap<>(); + claims.put("id", e.getId())、claims.put("username", e.getUsername())；String jwt = JwtUtils.generateToken(claims);；最后 new LoginInfo(e.getId(), e.getUsername(), e.getName(), jwt) 三级 · 骨架：Map<String, Object> claims = new ____<>(); claims.put("____", e.getId()); claims.put("____", e.getUsername()); String jwt = JwtUtils.____(claims); return new LoginInfo(____, ____, ____, jwt);

  参考答案（做完再点开）

  1
      @Override
  2
      public LoginInfo login(Emp emp) {
  3
          //1. 调用mapper接口, 根据用户名和密码查询员工信息
  4
          Emp e = empMapper.selectByUsernameAndPassword(emp);
  5
  
  6
          //2. 判断: 判断是否存在这个员工, 如果存在, 组装登录成功信息
  7
          if(e != null){
  8
              log.info("登录成功, 员工信息: {}", e);
  9
              //生成JWT令牌
  10
              Map<String, Object> claims = new HashMap<>();
  11
              claims.put("id", e.getId());
  12
              claims.put("username", e.getUsername());
  13
              String jwt = JwtUtils.generateToken(claims);
  14
  
  15
              return new LoginInfo(e.getId(), e.getUsername(), e.getName(), jwt);
  16
          }
  17
  
  18
          //3. 不存在, 返回null
  19
          return null;
  20
      }

  显示更多显示更少

  检查点：① claims 里放的是数据库里查到的员工的 id/username（e），不是请求里传进来的对象；② 本机实测登录响应里的令牌中段解出来就是 {"id":1,"username":"shinaian","exp":1790736345}（exp = 生成时刻 + 12 小时）——claims 放什么，令牌里就能解出什么；③ 令牌最终随接口响应 data.token 回到前端，之后每次请求放到请求头 token 里（接口文档约定）。

• 2-4 把三种会话跟踪方案讲清楚，并说明课程为什么选令牌 需求：PPT 第 21 页把三种方案摆在一起比较，其中一种被标了”主流方案”。请分别写清楚： ① 三种方案各自的原理（标记存在哪、浏览器怎么把它带回来、服务器怎么认）； ② 三种方案各自的优缺点； ③ 课程为什么选第三种？（提示：想想移动端、服务器集群、服务端存储这三件事） 另外补一句：本机实测里 GET /s2 一次带 JSESSIONID、一次不带，两次结果有什么不同？这说明了什么？ （练习文件 test_82_会话技术与JWT.java 的题目2-4 里给了写作区。）

  提示（先自己想，实在想不出再点开）

  一级 · 思路：按”数据存在哪”给三种方案分个类——存浏览器、存服务器、存在令牌自己身上，然后顺着”登录之后谁记住、请求怎么带回来”把原理说一遍 二级 · 方法：关键词——Set-Cookie / Cookie（响应头写、请求头带）、JSESSIONID（Session 的底层是 Cookie）、集群/负载均衡（换台机器就找不到 Session）、令牌自包含 + 签名（服务端不存东西） 三级 · 骨架：① Cookie：数据存____，服务器用____头写、浏览器用____头带；② Session：数据存____，靠____这个 Cookie 找到它；③ 令牌：数据在____，服务器只负责____和____。优缺点各写 2~3 条，选令牌的理由按”____端、环境、服务端”三点说

  参考答案（做完再点开）

  ① 原理：

  • Cookie：服务器在响应头里写 Set-Cookie: name=value，浏览器存下来，之后每次请求自动在请求头 Cookie: name=value 里带回，服务器从请求头读取；
  • Session：数据存在服务端，服务器创建 Session 后返回 Set-Cookie: JSESSIONID=1（编号），浏览器之后带着 Cookie: JSESSIONID=1 来，服务器按编号找到自己的那格 Session——底层基于 Cookie；
  • 令牌：登录成功时服务器生成令牌（里面装着自定义信息 + 签名）交给客户端保存，之后客户端每次请求把令牌放在请求头里带上，服务器校验（签名、有效期）即可，自己什么都不用存。 ② 优缺点：
  • Cookie：优点——HTTP 协议中支持的技术；缺点——移动端 APP 无法使用、不安全（用户可以自己禁用 Cookie）、不能跨域；
  • Session：优点——存储在服务端，安全；缺点——服务器集群环境下无法直接使用（负载均衡换台机器就找不到），且 Cookie 的缺点（移动端、可禁用、跨域）它也跑不掉；
  • 令牌：优点——支持 PC 端与移动端、解决集群环境下的认证问题、减轻服务器端存储压力；缺点——需要自己实现。 ③ 选令牌的理由就是它那三条优点：移动端（APP 里没有 Cookie 机制，但能存字符串）、集群（任何一台服务器拿同一把秘钥都能独立校验，不用共享 Session）、服务端存储（服务器不存会话数据，压力小）；代价是”需要自己实现”——这个实现就是 JWT（jjwt 库 + Jwts 工具类）。 补充：GET /s2 带 JSESSIONID 时返回 {"code":1,"msg":"success","data":"tom"}（取到了 Session 里存的用户名），不带时返回 {"code":1,"msg":"success","data":null}（拿不到）。同一个 JSESSIONID 能换到数据、换一个或没有就换不到——说明服务器就是靠 Cookie 里这个编号认人，Session 离了 Cookie 就找不到自己那格数据。

三、综合题#

• 3-1 做一遍”令牌的一生”实验：生成 → 解析 → 过期 / 篡改，再接进登录接口 这一题把本篇串起来，重点是把结论用真机跑出来。

  1. 建 JwtUtils 工具类：写生成令牌、解析令牌两个静态方法（HS256 + 秘钥常量 + 12 小时过期）；
  2. 写一个测试方法生成令牌（自定义信息里放 id=1、username=admin，过期时间先设成 1 分钟，方便做第 5 步），运行，把输出的令牌抄下来；
  3. 把令牌按 . 切开数一数有几段，并把中段按 Base64 解开，把解出来的 JSON 抄下来（对照：这就是 Payload）；
  4. 用同一个秘钥解析刚才生成的令牌，把控制台打印出的内容抄下来；
  5. 等一分钟后再解析同一枚令牌（或者直接解析课程 JwtTest 里那个 2024 年的旧令牌），把异常类名和异常信息的前两行原样抄下来；
  6. 把令牌的最后一个字符改掉（模拟篡改），再解析一次，记下抛出的异常；再换成一把不一样的秘钥解析，记下抛出的异常——这两次应该是同一个异常类；
  7. 把过期时间改成 12 小时，接进登录接口：启动应用，发一次正确的登录请求，把响应里的 token 抄进练习文件；
  8. 回答下面的问题。

  （练习文件 test_82_JWT生成与解析.java 的”综合题”一段里按第 2～6 步给了记录区，test_82_会话技术与JWT.java 里给了第 1、7 步的写作区。）

  回答：① 为什么改动令牌里的一个字符就会解析失败？② 把令牌中段 Base64 解出来能看到 id、username，那能不能把密码也放进令牌里？为什么？③ 解析通过这件事能同时证明哪两件事？

  涉及知识点

  知识点	在这里的应用
  JWT 三段结构（PPT 25）	第 3 步——数段数、解开前两段看内容
  签名防篡改（PPT 25、27）	第 6 步——改字符/换秘钥都解析失败
  过期会解析失败（PPT 27）	第 5 步——ExpiredJwtException 现场
  jjwt 依赖与 Jwts 写法（PPT 26）	第 1、2、4 步——Jwts.builder() / Jwts.parser()
  登录成功后生成令牌（PPT 28）	第 1、7 步——claims 放 id/username，随 LoginInfo 返回
  令牌是”自包含”的（PPT 21、25）	第 8 步——服务端不存数据也敢信令牌的原因

  提示（先自己想，实在想不出再点开）

  一级 · 思路：先生成一枚”短命”的令牌把三个实验做完（正常解析、过期、篡改），再回到登录接口上看真实业务里的令牌长什么样 二级 · 方法：生成 Jwts.builder().signWith(SignatureAlgorithm.HS256, 秘钥).addClaims(claims).setExpiration(new Date(...)).compact()；解析 Jwts.parser().setSigningKey(秘钥).parseClaimsJws(token).getBody()；解开中段用 Base64 解码工具（在线 Base64 解码或 IDE 里看）；过期令牌在课程 JwtTest 里就有现成的 三级 · 骨架：① String jwt = JwtUtils.____(claims);；③ Base64 解码中段 → {"id":1,"username":"admin","exp":____}；④ Claims claims = JwtUtils.____(token);；⑤ 异常 io.jsonwebtoken.____JwtException；⑥ 改一个字符 / 换秘钥 → ____Exception；⑦ POST /login 响应 data.token

  参考答案（做完再点开）

  1. JwtUtils 见题目2-1、2-2 的答案（秘钥 aXRoZWltYQ==、12 小时过期，两个 static 方法）。
  2. 生成方法可参考课程的 JwtTest.testGenerateJwt（id=1、username=admin、过期 1 分钟）。本机实测输出：

     1
     eyJhbGciOiJIUzI1NiJ9.eyJpZCI6MSwidXNlcm5hbWUiOiJhZG1pbiIsImV4cCI6MTc5MDY5MzM0Nn0.BSgyQPMJ6PV1atT0j6uSkFoLDqsiBWawaoqek_hqJjI

  3. 三段（用 . 分隔）。中段 Base64 解开是：

     1
     {"id":1,"username":"admin","exp":1790693346}

     头段解开是 {"alg":"HS256"}；第三段是签名（不可读、供比对）。
  4. 用同一把秘钥解析，System.out.println(claims) 打印类似 {id=1, username=admin, exp=1790693346}（Claims 的 toString 是 Map 样式）——取值得用 claims.get("id")。
  5. 本机实测（解析课程里 2024 年生成的旧令牌）：

     1
     io.jsonwebtoken.ExpiredJwtException: JWT expired at 2024-11-24T17:16:18Z.
     2
     Current time: 2026-09-29T22:48:07Z, a difference of 58253509112 milliseconds.

     说明 JWT 库在解析时会把”过期”当异常抛出来；课程里那个硬编码 token 早就过期，换成刚生成的就正常。
  6. 改一个字符、或换一把秘钥，都会抛 SignatureException（签名与内容/秘钥对不上）。把这两次实验对比着看：过期和签名不对是两种不同的失败，分别对应 ExpiredJwtException 与 SignatureException。
  7. 把过期时间改成 12 * 60 * 60 * 1000 后接进登录业务（见题目2-3 答案），本机实测登录响应：

     1
     {"code":1,"msg":"success","data":{
     2
       "id":1,"username":"shinaian","name":"施耐庵",
     3
       "token":"eyJhbGciOiJIUzI1NiJ9.eyJpZCI6MSwidXNlcm5hbWUiOiJzaGluYWlhbiIsImV4cCI6MTc5MDczNjM0NX0.zHEWXHS6ZSoz8L2klv-8fFZQODftFlp4r_Ps1jGJFic"}}

     中段解出来是 {"id":1,"username":"shinaian","exp":1790736345}——claims 里放什么，令牌里就能解出什么。
  8. 回答： ① 第三段签名是拿”header.payload + 秘钥”按 HS256 算出来的。令牌里改了哪怕一个字符，服务器重新计算时用的”原料”就变了，算出来的签名与令牌里带着的第三段对不上——于是判定”被篡改过”，直接解析失败。改动越细微越说明问题：签名保护的是完整性，不是保密性。 ② 不能。Base64 是编码不是加密，令牌前两段谁都能解开（实验第 3 步就解开了）；把密码放进去等于把密码公开传送和公开存储。课程只放 id 与 username 正是这个道理——这两个信息即便被人看到，也不足以直接登录；真正的敏感数据（密码、身份证号）不放令牌，要放也只能放”服务端拿着能查到的标识”。 ③ 解析通过能同时证明两件事：令牌确实由持有正确秘钥的服务器签发（签名对得上，没被篡改过），以及令牌还没过期（exp 还没到）。这正是”服务器不存任何会话数据、也敢相信请求者身份”的全部依据——也就是令牌方案”减轻服务端存储压力 / 解决集群认证”的底气。