企业官网建设流程全解析

最近后台收到不少同学私信，说想找一个前后端分离、技术栈不太老也不太激进、能直接跑起来做二次开发的Java Web项目。正好我手头有一套完整的房产销售系统源码，用的就是SpringBoot2 + Vue3 + MyBatis-Plus + MySQL8.0这套组合，还带了配套文档，前后端加数据库脚本都齐全。这篇文章我不打算只贴链接或者简单介绍功能，而是把整个项目从架构设计、数据库建表、后端接口、前端页面的实现思路，到实际部署运行需要避开的坑，一次性讲清楚。不管你是毕业设计要用，还是想学习主流前后端分离项目的组织方式，这套代码都值得花点时间研究。

1. 项目整体设计与技术选型思路

1.1 这套系统到底是干什么的

房产销售系统，核心业务链路其实很清晰：楼盘房源管理、客户信息登记、销售顾问跟进、预约看房、认购签约、售后服务跟踪。市面上很多类似项目要么只做了个简单的CRUD演示，要么业务逻辑混乱、表设计随意。这套源码比较难得的地方在于，它是按照真实业务流程来设计的，把销售角色、客户状态、房态状态这些关键业务概念都落到了代码里。

登录进去之后，系统区分管理员和销售顾问两种角色。管理员可以管理房源信息、查看所有客户的跟进记录、配置楼盘基础数据；销售顾问可以录入自己负责的客户、给客户分配意向房源、登记看房记录、提交认购申请。整个权限控制用的是Spring Security + JWT的方案，前端根据登录用户的角色动态渲染菜单和按钮，后端接口也会做二次权限校验，避免越权操作。

1.2 为什么偏偏选这四件套

很多人在技术选型上容易纠结，我直接说结论：这套组合在2024-2025年这个时间点，恰好是最均衡的搭配。

SpringBoot2虽然已经出了3.x版本，但2.x的生态最稳定，网上能搜到的资料、常见的踩坑解决方案基本都是基于2.x的。更重要的是，很多企业的存量系统就是SpringBoot2，学会这套还能直接上手公司老项目。MyBatis-Plus是MyBatis的增强工具，单表操作连SQL都不用写，内置的Wrapper条件构造器能搞定绝大多数查询场景，比原生MyBatis省太多事，又不至于像JPA那样屏蔽了SQL细节。Vue3是目前前端的主流方向，组合式API写起来逻辑更聚合，配合Vite构建速度飞快。MySQL8.0则提供了窗口函数、CTE这些新特性，性能和安全机制也比5.x时代强很多。

当然有人会说，SpringBoot3 + Vue3 + MyBatis-Flex不更新吗？我只能说，这套系统定位是生产可用、学习友好，不是追新工具。追求“跑得起来、看得懂、改得动”，这四个版本号是最稳的。

1.3 前后端分离架构下项目怎么组织

整个项目分成两个大目录，前端叫property-front，后端叫property-server。后端采用标准的maven多模块结构，按照controller/service/mapper/entity分层，但又不是简单的按层分包，而是先按业务模块划分（比如house、customer、contract、system），每个模块内部再分层。这样做的好处是后期维护的时候，找一个功能点直接进对应包，不用在几十个controller里翻找。

前端部分用的是Vite + Vue3 + Vue Router + Pinia + Element Plus。Vite负责本地开发服务器和构建打包，Vue Router管页面路由，Pinia做全局状态管理，Element Plus提供现成的UI组件。目录结构上分了views、components、api、store、router五个核心目录，views按后端模块一一对应，api目录里每个文件对应一个页面的接口请求。前后端通过HTTP + JSON通信，开发时用Vite的proxy代理转发接口，生产环境由Nginx统一托管静态资源并反向代理后端地址。

这套结构的核心好处是职责清晰。拿“新增房源”这个功能举例：前端页面填写表单，通过api模块调用POST /api/house接口，后端Controller接收参数后交给Service处理业务逻辑，Service调用Mapper操作数据库，最后把结果封装成统一响应对象返回。任何一个环节出了问题，都能快速定位到对应的代码位置。

2. 核心功能模块与数据库设计

2.1 数据库表结构怎么设计的

房产销售系统的数据库一共设计了9张表，我挑几个核心的表讲一下设计思路。项目里提供了完整的property.sql脚本，MySQL5.7和8.0都能直接导入，早期版本需要改一下字符集配置。

房源信息表（house）包含楼盘名称、楼栋编号、单元号、建筑面积、户型、朝向、单价、总价、装修状态、销售状态等字段。其中销售状态是典型的字典值设计，用0表示未售、1表示预定、2表示已售、3表示保留，为什么用数字不用字符串？因为数字在索引查询和统计汇总上性能更好，代码里配合枚举类使用，并不会降低可读性。

客户信息表（customer）除了基本联系方式和需求偏好，专门设计了source_channel字段记录客户来源渠道，比如是自然到访、电话咨询、老客转介绍还是线上广告投放。这个字段看似不起眼，但在后期的数据统计报表里非常关键，房产公司非常看重渠道转化率。另外还加了level字段表示客户意向等级，用于销售顾问做优先级排序。

预约看房表（visit）和合同表（contract）是体现业务深度的两张表。预约看房表记录客户预约的时间段、随行人数、看房状态（待带看/已完成/已取消）、关联的房源码和置业顾问工号。合同表关联客户和房源，记录成交总价、付款方式（一次性/按揭）、首付比例、签约日期，按揭方式还会额外记录贷款金额和贷款年限。

2.2 表关系与索引设计的细节

9张表之间的关系其实不复杂，主要是客户表、房源表、合同表三张核心表互相关联。客户和合同是一对多，一个客户可以重复购买（投资客很常见），同一个房源只能认筹一次（幂等性靠唯一索引保证，house_id和customer_id联合唯一）。预约看房表关联客户和销售顾问，房源表和楼盘表是多对一关系。

索引方面我特别看重两个设计。一是同步字段更新，客户表和房源表都冗余了last_follow_time字段，每次更新跟进记录时同步刷新，这样列表排序就非常快，不需要关联子查询。另一个是visit表的visit_date字段单独建了普通索引，因为按日期范围查询看房记录是非常高频的操作。

字段命名上全部采用下划线风格，后端实体类里配置了MyBatis-Plus的@TableField和驼峰自动映射，所以Java里写lastFollowTime，数据库里存last_follow_time，这中间不需要手写映射关系，MyBatis-Plus启动时就自动处理了。

2.3 从业务需求反推的数据字典

除了九个核心表，系统还设计了一套数据字典机制。房源的朝向、装修状态、客户意向等级、跟进方式这些字段，如果硬编码在代码里，后期加一个选项就得改代码重新发版，于是单独建了字典表，通过dict_type和dict_value两个字段存储。前端字典值会缓存在内存中，所有下拉框数据统一从字典表读取。

这个设计对业务系统来说太重要了。部署到新项目时，只要改数据库的字典数据，不用动一行代码，就能适配不同公司的业务术语。比如有的公司把“预定”叫“锁定”，有的叫“预留”，统一数据字典之后，前端展示的文案随时可调。

3. 后端SpringBoot2核心实现详解

3.1 项目初始化与依赖配置

后端项目是基于Spring Initializr创建的，JDK使用的1.8版本。这里多说一句，SpringBoot2.7.x最高支持JDK8到JDK21，但为了稳妥，我用的JDK8 + SpringBoot2.7.18，配合Maven3.8以上版本，整个依赖解析和打包过程一气呵成。

核心依赖其实就那几个，pom.xml里主要引入了spring-boot-starter-web提供Web能力，spring-boot-starter-security做安全认证，mybatis-plus-boot-starter集成MyBatis-Plus，mysql-connector-java驱动连接MySQL，jjwt生成和解析JWT令牌，hutool提供工具类库，lombok简化实体类代码。

需要特别提醒的是，MyBatis-Plus和SpringBoot2搭配时要选对版本。我用的mybatis-plus-boot-starter版本是3.5.3.1，这个版本对SpringBoot2的兼容性经过充分验证，如果用3.5.5以上的版本，极少数情况下会出现分页插件拦截器注册不上的问题。还有druid-spring-boot-starter数据源连接池，版本用的1.2.20，完全兼容SpringBoot2.

3.2 统一响应体与全局异常处理

一个乱糟糟的后端接口，前端对接起来非常痛苦。这套代码在一开始就定义了统一响应体Result<T>，所有接口的返回值都是这个格式：code（状态码）、msg（提示信息）、data（业务数据）。成功返回200，业务异常返回500，参数校验失败返回501，未登录返回401，权限不足返回403，前端通过code值判断是正常处理还是弹错误提示。

全局异常处理的实现用的是Spring的@RestControllerAdvice，配合自定义业务异常类BizException。在Controller里只要写业务逻辑，遇到不满足条件的情况直接抛出BizException，全局异常处理器负责把异常消息转换成统一响应体返回。空指针这种未捕获的异常则会被日志记录并返回“系统繁忙，请稍后重试”。这个设计看起来很基础，却是保证前后端联调效率的关键。

3.3 JWT登录认证与权限控制

登录流程是这样的：用户提交用户名密码，后端校验通过后用JWT工具生成token，token里存了用户ID、用户名、角色编码，有效期24小时。前端拿到token之后存在localStorage里，每次请求都在请求头加上Authorization: Bearer token。后端用Spring Security的过滤器链拦截请求，在OncePerRequestFilter里解析token、校验合法性、把用户信息放入SecurityContextHolder。

安全性方面，密码存储使用BCrypt加密，不是MD5也不是SHA，因为BCrypt内置随机盐，同样的明文密码每次加密结果都不同，有效防彩虹表破解。对于访问控制，通过@PreAuthorize注解实现，比如@PreAuthorize("hasRole('ADMIN')")表示只有管理员能调用，hasAuthority('house:add')表示需要细粒度的操作权限。这里我把角色和权限做了区分，核心接口限制角色，按钮级权限用权限标识控制。

3.4 MyBatis-Plus的3个高频应用技巧

MyBatis-Plus之所以效率高，是因为它把单表CRUD都封装好了。这里重点讲三个我在项目中深度使用的应用点。

第一个是条件构造器LambdaQueryWrapper。查询房源列表的时候，可能是根据楼盘名模糊查询、根据价格区间筛选、根据状态判断，用LambdaQueryWrapper链式编程，字段名用方法引用，编译期就能发现字段名的拼写错误，改代码不怕脏数据。代码大概是这样的：

LambdaQueryWrapper<House> wrapper = Wrappers.lambdaQuery(); wrapper.like(StringUtils.hasText(keyword), House::getBuildingName, keyword) .ge(minPrice != null, House::getTotalPrice, minPrice) .le(maxPrice != null, House::getTotalPrice, maxPrice) .eq(House::getSaleStatus, status); List<House> houses = houseMapper.selectList(wrapper);

条件为false时对应的条件自动忽略，这个特性太适合动态筛选了。

第二个是分页插件。MyBatis-Plus分页需要手动注入MybatisPlusInterceptor并添加PaginationInnerInterceptor，注意新版拦截器的包路径有变化。配置好之后调用selectPage方法，返回的Page对象里直接就有总条数、总页数、当前页数据，前端拿到后渲染分页组件即可。

第三个是逻辑删除。房源如果被误删除是有风险的操作，我用逻辑删除，删除操作自动变成UPDATE house SET deleted = 1 WHERE id = ?，查询的时候自动追加deleted = 0条件。实体类字段加@TableLogic注解，数据库表加deleted字段，配置即可生效。逻辑删除也有代价，就是唯一索引不能建在业务字段上，否则删除后的数据再插入会冲突，需要在代码里处理。

3.5 Service层的业务逻辑组织

后端的Service层不是简单把Mapper调用包一层。在合同签约这个场景里，Service层的逻辑是这样的：先校验房源状态必须是未售，再把房源锁定状态改成预定，同时给客户创建合同草稿，最后更新客户的意向等级。这四个步骤必须放在同一个事务里，任何一个失败全部回滚。

这里的落库操作涉及多张表，SpringBoot的开发模式是在Service方法上标注@Transactional(rollbackFor = Exception.class)。注意，rollbackFor一定要指定，默认RuntimeException才会回滚，如果抛出的是检查异常，事务不会回滚，数据就出现不一致了。我还习惯在核心业务操作前加自有锁，比如签约时用Redis分布式锁锁定房源码，防止两个销售顾问同时卖同一套房。

4. 前端Vue3项目实现与页面细节

4.1 Vue3项目搭建与环境配置

前端部分使用Vite搭建，创建命令是npm create vite@latest property-front -- --template vue。Node.js版本要求16以上，推荐18.17或20 LTS版本，npm版本8以上。

项目依赖主要这几块：vue-router@4做路由管理，pinia做状态管理，element-plus做UI组件库，axios做HTTP请求，sass做样式预编译。Element Plus按需引入我用的是unplugin-auto-import和unplugin-vue-components这两个Vite插件，组件和API都会自动导入，构建出来的代码体积比全量引入小很多。

开发环境的跨域配置在vite.config.js里，配置server.proxy把/api前缀的请求代理到http://localhost:8080，这样前端开发时请求路径统一写/api/xxx，不容易出乱子。

4.2 基于Pinia的状态管理与登录态控制

Pinia替代了Vuex成为Vue3推荐的状态管理方案，它的API更简洁，去掉了mutation的概念。项目里我建了userStore和dictStore两个store。userStore保存当前登录用户的token、用户名、角色、权限列表，刷新页面时从localStorage恢复数据并重新请求用户信息接口，保证登录状态不丢。dictStore负责按字典类型拉取数据字典，并缓存在内存中，提供getDictList方法供组件调用。

路由守卫是前端访问控制的核心。router.beforeEach里判断如果访问的页面需要登录而本地没有token，跳转到登录页。如果有token但访问的是登录页，则重定向到首页。动态路由方面，根据用户的角色编码，在守卫里动态添加对应权限菜单的路由，这样普通销售看不到管理员的页面入口，配合后端权限校验，双重保险。

4.3 核心业务页面的实现思路

房源管理页面是大数据量表格的典型场景。表格展示楼盘名称、户型、面积、单价、总价、状态等字段，顶部是筛选条件，包括关键字搜索、价格区间、户型筛选。这里用Element Plus的el-table组件，分页使用el-pagination，切换页码或者改变每页条数时重新请求接口。前端拿到Page对象后，表格数据就是records字段，总条数用于计算分页组件。状态字段是数字字典值，表格里通过tag标签展示不同颜色的状态，未售是绿色、预定是橙色、已售是灰色。

客户管理页面用了el-tabs组件做状态的切换筛选，分为全部客户、待跟进、已成交、已流失几个标签页。点击某个客户时可以打开抽屉（el-drawer）展示客户详情，包括基本信息、意向房源、跟进历史记录。跟进记录的录入方式是表单弹窗，提交后刷新列表，这里通过mitt事件总线通知详情组件刷新数据。

预约看房模块用日历视图展示一个月的看房安排。日历选中的日期会查询当天所有预约记录，右侧列表展示具体的看房时间段、客户姓名、置业顾问和房源码。已经带看完成的记录可以登记带看结果，这个结果数据是后续分析销售转化率的基础。

4.4 前端工程化细节与体验优化

请求封装方面，我在utils/request.js里基于axios创建了一个实例，设置了基础URL、超时时间和请求拦截器。请求拦截器自动从userStore取出token并添加到请求头，响应拦截器统一处理code值不等于200的情况，401跳到登录页，403弹出无权限提示，其他错误通过ElMessage弹出错误信息。这样业务代码不用关心异常处理的重复逻辑。

按钮级权限的自定义指令v-hasPermi也值得一提。拥有权限列表里包含house:delete权限的用户才能看到删除按钮，否则直接移除DOM元素。实现原理也很简单，在Vue的directive里bind钩子中判断权限，没有权限就直接el.parentNode.removeChild(el)。

页面性能上，路由和组件都做了懒加载，首屏只加载必要的JS，进入二级页面再按需加载。表格在大数据量情况下，我给el-table设置了height属性和虚拟滚动（自研了一个简单版本），3万条数据滚动不卡顿。如果数据量超过5万，建议走后端做游标分页或者引入el-table-v2，这是后话。

5. 部署运行全流程与常见问题排查

5.1 从零到一跑通这个项目

我先说怎么在本地把它跑起来，这是很多人卡住的第一关。

第一步装环境。JDK8、Maven3.8以上、Node.js18以上、MySQL8.0，缺一不可。MySQL8.0的安装，Windows环境直接下载zip包解压后初始化，写配置文件my.ini，执行mysqld --initialize-insecure，然后安装服务并启动。Mac环境建议用Homebrew直接brew install mysql，默认配置就能用。Linux服务器上我习惯用Docker安装，docker run -d --name mysql8 -p 3306:3306 -e MYSQL_ROOT_PASSWORD=123456 mysql:8.0，一行命令搞定，数据卷挂载记得加上。

第二步初始化数据库。用Navicat或者命令行执行项目里的sql/property.sql脚本，脚本会自动建库建表并插入初始数据（包含admin管理员账号和几个演示数据）。MySQL8.0默认字符集已改为utf8mb4，没有中文乱码问题，但是如果是从5.7升级上来的库，建议启动参数加character-set-server=utf8mb4。

第三步启动后端。用IDEA打开property-server目录，等待Maven下载依赖后，修改application.yml里的数据库账号密码，直接运行PropertyApplication类的main方法即可。启动日志出现Started PropertyApplication表示成功，默认端口8080。

第四步启动前端。命令行进入property-front目录，npm install安装依赖（国内网络建议配一下镜像源），npm run dev启动开发服务器，默认端口5173。浏览器访问http://localhost:5173，用admin/123456登录即可看到系统首页。

5.2 后端部署到Linux服务器的实操记录

本地跑通只是第一步，部署到服务器才是真实挑战。我在这套项目上完整走了一遍服务器部署流程，这里分享出来。

后端打包是mvn clean package -DskipTests，在target目录生成property-server.jar。服务器上我用的是systemd管理Java进程，创建/etc/systemd/system/property.service文件，配置ExecStart指向jar包地址，监听8080端口，设置标准输出日志到指定文件。这样做的好处是进程崩溃自动重启，开机自启，而且日志管理规范，不污染终端。

需要注意的一点是，jar包启动时的运行内存，我指定了-Xms256m -Xmx512m参数。如果是1核2G的服务器，给JVM分配512M内存足够了，剩下的留给前端Nginx和数据库。如果内存配额太小，JVM频繁GC会导致接口响应慢，用户直观感受就是页面卡顿。

5.3 Nginx部署Vue3项目的配置要点

Vue3项目打包命令是npm run build，生成dist目录。把dist目录上传到服务器后，配置Nginx的server块。这里给出一个经过验证的配置：

server { listen 80; server_name property.example.com; root /usr/share/nginx/html/property-front; index index.html; location /api/ { proxy_pass http://127.0.0.1:8080/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } location / { try_files $uri $uri/ /index.html; } }

try_files $uri $uri/ /index.html;这段配置是SPA路由的核心，不管用户刷新哪个子路由，Nginx都返回index.html，交给Vue Router接管。如果不加这段，刷新二级页面就会404，这是Vue3项目部署最常见的坑。

静态资源缓存问题也要处理。因为Vue3打包生成的JS和CSS文件名带hash值，可以给assets目录配置强缓存。在上面location /配置里加一条location /assets/ { expires 30d; add_header Cache-Control "public, immutable"; }，用户二次访问加载速度提升非常明显。

5.4 我实际踩过的坑与排查技巧

这套项目从拿到到部署，前前后后我排了不少问题，挑几个有代表性的分享，保准你能用得上。

坑一：数据库连接报Public Key Retrieval is not allowed。MySQL8.0默认使用caching_sha2_password认证插件，JDBC连接时如果没配置allowPublicKeyRetrieval，会报这个错。解决办法很直接，在JDBC连接串上加参数allowPublicKeyRetrieval=true&useSSL=false&serverTimezone=Asia/Shanghai。时区参数必须指定，否则插入时间字段会差8个小时。

坑二：MyBatis-Plus分页失效，查出来的数据不分页。这个现象一般是分页插件没有注册成功。检查是否配置了MybatisPlusInterceptor的Bean，注意分页插件的类名是PaginationInnerInterceptor，包路径是com.baomidou.mybatisplus.extension.plugins.inner。配置了还是不生效，检查Mapper的selectPage方法第一个参数是否有@Param注解，版本迭代后有些写法会有变化。

坑三：前端启动后接口请求404，但后端接口用Postman测是通的。如果配置了Vite代理，检查请求路径是否以/api开头，代理规则是按前缀匹配转发的。代理配置里rewrite路径也要确认，是否已经去掉了前缀。如果后端接口实际路径就是/api/house/list，代理到8080时直接透传即可，不需要rewrite。

坑四：Element Plus的表格样式不对或者组件完全没有渲染。优先检查你是不是用全量引入，import ElementPlus from 'element-plus'之后记得app.use(ElementPlus)。如果用了按需自动导入，检查unplugin-vue-components插件是否在vite.config.js的plugins数组里正确注册。另外，Element Plus的中文语言包默认不加载，需要手动引入zh-cn并配置给ElConfigProvider组件。

坑五：部署后前端页面能打开但接口超时。大多数情况是Nginx的proxy_read_timeout默认60秒，但后端接口处理耗时长。如果是文件上传或者导出Excel这种耗时操作，在location /api/块里配置proxy_read_timeout 300s;。还有可能是服务器防火墙没放行8080端口，用firewall-cmd --list-ports或者云控制台的安全组规则检查一遍。

5.5 如何用Jenkins做自动化部署

项目稳定运行一段时间后，手动上传jar包和dist目录太费劲了，我给这套系统加了一套Jenkins自动部署流水线。Jenkins服务器上安装好JDK、Maven、Node.js插件，创建流水线任务，配置源码仓库地址（Git）后，执行三个阶段的脚本。

第一阶段拉取代码，第二阶段分别打包后端和前端，前端构建时npm ci代替npm install保证依赖版本一致。第三阶段通过SSH插件把jar包和dist目录推送到目标服务器，然后执行systemctl restart property重启后端服务，前端直接覆盖Nginx的静态目录。整个过程从提交代码到上生产环境，5分钟以内完成，而且每次构建都有日志记录，出了问题能迅速回溯到是哪个代码提交引起的。

5.6 二次开发与扩展建议

跑通项目只是开始，这套系统的价值在于二次开发。我提供几个实际可操作的扩展方向。

如果要做数据可视化大屏，可以在现有统计数据基础上增加接口，用ECharts实现。项目里我预留了看房热力分析和成交趋势的统计接口，把DAO层写好之后，前端接上大屏模板就能展示。

如果要对接微信公众号，可以增加微信授权登录。后端引入wx-java-mp的SDK，申请公众号开发者权限，把OAuth2授权流程接入现有的JWT认证体系。用户通过微信进入后首次授权绑定手机号，系统自动创建客户记录并分配归属置业顾问。

如果要做移动端适配，可以基于uni-app或者Taro写一套H5，接口完全复用现有后端的，只需要前端重新实现页面，开发效率会很高。

6. 源码文档结构导读与学习方法建议

6.1 拿到源码后从哪里开始看

打开项目的第一件事，我建议先别急着跑，把目录结构浏览一遍。后端重点看controller包里有哪些接口，一层层往下跟，看Service怎么实现业务，Mapper怎么写SQL，回到数据库看表结构。前端重点看router里的路由配置和api目录的接口定义，对应到页面上理解每个功能是怎么串联起来的。

项目里的文档目录包含需求分析说明、数据库设计文档、接口文档（Swagger导出的）和部署手册。Swagger UI建议启动后访问http://localhost:8080/swagger-ui/index.html，既能看接口文档，又能在线调试接口，比看PDF文档直观多了。

6.2 迁移到自己的业务场景要注意什么

这套系统的核心框架和权限模型可以直接复用到很多业务场景，比如二手房中介管理、租赁平台后台、物业管理系统。迁移时主要改三个地方：数据库表结构按新业务调整、实体类和Mapper文件同步修改、前端菜单和页面文案替换。

这里要特别提醒，改了业务表之后，原有的查询逻辑、统计SQL、导入导出模板都要仔细检查。比如房源表改为商铺表，面积、租金这些字段的变化会直接影响到列表页面和表单组件，不能只改字段名，要检查整个数据流的兼容性。

6.3 我的个人实操心得

最后分享一个我的切身体会。刚拿到这套代码时，我也犯过“先改代码后看文档”的毛病，结果把原有功能改坏了还不知道。后来老老实实花了一个晚上把需求文档和数据库设计文档通读了一遍，再动手就顺畅很多。

这套项目最好的学习方式是带着问题上手。比如想搞清楚“预约看房这个流程有哪几个状态节点”，就去数据库里看visit表的字段设计，再看后端visitController的接口逻辑，最后到前端页面上操作一遍，把状态流转画出来。实践一遍比看十遍文档都管用。

有一个建议：有条件的话，自己手写一遍登录认证的流程，从JWT工具类到Spring Security过滤器，不抄代码，理解结构之后再参照源码检查。做完这一步，你对整个系统的理解会真正上一个台阶，面试的时候被问到权限设计也能讲出自己的实战体会，而不是停留在概念层面。