外卖项目总结

技术点

1. Nginx
   1.1 Http服务器，部署静态资源，访问性能高。
   1.2 负载均衡：通过调度算法将客户端的访问流量分发到不同的应用服务器上面，避免单点故障。
   
   1.3 反向代理与正向代理
   相同点：都位于客户端与服务器之间
   不同点：

   正向代理	反向代理
   为客户端服务	为服务器端服务
   应用在FQ、内网访问	应用在负载均衡、隐藏真实服务器IP
   客户端配置代理	服务器端配置代理
   客户端直到目标服务器	客户端只知道代理服务器

2. Swagger——框架
   接口文档的在线生成，让API结构自动化地以可视化的形式展现出来。提供了接口文档的自动生成、交互式测试、接口定义规范
   SpringBoot中的使用：
   2.1 引入依赖
   2.2 添加配置类
   2.3 在对应位置使用注解
   常用注解：

   @Api(tags = "")//用在类上
   @ApiModel//用在类上
   @ApiModelProperty//用在属性上
   @ApiOperation//方法上
   

   面试一问：

   1. Swagger文档对生产环境是否安全？
      不建议在生产环境暴露Swagger，可能导致接口被恶意测试或攻击。通常配置为仅在开发或测试环境启用
   2. 使用过程中遇到过什么问题
      我在使用 Swagger 时遇到过接口过多导致加载速度变慢的问题，后来通过分组（groupName）、限定扫描包路径、升级 Springdoc 版本解决。此外，对于需要登录态的接口，配置了全局参数添加 Token 以便测试。
   3. Swagger有哪些代替方案
      Apifox: 国内常用，集接口文档、调试、Mock、测试于一体
      Knife4J：Swagger的增强UI，中文社区常用

3. JWT
   将原始的JSON数据进行安全封装，右Header（令牌类型、签名算法等）、载荷（携带信息）、签名（防伪）组成
   应用场景：身份验证、授权、信息交换
   使用流程：

   1. 导入依赖
   2. 编写工具类
   3. 利用工具类下发/解析JWT实现功能
      认证流程：
      用户登录，服务端验证用户名密码正确后，生成 JWT（包含用户信息）并返回给客户端。
      客户端将 JWT 存储（通常在 localStorage 或 sessionStorage）。
      客户端每次请求 API 时，将 JWT 放在 HTTP Header（Authorization: Bearer ）。
      服务端通过验证 JWT 的签名，确定用户身份，无需再查询数据库。
      优点：
   4. 无状态：服务器端不需要存储Session信息，减少了服务器压力，适合分布式架构
   5. 跨语言支持：基于JSON，各语言均有库支持
   6. 安全性：通过签名可以防止篡改
      面试一问：
   7. JWT与Session区别
      |Session|JWT|
      |----|----|
      |服务器端保存Session|服务端无状态，不保存token|
      |扩展到多服务器需要共享Session|JWT自包含，适合分布式架构|
      |相对安全，不易被窃取|易被窃取，需配合https|
   8. JWT如何防止被篡改
      通过签名算法，验证载荷是否被修改
   9. JWT可以存储敏感信息吗
      不建议。虽然签名能防篡改，但 Payload 是明文可解码（Base64Url 编码），除非对内容进行额外加密。
   10. JWT如何实现过期
       使用 Payload 中的 exp 字段，服务端验证 Token 是否过期。
   11. JWT如何实现登出
       由于 JWT 无状态，登出比较麻烦：可以维护黑名单（存储已登出 Token 的标识）；减短 Token 有效期 + 使用 Refresh Token 机制。
   12. JWT有Refresh Token吗？
       通常结合使用：Access Token：短有效期（如 15min），用于访问资源；Refresh Token：长有效期，用于获取新的 Access Token

4. Refresh Token
   背景：Access Token 一般设置较短的过期时间（如15min）以提升安全性。但如果Access Token过期，用户需要重新登录会导致体验很差。由此引入了Refresh Token（刷新令牌），用于在Access Token过期后，无需重新登录即可换取新的Access Token
   工作原理：

   1. 用户登录成功
      服务端生成Access Token（短期有效），同时生成Refresh Token（长期有效）。将两者返回给客户端
   2. 客户端请求接口时
      使用 Access Token进行认证
   3. 当 Access Token过期
      客户端使用Refresh Token 请求服务端刷新获取新的Access Token
   4. 如果Refresh Token 也过期
      用户需要重新登录
      存储位置
      Access Token： LocalStorage / SessionStorage / Cookie
      Refresh Token： 通常存放在HttpOnly Cookie，避免被js读取，提高安全性
      面试一问：
   5. 为什么Access Token不设置长一点的有效期？
      安全性考虑：Token有效期越短，即使被窃取，也能尽快失效
   6. Refresh Token可以撤销吗？
      可以，通常在服务端维护：Refresh Token列表或黑名单；用户登出时，立即将Refresh Token失效。

   ​