每年到了毕业季总能看到一堆人抱着“SpringBootVue”的组合在论坛里蹲源码、找毕设。说实话这个组合早就成了Java Web方向毕业设计的标准答案但真正的问题是源码拿到手之后你能不能讲清楚、改得动、跑得起来。这篇东西我按一个完整可交付的“旅游景点导游平台”项目来拆围绕SpringBoot、Vue、SQL脚本和接口文档这几块把从数据库设计到前后端联调的完整链路捋一遍既适合拿来当毕设参考也适合想正经学一遍前后端分离项目的同学。1. 项目整体设计与选题思路1.1 这个平台到底解决了什么问题你说一个旅游景点导游平台核心用户其实是两类人一类是到桂林旅游、想找景点信息、想看导游讲解的游客另一类是管理景点资料、发布导游信息的平台运营方。游客端的需求很直白——打开页面能看到景点列表、景点详情、导游介绍甚至能根据景点名称或地区搜索运营端的需求则是要把这些数据管起来增删改查、上下架、录入导游信息。很多同学在做这类毕设的时候容易犯一个毛病就是把“导游平台”做成一个只展示静态景点介绍的网站。这其实等于没做。真正的导游平台至少要有一个“导游资源”的概念每个景点可以关联一个或多个导游导游有简介、有擅长路线、有讲解风格标签。游客可以看景点也可以看“哪位导游负责这个景点”。这套关系在数据库里就是一张关联表的事但在功能上它决定了你系统里到底有没有“平台”的味儿。别小看这一点。答辩的时候老师问“你的系统业务是什么”你能说出“游客通过平台获取景点信息并选择合适的导游讲解”和你只能说“游客看景点介绍”完全是两个档次。1.2 为什么选SpringBootVue这套组合SpringBoot Vue 前后端分离几乎已经成了Java Web毕业设计的默认模板。原因其实很实在SpringBoot把Spring MVC那一大堆XML配置全部简化掉了你写一个RestController就能吐接口Vue则有完整的前端生态组件化开发让页面组织起来很清晰。对于一个人要在一个学期内完成整套系统的学生来说这是学习成本最低、出活最快、而且招聘市场上最认可的组合。从后端角度看SpringBoot 2.x版本配MyBatis-Plus是现阶段最主流的搭配。MyBatis-Plus的BaseMapper让你连SQL都少写一大半单表CRUD真的就只是几行代码的事。当然不要因为有了它就连SQL都不学这个概念你一定要清楚MyBatis-Plus解决的是单表通用操作真正复杂的多表联查、分组统计该写SQL还是要写。前端Vue这边我用的是Vue 2 Element UI。虽然Vue 3和Element Plus已经很成熟了但你要考虑一个现实问题网上的教程、论坛里的报错帖子、甚至你导师手里可能存着的参考代码绝大多数还是Vue 2的。毕设求稳Vue 2不是技术落后而是生态成熟你卡住的时候能搜到答案比什么都强。前后端分离还有一个好处接口文档变得非常重要。这也是这个项目里为什么要专门准备一份接口文档的原因。前后端分离之后前端同学和后端同学是并行开发的如果没有一份统一的接口约定两边各自写完一对接简直是一场灾难。1.3 系统核心模块拆解一个完整的景点导游平台按我的习惯会拆成下面这几个模块用户模块游客注册登录、个人信息管理后端用JWT做无状态登录认证。景点模块景点列表分页展示、景点详情、按名称/地区搜索、景点图片管理。导游模块导游信息维护、导游与景点关联、按景点查询导游。评论收藏模块游客可以对景点评论、收藏景点好评率是加分项。管理后台管理员对景点、导游、用户进行统一管理包含数据统计看板。模块划分的意义在于它直接影响你数据库的表设计和接口粒度。很多同学上来就建表建到一半发现字段关系理不清就是因为没有先在脑子里面把模块边界画出来。模块定下来表结构才能定下来接口才能定下来。2. 数据库设计与SQL脚本要点2.1 表结构设计思路数据库是整套系统的地基。地基没打好后面写接口的时候到处补字段、改结构那体验别提多难受了。按照上面拆的模块我会把数据库设计成7张表表名用途关键字段user用户表id, username, password, nickname, avatar, role, create_timescenic景点表id, name, region, level, price, description, cover_image, statusguide导游表id, name, avatar, language, years, tags, introduction, scenic_idcomment评论表id, user_id, scenic_id, content, rate, create_timefavorite收藏表id, user_id, scenic_id, create_timeadmin管理员表id, username, password, real_name, create_timenotice公告表id, title, content, create_time核心关系我解释一下。guide表里直接放一个scenic_id表示这个导游属于哪个景点。这是典型的一对多关系一个景点有多个导游一个导游只属于一个景点。如果你想做得更灵活一点比如一个导游可以带多条线路那就要拆第三张关联表guide_scenic出来。毕设级别用直接外键就可以了但思路要能说清楚。user表里的role字段我之前犹豫过后来决定保留。虽然一般系统会把管理员单独放一张表但通过role字段区分游客和管理员能让登录逻辑变得非常统一——同一个登录接口查user表拿到角色如果是管理员就直接跳后台。这个做法在中小型系统里非常常见省一张表也省一套登录逻辑。2.2 SQL脚本编写细节与初始化数据SQL脚本是整个项目交付物里最容易被人忽略、但实际最要命的一个文件。老师要验收项目的时候第一步就是看你能否把数据库跑起来。如果SQL脚本一执行就报错或者字段对不上那就算你代码写得再漂亮也白搭。我写SQL脚本时有几个习惯都在这个项目中用上了第一建库建表语句必须带IF NOT EXISTS插入数据前先查重。这样脚本重复执行不会报错。别笑真有同学交上去的脚本执行到一半崩了就是因为第二次跑的时候主键冲突。CREATE DATABASE IF NOT EXISTS guide_platform DEFAULT CHARACTER SET utf8mb4; USE guide_platform; CREATE TABLE IF NOT EXISTS scenic ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(100) NOT NULL COMMENT 景点名称, region VARCHAR(50) COMMENT 所在区域, level VARCHAR(10) COMMENT 景区等级, price DECIMAL(10,2) DEFAULT 0 COMMENT 门票价格, description TEXT COMMENT 景点介绍, cover_image VARCHAR(255) COMMENT 封面图地址, status TINYINT DEFAULT 1 COMMENT 1上架 0下架, create_time DATETIME DEFAULT CURRENT_TIMESTAMP );第二表结构里必须写COMMENT。注释这东西平时写代码你可能嫌烦但写SQL脚本的时候每张表、每个关键字段的注释都是答辩时的救命稻草。老师一看你的注释就知道你懂这个字段是干什么的。第三初始化数据要贴近真实场景。既然是桂林旅游平台那像漓江、象鼻山、龙脊梯田、两江四湖、银子岩这些景点必须出现在初始化脚本里。导游数据也一样名字、语种、服务年限、擅长路线都要像模像样。真实感的初始数据在演示系统的时候特别加分一眼就能看出你是认真做过功课的。2.3 字段设计中的几个坑第一坑密码字段。很多同学的user表里password字段就定义一个VARCHAR(20)然后明文存进去。不是我看不起这种写法是这种行为放到答辩现场真的会被老师抓住不放。正确做法是用BCrypt加密加密后的字符串长度是60个字符左右所以VARCHAR(100)才是安全的长度。明文存密码这种问题属于教师答辩时最典型的“安全性追问”。第二坑金额字段。景点的门票价格千万不要用FLOAT或者DOUBLE。二进制浮点数在比较和计算的时候会出现0.1 0.2 0.30000000000000004这种问题。数据库里关于钱的正确字段只有DECIMAL也就是定点数。第三坑时间字段。统一用DATETIME配合DEFAULT CURRENT_TIMESTAMP自动填充创建时间。更新时间的字段加上ON UPDATE CURRENT_TIMESTAMP属性这样每次更新记录时时间自动变不需要在Java代码里手动赋值。3. 后端核心接口实现3.1 项目结构分层与接口规范SpringBoot后端项目的目录结构我推荐按“controller / service / mapper / entity”四层来组织。这是最经典的Java Web分层方式也是绝大多数毕设会采用的方式。模块化分包建议用common存放统一返回结果、统一异常处理、JWT工具类用config放跨域和拦截器配置把业务代码和基础设施分开看着清爽也方便老师检查代码质量。统一返回结果这块是很多新手容易忽略的。如果不做统一封装每个接口的返回格式都不一样前端取值的时候就非常痛苦。我的做法是定义一个Result类包含code、message、data三个字段public class ResultT { private Integer code; private String message; private T data; public static T ResultT success(T data) { ResultT result new Result(); result.setCode(200); result.setMessage(success); result.setData(data); return result; } public static T ResultT error(String message) { ResultT result new Result(); result.setCode(500); result.setMessage(message); return result; } }这个类写好之后所有接口返回Result.success(xxx)前端统一判断code 200再取data联调的时候能少吵一半的架。这也是我在接口文档里重点约定的一条所有接口统一返回格式前端不管拿到什么接口解析方式都是一样的。3.2 用户认证与JWT登录登录认证这块我用的方案是JWT全称JSON Web Token。它的核心思想是用户登录成功后后端生成一个加密的Token字符串返回给前端前端把Token存下来之后每一次请求都在请求头里带上Authorization: Bearer token后端验证这个Token是否有效。为什么不用Session因为前后端分离之后后端不再View渲染页面Session依赖的Cookie跨域很麻烦。而JWT是无状态的后端不需要存任何会话数据验签通过就放行。这对以后部署成多实例服务也是有好处。JWT的结构分三段Header头部、Payload载荷、Signature签名。Payload里可以放用户ID、用户名、角色等信息。要注意的是JWT默认只是Base64编码不是加密所以不要往Payload里放密码之类的敏感信息。关键的签名是用HMAC SHA256算法做的密钥放在后端的配置文件中不能泄露。具体到项目里我用一个JwtUtil类负责生成和解析Token用Spring Boot的拦截器HandlerInterceptor统一做登录校验。放行的路径比如首页景点列表、游客注册登录通过WebMvcConfigurer里的addInterceptors方法配置其余接口全部拦截Configuration public class WebConfig implements WebMvcConfigurer { Resource private JwtInterceptor jwtInterceptor; Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(jwtInterceptor) .addPathPatterns(/api/**) .excludePathPatterns(/api/user/login, /api/user/register, /api/scenic/**); } }这里的/api/scenic/**放行也是有意为之的景点信息属于公开数据游客未登录也应该能看但评论、收藏这类写操作就必须登录。3.3 景点与导游核心接口示例景点模块的接口最核心的就是分页查询和详情查询。分页查询一定要支持三个参数当前页pageNum、每页大小pageSize、搜索关键字keyword。我用MyBatis-Plus的Page对象来实现示例代码如下GetMapping(/api/scenic/page) public ResultIPageScenic getScenicPage( RequestParam(defaultValue 1) Integer pageNum, RequestParam(defaultValue 10) Integer pageSize, RequestParam(required false) String keyword) { LambdaQueryWrapperScenic wrapper new LambdaQueryWrapper(); wrapper.eq(Scenic::getStatus, 1); if (keyword ! null !keyword.isEmpty()) { wrapper.like(Scenic::getName, keyword) .or().like(Scenic::getRegion, keyword); } wrapper.orderByDesc(Scenic::getCreateTime); return Result.success(scenicService.page(new Page(pageNum, pageSize), wrapper)); }这里有个你想不到的细节为什么分页查询里景点状态要写死为status 1因为游客端只能看到上架的景点而管理后台需要看到全部包括下架的。同一个接口我在管理后台的Controller里单独写了一个/api/admin/scenic/page不加status条件两套接口各管各的。如果你只用一个接口靠传参控制也不是不行但那样逻辑耦合后面改起来容易出bug。导游接口同理。按景点查导游的接口路径我定义为GET /api/guide/listByScenicId?scenicId1并且要求scenicId不能为空否则直接返回错误。这种防御性校验虽然简单但它是接口健壮性的体现接口文档里必须写明哪些参数是必填的。3.4 接口文档如何整理接口文档是项目交付物的重要部分很多同学把这个当成“写文档”随便弄个Word文件把接口路径一列就完了。这完全不行。一份能用的接口文档每个接口至少要包含接口路径、请求方式、请求参数名称、类型、是否必填、说明、返回示例、错误码说明。我拿到这个项目的时候整理接口文档用的是Markdown格式因为GitHub和Gitee都能直接渲染浏览起来特别方便。文档结构按照模块分章节每个模块下逐个列接口。比如景点模块的文档片段### 3.1 景点分页列表 - 请求地址GET /api/scenic/page - 请求参数 | 参数名 | 类型 | 必填 | 说明 | | --- | --- | --- | --- | | pageNum | int | 否 | 当前页码默认1 | | pageSize | int | 否 | 每页数量默认10 | | keyword | String | 否 | 景点名称或地区 | - 返回示例 { code: 200, message: success, data: { records: [], total: 20, size: 10, current: 1 } }这里有个技巧接口文档里的返回示例不要手写直接从Swagger或者实际接口调用里复制真实的JSON返回。手写很容易漏字段或者写错类型坑了前端不说答辩被问到也说不清。4. 前端Vue页面开发与联调4.1 前端工程搭建与路由设计前端项目我用Vue CLI脚手架生成项目结构是标准的src/views放页面组件、src/router放路由配置、src/api放接口请求封装、src/utils放axios实例和工具函数。页面方面游客端我规划了首页、景点列表、景点详情、导游列表、个人中心五个主页面管理后台则是景点管理、导游管理、评论管理、用户管理、数据概览五个页面。路由设计这里要展开说。Vue Router有两种模式hash和history。毕设项目我推荐用hash模式因为history模式刷新页面时后端必须有对应的路由重写规则否则页面会404。部署到Tomcat里尤其要注意history模式需要特殊配置而hash模式什么都不用管URL里多个#符号而已无所谓。路由守卫是另一个值得写的点。管理后台的页面必须要登录且角色是管理员才能访问。我用Vue Router的beforeEach全局守卫来做控制router.beforeEach((to, from, next) { const token localStorage.getItem(token); const role localStorage.getItem(role); if (to.path.startsWith(/admin) (!token || role ! admin)) { next(/login); } else { next(); } });前端路由守卫和后端拦截器是双重保险。哪怕有人绕过前端守卫直接发请求后端的JWT拦截器也会把没有Token的请求拦下来。这个逻辑要做到后端为主、前端为辅思路要清晰。4.2 页面核心组件实现景点列表页是整个系统的门面也是老师最先看到的功能页面。我用Element UI的Card卡片组件做景点展示每个卡片包含封面图、景点名称、等级、地区、门票价格。搜索框放在页面上方输入关键字回车或者点击搜索按钮调用分页接口。整套逻辑其实不复杂但有几个细节能体现你的专业度图片地址的拼接要有统一规范。数据库里存的是相对路径/images/guilin/xiangbishan.jpg前端请求接口返回的原始数据里不能直接拿来用因为主机地址部分是缺失的。我在utils里写了一个方法用环境变量里的VITE_BASE_URL来拼完整地址。这个做法在Vue项目里很常见比在前端写死一个IP强得多。分页组件的current-page和page-size要与后端分页接口的返回数据绑定。Element UI的Pagination组件的total要赋值为接口返回的total字段否则分页不能正确显示总页数。这些看起来是小事但是前后端字段对不上也会导致分页失效。景点详情页的设计上我用了一个el-tabs组件分成“景点介绍”“导游信息”“用户评论”三个Tab。导游信息Tab里前端通过scenicId调/api/guide/listByScenicId接口用户评论Tab里则调/api/comment/list?scenicIdxxx接口。Tab加接口的组合能让详情页的信息层次非常清楚也方便扩展。4.3 前后端联调与跨域问题前后端联调最经典的问题就是跨域。前端开发时跑在localhost:8080后端跑在localhost:9090浏览器会见两个端口不同直接判定为跨域请求然后把响应拦掉。解决办法有几种后端加CrossOrigin注解单接口级麻烦后端全局CORS配置类推荐一次配完前端Vite或Webpack配proxy代理用于生产环境部署。我的做法是在后端写一个全局配置类Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/api/**) .allowedOriginPatterns(http://localhost:*) .allowedMethods(GET, POST, PUT, DELETE) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }注意一个细节在allowedOriginPatterns里不要写*因为allowCredentials(true)和通配符*是冲突的会被浏览器拒绝。localhost:*表示允许所有端口比一个一个写要省事。联调时我还常遇到一个问题前端请求能到达后端但返回不了。排查思路是先打开浏览器F12的Network面板看请求有没有发出再看请求的响应状态码如果是401说明是拦截器拦了403说明是跨域配置不对404说明是路径写错了——尤其是Controller里的RequestMapping类级路径加/api后前端请求路径必须完全一致。这种排查思路要刻在脑子里它能帮你省下来大量跟同学互相甩锅的时间。5. 常见问题与排查技巧实录5.1 数据库连不上与时区问题这个项目的数据库连接报错99%的原因集中在三个方面URL写错、驱动版本不匹配、时区不对。SpringBoot 2.x默认用的MySQL驱动是com.mysql.cj.jdbc.Driver这个驱动对时区要求很严格连接串里不带时区参数会直接报Server returns invalid timezone的异常。解决办法是在application.yml里加上serverTimezoneAsia/Shanghaispring: datasource: url: jdbc:mysql://localhost:3306/guide_platform?useSSLfalseserverTimezoneAsia/ShanghaicharacterEncodingutf8mb4 username: root password: 你的密码 driver-class-name: com.mysql.cj.jdbc.Driver还有个容易踩的坑password直接写在application.yml里。如果是自己学习无所谓但如果是交付项目建议把密码改成环境变量占位符${DB_PASSWORD}然后在启动参数里传入。这个细节在答辩的时候提出来老师会认为你有生产环境的意识。5.2 接口返回中文乱码中文乱码这个问题的根源是编码不一致。数据库表用了utf8mb4但连接串没指定characterEncoding或者后端接口返回时没有设置produces为application/json;charsetUTF-8。SpringBoot里最简单的处理方式是在application.yml里强制设置响应编码server: servlet: encoding: charset: UTF-8 force: trueforce: true这个配置很关键它会让所有响应强制使用UTF-8不管请求头里写的什么编码。如果你已经配了这个还是会乱码那就把目光转向数据库连接串检查是不是没有加characterEncodingutf8mb4。把URL里加上这个参数重启基本能解决。5.3 打包部署时遇到的坑前后端分离项目的打包部署只要遇到了十有八九是静态资源路径问题。前端执行npm run build后生成dist目录你可以选择两种方式部署一是把dist放到Nginx里配置反向代理转发/api请求到后端二是把dist直接放到SpringBoot的src/main/resources/static目录下打成一个大Jar包。毕设项目我推荐第二种因为省事——一个Jar包解决全部。但有个问题要注意SpringBoot默认只能识别static目录下的index.html如果你用了Vue Router的history模式刷新任意非首页路径都会404。解决办法就是在后端加一个路由重定向Controller public class IndexController { RequestMapping({/{path:[^\\.]*}, /**/{path:[^\\.]*}}) public String forward() { return forward:/index.html; } }这段代码的意思是所有不带文件后缀的路径全部转发到index.html让前端路由自己去解析。[^\\.]*这个正则过滤了带点号的路径资源比如logo.png避免把静态资源请求也转发出去。5.4 开发过程中最经典的三个报错第一个是Whitelabel Error Page。后端启动成功但访问某个路径返回这个默认错误页意味着Controller没有匹配到这个路径。排查重点是看RequestMapping的完整路径尤其注意类级和方法级路径的拼接是否有歧义。第二个是Invalid bound statement (not found)。Mapper接口定义了方法但对应的XML文件里没有这个id的SQL或者XML文件路径与Mapper接口路径不一致。我的习惯是让XML文件和Mapper接口放在同一个包目录下并且开启mapper-locations通配扫描mybatis-plus: mapper-locations: classpath*:mapper/**/*.xml第三个是Consider defining a bean of type xxxMapper in your configuration。启动时提示找不到Mapper的Bean99%的原因是没有在主启动类上加MapperScan注解或者注解包的路径写错了。加上它就好。5.5 问题排查的通用方法论把所有问题收敛到最后我发现一个通用排查链条先看控制台日志报错信息再看前端Network面板请求状态最后看数据库里的数据状态。Log记录后端异常、Network记录接口交互、数据库记录数据结果三层定位就是做项目调试的核心方法。后端日志看什么看堆栈第一行的异常类型和描述NullPointerException就是空指针、DuplicateKeyException就是主键冲突、BadSqlGrammarException就是SQL写错。把这些常见异常的名字和含义记住了以后看日志就不用一行一行读了扫一眼就知道大致方向。前端Network面板看什么看HTTP状态码和响应内容。200不代表一定成功还要看响应体里的code字段500看后端日志401看Token是否过期404首先检查地址拼写。这套方法熟练之后联调速度能提升一倍。6. 项目答辩要点与扩展方向6.1 答辩时容易被问到的问题毕设答辩的套路其实很固定老师翻来覆去就那几个问题但答不好的话项目做得再好也容易翻车。我列几个高频问题你可以提前想好答案“你的系统安全性怎么考虑”——从密码加密BCrypt、登录认证JWT、后端参数校验、SQL注入预防用MyBatis-Plus预编译拒绝字符串拼接这几个角度答基本滴水不漏。“为什么用Redis做缓存没你的系统有哪里需要缓存。”——如果你项目里没有用到Redis要能坦诚地说系统当前的数据量不需要缓存但要能说出在什么场景下需要加比如景点详情页热点数据。加了这个回答老师会觉得你有架构思维。“你的系统有哪些创新点”——这个问题是送分题也是送命题。别说什么“使用前后端分离技术”这种话。你可以说“系统把景点、导游、评论、收藏整合成闭环游客能在一个平台完成信息获取到服务选择的完整链路”这才是你说得清楚的创新。“项目都有哪些角色权限是怎么控制的”——务必把你的用户角色游客、管理员说清楚然后把后端拦截器如何拦截、前端路由守卫如何控制、管理员接口如何独立开这三个层次答出来。在我看来答辩的关键不在于把每个问题都答成标准答案而在于你对自己项目代码的熟悉程度。每一行核心代码都要能解释为什么这么写这才算真正掌握了这个毕设。6.2 项目还能怎么扩展如果你只想及格做到上面的内容已经够了如果你想拿个高分那我建议你在这个基础上有针对性地做一点扩展。第一个扩展方向是推荐系统。毕设级别的推荐系统不需要什么深度算法简单的“基于用户浏览历史推荐同地区景点”就能支撑一篇很有说服力的论文。算分逻辑可以用“用户最近浏览的景点地区标签 同地区其他热门景点排序”实现思路清晰、可解释性强。第二个扩展方向是地图可视化。接入像Leaflet或高德地图JS API把景点列表渲染到地图上用户在地图上直接点击景点标记查看详情。这项工作的技术难度不大但视觉效果非常出彩答辩现场算是很有冲击力的演示素材。第三个扩展方向是统计看板。管理后台加一些简单的统计报表——按地区统计景点数量、按月统计访问量、热门景点Top10。用ECharts画折线图、柱状图、饼图不需要多复杂但能让你的项目从“功能型系统”变成“数据型系统”这个层次感是完全不同的。第四个扩展方向是提升非功能性能。把景点详情页做成静态化处理或者给热点数据加一层本地缓存把上传的图片存到OSS而不是本地磁盘。这些都属于“一句话就能解释清楚价值”的优化适合在论文的“不足与展望”部分写也适合在答辩时回答问题。6.3 我在实际开发中的几点感受最后说点掏心窝子的话。就是这个项目我在实际复盘的时候发现最花时间的根本不是写代码而是“改代码”——就是那种今天写完明天觉得不好推倒重来的过程。数据库字段命名不统一后端返给前端的字段名没和文档对齐前端在页面上把后端字段名的scenicId写成了scenic_id联调时报错半天结果是字段名不一致。这些教训印在脑子里以后我再做项目就养成了一个习惯先写接口文档再定数据库字段最后才写代码。另外补充一个很实用的小建议做这种带管理后台的系统一定提前准备一套演示用的“排练脚本”包括几条路径游客注册登录 → 浏览桂林景点列表 → 查看漓江详情 → 查看导游信息 → 提交评论管理员登录 → 新增景点 → 编辑导游信息 → 查看用户列表。演示的时候按这套脚本走每一步都要提前确认数据是存在的、按钮是可点的。答辩现场的突发状况九成都是因为演示时点了某个按钮发现数据为空或者页面报错。做毕设这件事说辛苦是真辛苦但回头看它其实是你把课堂上学的所有东西串成一条线的机会。把这个项目从头到尾啃下来SpringBoot和Vue怎么配合、数据库表怎么设计、接口怎么定义你就都有了切身的体感这份体感比代码本身更值钱。