这两年我带过的毕设里出现频率最高的一类题目就是电商后台管理系统尤其是SpringBoot Vue这套技术栈的组合。很多同学在选题时一眼相中它理由是“这题目听着就稳妥”也确实稳妥。它不像算法类题目那样需要很强的理论功底也不像纯硬件项目那样受条件限制只要你把这个系统的业务逻辑理清楚把CRUD做得规范把状态流转和权限控制讲明白答辩时就能拿出足够扎实的东西给老师看。1. 项目拆解这个“后台管理系统”到底要做成什么样1.1 为什么“后台”比“前台”更适合做毕业设计很多人一开始想做商城前台页面觉得用户端界面好看能放购物车、能模拟下单演示起来花哨。我通常会劝他们冷静一下。前台商城的问题在于它的本质是交互流程真正的复杂性全部集中在后端接口和业务规则上而前台页面本身又被各种UI框架统一化很难做出区分度。反观后台管理系统它的边界非常清晰功能的维度多到足够你展开写商品管理、分类管理、订单管理、会员管理、库存管理、轮播图配置、数据统计、权限管理、操作日志。这些模块的难点不在“写得出来”而在“写得好”。比如订单状态怎么流转、库存和订单之间怎么保持一致性、不同角色能看到哪些菜单和按钮这些都是在实际开发中才会碰到的逻辑问题也是答辩时最能展示你思考过程的素材。1.2 核心角色与功能边界在开始写代码之前先把系统的使用者捋清楚。这套商城后台管理系统至少包含两类角色第一类是超级管理员负责整个平台的全局配置包括管理员账号的创建和分配、角色权限的设置、基础数据的维护。第二类是运营人员负责日常业务操作比如上架商品、调整价格、处理订单、审核评论等。这两类角色的权限天然不同。超级管理员能看到系统管理模块运营人员只能看到商品、订单、会员这些业务模块。这个差异就是RBAC基于角色的访问控制模型的经典落地场景。你要是能把权限表设计得清楚把拦截器或者路由守卫的校验讲明白答辩时这就是一个非常稳的亮点。功能边界上我建议把系统拆成六个核心模块后台登录与鉴权、商品管理、商品分类、订单管理、会员管理、数据统计。再扩展两个可选模块作为加分项操作日志和公告管理。不要把功能做得太散也不要贪多能把这六个模块之间的数据关联讲清楚就已经超过绝大多数同类题目了。1.3 一套后台系统到底折射了多少业务这就引出一个关键认知你做的不只是一堆数据表格的增删改查。商品有上下架状态那就要有状态字段和对应的时间记录用户下单后订单有创建、支付、发货、完成、取消这些环节那就要有状态枚举和流转规则商品库存和订单扣减要保证不超卖那就要有事务控制和锁或者乐观锁的处理思路。这些都是真实电商系统里每天都在面对的问题。所以你在准备这个项目时心里要有个底它的业务复杂度和真实工业项目之间的差距最重要的不是技术框架而是对业务状态的建模能力。你写出来的每一个state字段、每一个if判断背后都是真实世界的交易规则。2. 技术选型为什么SpringBoot Vue成了黄金组合2.1 SpringBoot到底解决了什么问题如果倒退七八年用Spring MVC写一个Web项目你要手动配置一堆XML文件要处理各种Bean的定义要操心容器怎么启动。SpringBoot的核心贡献是让这些“约定”变得自动化通过自动配置把大部分重复劳动接管了你只需要关注自己的业务代码。这不只是对开发效率的提升对做毕设这件事更现实的意义是它大幅降低了环境搭建的门槛。你不需要在论文里写上一大堆环境配置的细节只需要在一个入口类上标注启动注解系统就能跑起来。对答辩老师来说这种干净整洁的工程结构也更容易看懂。2.2 为什么前端选Vue而不是React这个选择其实没有绝对的对错但放在毕设场景下Vue有它的明显优势。Vue的中文文档足够完善上手曲线比React平缓而且国内社区里针对毕设场景的教程和工具链资料非常多遇到问题搜一圈基本都能解决。更关键的是Vue配合Element UI或者Element Plus组件库做后台管理系统几乎是“装配式”开发。表格、表单、弹窗、分页、树形控件这些后台管理的高频组件都是现成的你只需要关注数据绑定和交互逻辑不用花费大量时间在样式细节上。对毕设来说时间永远是不够用的把精力省到业务上是很划算的选择。2.3 后端技术栈的具体组成后端我这里推荐一套非常成熟、文档很多、面试也能聊的组合JDK 8或11SpringBoot 2.xMyBatis-PlusMySQL 5.7或8.0Redis可选用于缓存Token和热点数据JWT做无状态登录鉴权Maven做依赖管理这里面值得多说一句的是MyBatis-Plus。它既有MyBatis的灵活SQL控制能力又内置了通用CRUD方法你写一个Mapper接口继承BaseMapper就能直接使用插入、删除、根据ID查询这类基础方法不用每个实体都手写SQL。这对毕设阶段的开发速度是巨大的提升。它还有一个我特别推荐的功能分页插件。实现分页查询只需配置一个拦截器然后在代码里传入分页参数剩下的SQL拼接、总数统计都由框架完成。文章后面写商品列表时我会具体说这个。2.4 数据库设计的基本盘数据库是整个系统真正的基座。我建议把所有表列举出来让它们的关系在脑子先完整过一遍sys_user管理员表sys_role角色表sys_menu菜单/权限表sys_user_role用户角色关联表sys_role_menu角色菜单关联表product_info商品表product_category商品分类表product_stock_log库存变动日志表order_master订单主表order_detail订单明细表member_user会员表operation_log操作日志表这些表之间是清晰的主外键关联。比如订单主表和订单明细表是一对多关系商品表和分类表是多对一关系管理员和角色是多对多关系。数据库设计做到这个粒度再往下写代码就会有章法很多。2.5 选型时的两个备选思路如果你基础较弱担心撑不起SpringBoot Vue双端开发可以退一步考虑SpringBoot Thymeleaf的纯后端方案页面交给模板引擎渲染。这个方案的工作量集中在后端少了一层前后端联调的复杂过程但展示效果要朴素一些。如果你基础不错想冲一下高分可以在现有架构上引入Redis缓存、RabbitMQ消息队列甚至拆出专门的订单服务模块但一定要量力而行别因为引入太复杂的技术导致最后连基本功能都没做完。3. 从零搭建项目环境准备与工程初始化3.1 环境准备清单先把环境凑齐这步别偷懒版本不同会有各种奇怪问题。JDK 8推荐JDK 8或11太新的版本有的依赖可能还不兼容Maven 3.6Node 14Vue项目构建需要MySQL 5.7或8.0记得设置好字符集utf8mb4IDEA后端开发 VSCode前端开发Navicat或其他的数据库客户端工具这些工具的安装本身不复杂但要注意环境变量的配置。特别是JDK和Maven配置不好后面Maven依赖拉不下来容易被卡住一整个下午。3.2 后端项目初始化打开IDEA新建Spring Initializr项目设置好group和artifactId。这里有一个容易踩的坑Spring Boot版本不要选最高的3.x如果你的MyBatis-Plus版本没跟上可能会遇到兼容性问题。选2.7.x或者2.5.x就行足够稳定。在pom.xml中引入需要的依赖dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3.1/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scoperuntime/scope /dependency dependency groupIdio.jsonwebtoken/groupId artifactIdjjwt/artifactId version0.9.1/version /dependency dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId optionaltrue/optional /dependency这些依赖里Lombok是很提升开发体验的它自动生成getter、setter、构造器代码写起来会干净很多。JJWT负责生成和解析Token是整个登录鉴权的核心。3.3 配置application.yml写好数据源配置是项目跑起来的第一步。注意数据库名称、用户名、密码对应好你自己的环境。server: port: 8088 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/shop_admin?useUnicodetruecharacterEncodingutf8mb4serverTimezoneAsia/Shanghai username: root password: 123456 servlet: multipart: max-file-size: 20MB max-request-size: 20MB mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl map-underscore-to-camel-case: true global-config: db-config: id-type: automap-underscore-to-camel-case这个配置是MyBatis自动把下划线字段名映射成驼峰属性名的关键比如数据库的product_name字段能直接映射到实体的productName属性。很多同学在这上面踩过坑手动写resultMap写得很痛苦其实一个配置就解决了。3.4 Vue前端项目初始化前端项目的创建更直白用Vue CLI或者Vite初始化一个项目然后安装依赖。npm create vue3 # 或者 vue create shop-admin-web随后安装Element Plus和Axios以及Vue Routernpm install element-plus axios vue-router4装完后在main.js里注册Element Plusimport { createApp } from vue import ElementPlus from element-plus import element-plus/dist/index.css import App from ./App.vue const app createApp(App) app.use(ElementPlus) app.mount(#app)这样前端的基础骨架就出来了后面每个页面就靠Vue组件往这个壳里填。3.5 工程结构的规划后端我习惯按这种结构组织代码com.example.shopadmin ├── controller ├── service │ ├── impl ├── mapper ├── entity ├── dto ├── vo ├── common ├── config └── utilscontroller层只做参数接收和结果返回service层写业务流程mapper层访问数据库。层与层之间单向依赖不绕弯子。这种分层结构清晰写论文的时候画架构图也顺手。前端在src下按views和components组织页面再加一个utils存放axios封装和工具函数一个api目录存放各模块的接口调用文件。4. 核心模块实现从登录鉴权到订单闭环4.1 登录与JWT鉴权的完整链路登录模块看似简单但它是整个系统安全机制的入口所以我会多做一点设计。用户输入用户名和密码后后端先校验验证码有就校没有就略过再从数据库查出用户信息用MD5加盐或者BCrypt对密码做比对。密码匹配成功后用JWT生成一个TokenToken里面带上用户ID、用户名、角色标识并设置一个过期时间比如24小时。将这个Token返回给前端前端存储在localStorage或者store中之后每次Axios请求都在请求头里带上token字段。后端需要做一个拦截器统一从请求头中取出Token校验合法性如果Token过期或者被篡改直接返回401状态码。放行规则要注意登录接口和图片验证码接口不需要校验其他接口全部要求有效Token。这整个流程的底层逻辑可以概括为无状态认证。服务器端不存Session所有身份信息都在Token里这对集群部署非常友好同时也简化了后端的编码工作。嗯住需要注意的是JWT的signWith方法在不同版本里使用方式略有差异如果用的是0.9.1版本的jjwt直接setSigningKey就行。如果用了更新的版本API有变化最好先查一下文档再写。4.2 商品分类树形结构的处理商品分类是典型的树形数据结构数据库表设计采用父子关系是实现它最直接的方式一个parent_id字段指向父分类的ID顶级分类的parent_id为0。后端的查询逻辑是先把所有分类一次性查出来然后在内存里组装成树形结构返回给前端。组装方式是按parentId分组递归挂载子节点public ListCategoryVO buildTree(ListCategory allCategories) { MapLong, ListCategory childrenMap allCategories.stream() .collect(Collectors.groupingBy(Category::getParentId)); ListCategoryVO roots new ArrayList(); for (Category category : allCategories) { if (category.getParentId() 0) { CategoryVO vo toVO(category); vo.setChildren(buildChildren(childrenMap, category.getId())); roots.add(vo); } } return roots; }这里要注意一个细节mysql里如果某个分类下面挂了很多子分类一次性全部查出在内存中组装完全可接受。分类数量远不到性能瓶颈的程度所以说用递归的方式在内存里组装是够用的。前端侧Element Plus的el-tree组件可以直接渲染树形数据只需要配置好props里的label和children字段就行。这样商品分类的管理界面可以同时做到新增、编辑、删除删除时要注意先判断该分类下是否存在子分类或者商品如果有则提示“请先删除子分类或该分类下的商品”防止数据孤儿化。4.3 商品管理的CRUD进阶商品管理看起来是最普通的一张表但把它做好其实有几个关键点要处理。商品字段比较多包括商品名称、商品图片、分类ID、售价、原价、库存、销量、是否上架、添加时间等。新增和编辑时前端用el-form做表单校验图片上传用el-upload组件接后端的文件上传接口。后端上传接口把文件保存到本地磁盘或云存储上然后返回可访问的URL地址。分页查询是商品列表的核心接口。用MyBatis-Plus的分页插件在配置类里注册PaginationInnerInterceptor之后页面的请求参数带上pageNum和pageSize控制器直接返回分页结果。public ResultPageProductVO getProductPage(Integer pageNum, Integer pageSize, String keyword) { PageProduct page new Page(pageNum, pageSize); LambdaQueryWrapperProduct wrapper new LambdaQueryWrapper(); wrapper.like(StringUtils.hasText(keyword), Product::getProductName, keyword) .orderByDesc(Product::getCreateTime); PageProduct result productMapper.selectPage(page, wrapper); // 转VO返回 }商品上下架操作建议设计为单独接口状态变更时顺手记录操作时间和操作人为后续的操作日志模块留好数据基础。这样写的好处是答辩时你能清晰地告诉老师“商品状态的每一次变更系统里都有据可查”。4.4 订单模块的状态流转设计订单模块是整个系统中业务逻辑最密集的地方也是答辩老师最可能深挖的部分。我建议订单状态用整型或字符串来定义枚举值如下0待付款1待发货2待收货3已完成4已取消订单列表的查询需要关联用户表和订单明细表展示订单编号、用户昵称、商品数量、订单金额、订单状态、下单时间等信息。明细展示时再根据订单ID查询出订单详情里的商品列表。订单发货是一个典型的操作。发货时更新订单状态为待收货同时写入物流单号。这里要注意一个业务规则只有状态为待发货的订单才能执行发货操作状态不对要给出明确的错误提示。最有价值的设计是支付模拟。很多同学不知道怎么做支付模块其实可以做一个模拟支付接口接收订单ID后执行支付逻辑更新订单状态为待发货、扣减商品库存、增加商品销量。这三个动作必须放在同一个事务里用Transactional注解声明。如果缺少事务控制万一扣库存成功但订单状态更新失败了库存和订单就永远对不上号了。这一步就是事务一致性的最佳展示。4.5 会员管理与数据统计的落地会员管理模块相对独立。会员表记录用户名、手机号、注册时间、账号状态、累计消费金额。管理员在后台可以查看会员列表可以搜索也可以把异常账号禁用。这个模块有一个值得做的设计会员详情页。点击某条会员记录能跳到该会员的详情展示它的基本资料、近几个月订单列表、消费偏好。这个功能把会员和订单关联了起来体现你对表关联的理解。数据统计模块是加分项。用ECharts做柱状图和折线图展示近七天的订单数和销售额。实现方式可以简单直接写一个统计接口按日期分组查出数据然后封装成前端图表需要的格式。要注意的是日期分组的数据可能出现某天没有订单的情况这时需要补齐0值否则图表上会缺少某天的数据点观感上就会有断点。SELECT DATE(create_time) AS day, COUNT(*) AS order_count, SUM(order_amount) AS total_amount FROM order_master WHERE create_time DATE_SUB(CURDATE(), INTERVAL 7 DAY) GROUP BY DATE(create_time)这种SQL在答辩时完全可以重点讲它展示了你怎么把业务数据转换成可视化的聚合信息。4.6 RBAC权限模型的落地方式权限控制是我认为这个项目里最能拉开差距的部分。RBAC模型的三张核心表是用户表、角色表、菜单权限表外加用户角色关联表和角色菜单关联表。登录的时候查用户持有的角色再通过角色查出能访问的菜单列表。前端拿到菜单列表后动态生成侧边栏菜单同时判断按钮级别的权限。简单说就是某个角色只能看到分配给它的菜单点进去之后如果某个按钮不在权限范围内就隐藏。这个逻辑可以在前端用按钮级别权限指令v-permission实现自定义一个Vue指令检查当前用户权限数组里是否包含对应权限码不包含就移除按钮DOM。后端也要做对应校验。在每个Controller接口上使用自定义注解标注所需的权限码拦截器在分发请求前检查用户拥有的权限码集合是否包含目标权限码。后端的校验才是真正的安全屏障前端隐藏只是优化体验。这块内容做好了不仅项目的完整度高论文里也能花一整章去写权限设计答辩时值得一个很好的印象。5. 实操过程踩坑实录从跨域到事务的五个经典问题5.1 跨域问题前后端联调的第一次卡壳前端跑在localhost:5173或localhost:8080后端跑在localhost:8088两者的端口不同发起请求时浏览器会拦截跨域响应。这个卡壳让无数人浪费了半天时间。解决方案很多我推荐在后端配置一个CorsFilter或者用CrossOrigin注解。全局配置最省事Configuration public class CorsConfig { Bean public CorsFilter corsFilter() { CorsConfiguration config new CorsConfiguration(); config.addAllowedOriginPattern(*); config.addAllowedMethod(*); config.addAllowedHeader(*); config.setAllowCredentials(true); UrlBasedCorsConfigurationSource source new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration(/**, config); return new CorsFilter(source); } }注意如果设置了allowCredentials(true)则allowedOrigins不能使用*必须用allowedOriginPatterns。否则跨域请求依然会被浏览器拦截。这个细节网上教程里经常被忽略实际调试时会让人卡很久。5.2 日期格式化问题出在时区和序列化数据库存的是datetimeJava实体定义的是LocalDateTime结果前端拿到的字符串里带个“T”字符比如2026-03-22T15:30:00显示在页面上很丑。解决方案有两种一种在实体字段上用JsonFormat(pattern yyyy-MM-dd HH:mm:ss)注解另一种更彻底的是全局配置Jacksonspring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8这里还有个时区的坑MySQL连接串里如果没有serverTimezoneAsia/Shanghai取出来的时间可能差8个小时。务必在JDBC连接串上显式声明时区否则后患无穷。5.3 逻辑删除和物理删除的选择商品分类和会员这类数据我觉得更适合用逻辑删除也就是给表增加一个deleted字段默认值为0删除时把值改为1查询时只查deleted0的记录。MyBatis-Plus对逻辑删除有内置支持。在实体字段上加TableLogic注解配置全局逻辑删除的字段和值mybatis-plus: global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0它的好处在于数据不真正消失随时可以恢复而且操作日志里也能查到删除痕迹。答辩时被问到误删数据的恢复问题时这个设计就是最佳答复。5.4 库存与订单的事务一致性模拟支付时扣减库存如果扣减操作和更新订单状态之间出了问题会因为数据不一致留下脏数据。这个问题的标准解法就是加Transactional。Spring的声明式事务会在方法执行过程中管理Connection事务内任何一个操作抛出异常都会触发回滚。代码层面还有一个常见写法需要避免事务方法内部自己catch了异常然后吞掉这会让事务管理感知不到错误导致该回滚的数据没有回滚。我见过好几个同学把异常打印出来后直接return订单状态更新失败但库存已经扣了这种问题一旦被老师问出来很难自圆其说。另外在高并发场景下扣减库存要用乐观锁或悲观锁但在毕设阶段用一个加了事务控制的UPDATE语句就能说明思路UPDATE product_info SET stock stock - #{count} WHERE id #{productId} AND stock #{count}这个SQL本身带条件判断库存不足时不更新且影响行数为0再结合事务基本能满足毕设场景下的并发安全要求。5.5 前后端联调时的参数格式统一Axios默认以JSON格式提交POST参数SpringBoot控制器用RequestBody接收实体对象。但有些同学会在RequestParam和RequestBody之间搞混导致请求参数一直传递不过去。我的习惯是统一规则复杂对象用RequestBody接收JSON简单参数如ID、页码用RequestParam或PathVariable。前端Axios封装时设置responseType: json后端统一返回Result对象里面包含code、message、data三个字段。这样前后端联调的效率会提升很多。提示Result统一返回对象一定要在早期就封装好并全局使用不要在一个项目里混用Map或裸数据返回。答辩时老师浏览代码第一时间看的就是你这个系统的规范程度。6. 让毕设从“能用”到“值得高分”的四个加分设计6.1 统一响应结构 全局异常处理后端每个接口都返回同样的数据结构ResultT成功时code为200失败时code为其他值。再配合RestControllerAdvice做全局异常处理把校验异常、业务异常、未知异常都转成标准结构返回。这个设计看着轻巧但极大提升了系统的健壮程度。前端拿到响应后只需要根据code做判断不用处理各种异常形态。这种规范化处理的意识是答辩时老师非常认可的职业素养。6.2 操作日志的切片化实现用AOP技术定义一个切面拦截Controller层标注了OperationLog注解的方法自动记录操作人、操作方法、参数、执行耗时、操作时间。这样代码里不用在每个业务方法中手动写日志逻辑日志逻辑独立成一个模块通过注解声明式插入。实际实现中用反射获取注解内容用请求上下文获取操作人把日志保存到operation_log表。这块技术含量不高但展示效果非常好因为它完整体现了一个后台系统审计模块的设计思路也体现了你对于“系统性思维”的理解。6.3 部署到云服务器的体验答辩前最好把系统部署到一台云服务器上让老师直接通过浏览器访问。部署时后端打jar包前端构建出dist静态文件把dist用Nginx托管并配置反向代理把/api请求转发到后端的localhost:8088。这里重点看两个配置文件。Nginx配置的核心是server { listen 80; server_name your_server_ip; location /api/ { proxy_pass http://127.0.0.1:8088/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } location / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ /index.html; } }try_files那条规则非常关键它解决了Vue路由history模式下刷新页面404的问题。没有这一行你刷新一下后台页面就会遇到404当场演示翻车。部署这件事能做到就尽量做因为老师看到你能把项目跑在真实服务器上印象分会明显不一样。6.4 论文与答辩演示内容的对应关系论文的结构建议按章节来绪论、相关技术介绍、系统分析、系统设计、系统实现、系统测试、总结和展望。写系统设计和实现这两章时要注意每个功能模块的截图和描述都要对应代码里的真实实现。展示图别堆校园网速载入慢的动图用静态截图配上清晰说明就能说明问题。演示时我的建议是准备一个“演示脚本”规划好先展示什么、后展示什么。比如先登录展示权限控制下不同角色看到的菜单差异然后进入商品管理、新增一个商品、查看列表和分页效果再去订单模块完成一单模拟支付最后到数据统计去看图表变化。整个流程10到15分钟一气呵成展示的都是系统最精炼的部分讲究的是流畅而不是花哨。7. 常见问题速查表问题原因解决方法前端请求报403Token缺失或过期检查请求头是否携带Token重新登录获取新Token跨域请求失败Cors配置的allowCredentials与allowedOrigins冲突使用allowedOriginPatterns替代allowedOrigins接口能通但数据为空表名与实体类名映射不上配置驼峰映射检查表名是否与TableName保持一致分页返回异常分页插件未注册确认MyBatis-Plus分页拦截器添加到了配置类上传图片后无法访问静态资源映射未配置添加WebMvcConfigurer映射本地磁盘路径到URL日期少8小时JDBC连接串未声明时区在url后面加serverTimezoneAsia/Shanghai刷新页面404前端路由history模式未配置Nginx配置try_files规则事务未生效方法内部捕获异常或方法不是public事务方法用public修饰不要把异常吞掉前端的几个对应问题比如路由守卫失效、菜单刷新丢失多数是在本地存储管理上出了问题。token存到localStorage后刷新页面时要重新根据token获取用户信息和菜单列表再动态添加路由。很多同学只做了登录后加载菜单忘了刷新后的恢复逻辑于是每次刷新都回到登录页。我的习惯是在App.vue的onMounted钩子里写一个恢复流程本地有token就调用getUserInfo接口获取用户信息成功后重建路由。这样刷新页面就不再丢登录态了。8. 最后的几点体会带过不少同学整套项目做完回头问他们最大的收获几乎不是“会写SpringBoot了”而是理解了“一个完整的业务系统是怎么一层层组织起来的”。从一个控制器写一堆CRUD到后端有清晰的包结构、前端有完整的路由和状态管理、数据库有规范的表设计这套从0到1走完的过程带来的系统性认知不是看教程能替代的。给还没动工的同学一个建议不要从“技术”出发先从“项目结构”出发。花两天时间把表和接口设计好把系统的六大模块在纸上画一遍后面写代码就顺了。最浪费时间的方式就是边写边改表结构把多对多改成一堆重复字段最后自己都被搞晕。关于SpringBoot Vue这个组合我的观点依然是它是当前毕设场景下限高、上限也不低的稳妥选择。下限高在于它的资料丰富、模板成熟、即使照葫芦画瓢也不会翻车上限不低在于你完全可以在它的基础上扩展Redis缓存、Quartz定时任务、消息队列这些技术做出一个有真实工业感的系统让老师看到你在框架之外有自己的思考。这个题目的空间足够撑起一篇优秀论文剩下的就看你怎么走完这一遍了。