2026届的毕设题目下来得比往年早很多同学开题就领到了“乐器销售管理系统”这个题目技术栈指定ssmvue要求论文和程序一起交付。说实话这类题目属于经典的“管理系统”家族网上能搜到的代码很多但真正的问题在于搜到的东西要么结构混乱要么和论文对不上。我帮人拆过不少这样的系统今天把从需求到数据库、从后端接口到前端页面、再到论文和答辩的全套思路整理出来按这条线走这个毕设能省下不少返工时间。这个项目适合两类人一类是自己动手写想拿它练手顺便顺利毕业的另一类是时间紧、需要快速理解一套可复现代码并写出对应论文的。无论哪种核心都是先搞明白这个系统到底要做什么、技术栈之间怎么衔接然后才是写代码。1. 选题定位乐器销售管理系统到底在考你什么1.1 SSMVue为什么是毕设的黄金组合先聊一个很多学生会纠结的问题现在企业里早就用Spring Boot了为什么学校还让用SSM答案很简单——教学大纲和课程设计往往滞后于工业界而SSM的Spring、SpringMVC、MyBatis三件套恰恰能把“依赖注入、MVC分层、SQL映射”这些最核心的Java后端概念讲清楚。用SSM做毕设本质上是学校和导师想确认你真的理解了框架的底层协作方式而不是只会调一个注解搞定一切。Vue在其中的角色是前后端分离中的“前端”。过去那种用JSP在服务端拼页面、再用jQuery做点交互的模式已经不太能满足现在管理系统对交互体验的基本要求。Vue的组件化开发让页面拆成一个个独立模块数据驱动视图的变化配合axios请求后端接口形成了标准的“前端页面 后端API”结构。能用这套东西独立做出来一个完整系统说明你具备了基本的全栈开发意识和分层设计思维这在本科毕设里属于稳妥不出错的选型。1.2 乐器的业务模型决定了这个系统不是普通商城很多人看到“乐器销售管理系统”第一反应就是把网上的“商城系统”代码拿过来改个名字。这个思路最危险的地方在于——乐器的业务特性和普通服装、数码商品差别很大如果数据库里只是简单的“商品表分类表”答辩时老师问几个业务问题就容易露馅。乐器商品和普通商品至少有三个明显差异分类维度复杂。弦乐器、管乐器、键盘乐器、打击乐器、电子乐器每种乐器还有品牌、型号、材质、产地、尺寸等参数。单靠一个“分类ID”不够用需要设计更灵活的商品属性结构。单价高走精细化库存。一把吉他几千上万一件乐器通常有唯一序列号用于防伪和售后追踪。这和“按件数管理库存”的快消品不同。订单金额大购买决策链长。用户会反复比较、加入收藏、咨询客服业务上可能涉及定金、分期、以旧换新等场景虽然毕设不用做那么复杂但订单状态需要设计得更完整。把这些特征抽象成系统功能就自然得出了商品管理模块要支持多条件检索和富文本详情库存管理要支持单件乐器入库出库追踪订单模块要有一个清晰的状态机。1.3 角色与功能清单开题报告可以直接抄系统按角色分成前台用户和后台管理员两块功能边界很清晰这也是毕设论文里“可行性分析”和“功能需求”章节的素材。角色功能模块具体说明游客/用户注册登录账号密码注册登录密码MD5加盐存储游客/用户乐器浏览搜索分类筛选、关键词搜索、分页浏览、商品详情用户购物车加入购物车、修改数量、删除、批量结算用户订单管理提交订单、订单列表、确认收货、在线支付模拟用户个人中心收货地址管理、个人信息修改、浏览足迹管理员商品管理乐器增删改查、上下架、分类管理、库存录入管理员订单管理订单列表、发货、退款处理、查看详情管理员用户管理用户列表、禁用/启用、权限控制管理员数据统计销售统计、热门乐器排行可用图表展示2. 把数据库建好毕业论文的E-R图就完成了一半2.1 八张核心表的组织关系数据库设计是整个项目的地基也是论文里必画的E-R图来源。我在设计这套系统时用到的表和它们的关系比较经典学生复用度很高user用户表category乐器分类表product乐器商品表product_serial乐器序列号表cart购物车表orders订单表order_item订单项表address收货地址表外加一张可选的通知公告表notice。这些表的关系是一目了然的用户对应购物车、订单、地址分类对应商品商品对应序列号订单对应订单项订单项对应某个具体商品。有一个细节要注意表名尽量避免用order因为在MySQL里order是排序的关键字直接用作表名容易在写SQL时报语法错误我习惯用orders。类似的坑还有user在某些数据库是保留字统一加后缀或使用反引号能规避问题。2.2 乐器商品表比普通商品多出来的字段商品表是系统里最核心的一张表字段设计直接决定后续开发是否顺手。这张表建议包含以下字段字段名类型说明idint主键自增category_idint关联分类表brandvarchar品牌如雅马哈、芬达、卡西欧namevarchar商品名称如“雅马哈FG800民谣吉他”modelvarchar型号用于区分同系列不同版本materialvarchar材质如云杉木单板、玫瑰木指板originvarchar产地pricedecimal(10,2)售价注意用decimal不要用floatstockint库存总量salesint销量用于热门排行imagevarchar封面图URLimagestext轮播图多个URL用逗号拼接detailtext富文本详情statustinyint上下架状态1上架0下架create_timedatetime创建时间很多学生在这里犯的错是漏掉model、material、origin这类的属性字段只留一个name和price。问题是乐器用户很看重具体配置商品列表页也要有筛选维度没有这些字段后台商品管理和前台展示都会显得很空论文中“系统功能详细设计”也写不出内容。2.3 乐器序列号表答辩时能拿得出手的业务设计这是我认为整个数据库设计里最有业务含量的部分也是区别于“普通商城换皮”的关键设计。一张product_serial表字段大致是id、product_id、serial_no唯一编号比如YAMAHA-FG800-2026-0001、status0在库/1已售出、order_id售出时关联订单、purchase_date入库时间、sold_date售出时间。为什么要单独做一张序列号表因为乐器这种高价值商品在现实中是“一物一码”管理的。每把琴背后都有一个唯一的序列号印在琴身和保修卡上经销商用序列号报修、溯源、防串货。在系统里体现这一层等于给商品加了一个精细到单件的库存管理能力用户下单时系统会从这张表里锁定一件状态为“在库”的商品后台发货时管理员能看到具体发给用户的是哪一把琴。在毕业论文里这个设计可以对应写到“数据库设计”中的“实体关系分析”也可以作为“系统创新点”单独提一笔比那些只做增删改查的商城系统有说服力得多。2.4 订单状态机与支付流程设计订单部分的设计要回答一个关键问题订单从创建到完成一共经过哪些状态这也是论文里必然会画的状态图。我的建议用一组整型状态值来表示0待付款订单已创建未完成支付1待发货已支付等待管理员发货2待收货已发货物流流转中3已完成用户确认收货4已取消用户主动取消或超时关闭5售后中申请退款或退货后台管理员的“发货”操作对应状态从1到2用户的“确认收货”对应从2到3整个流转非常清晰。关于支付毕设一般不需要接入真实支付接口用“模拟支付”就足够了用户下单后点击“去支付”系统直接把订单状态从0改成1并扣减库存、生成支付流水记录。在论文里写清楚“本系统采用模拟支付方式重点在于订单与库存的联动逻辑”这是一个合理解释答辩老师能接受。3. SSM后端把“查询乐器列表”这一条请求链路跑通3.1 Maven工程的前后端文件规划很多学生拿到SSM项目时最头疼的是目录结构混乱。我建议按照下面这种规划来建工程这也是最标准的Maven Web结构pom.xml src/main/java/com/example/music/ ├── controller/ # Controller层接收前端请求 ├── service/ # Service接口 ├── service/impl/ # Service实现类 ├── dao/ # MyBatis的Mapper接口 ├── entity/ # 实体类对应数据库表 ├── common/ # 通用类Result、PageResult、异常处理 ├── config/ # 配置类拦截器、跨域、WebMvc配置 └── util/ # 工具类JWT或Token工具、MD5工具 src/main/resources/ ├── mapper/ # MyBatis的XML映射文件 ├── jdbc.properties ├── spring/ # spring配置、springmvc配置、mybatis配置 ├── log4j.properties └── sql/ # 数据库初始化脚本前端Vue项目独立放在一个frontend目录下和后端完全分离。这个结构清晰明了重点是后续写论文章节“系统详细设计”时可以很自然地按包结构描述各层职责。3.2 统一返回体与分页封装前后端分离的开发第一件事是统一接口的返回格式。否则前端对接每个接口都要单独判断数据结构很容易乱。我习惯的返回体是public class Result { private Integer code; // 200成功500失败401未登录 private String msg; // 提示信息 private Object data; // 数据 public static Result success(Object data) { Result r new Result(); r.code 200; r.msg 操作成功; r.data data; return r; } public static Result error(String msg) { Result r new Result(); r.code 500; r.msg msg; return r; } }分页时再包一层public class PageResult { private Long total; // 总条数 private List? rows; // 当前页数据 }这样做的好处是前端拿到响应后只需要判断code再取data渲染页面。错误信息集中显示逻辑统一。3.3 Controller→Service→Mapper的完整调用链以一个典型的“分页查询在售乐器”接口来说明后端的三层结构。Controller层只负责接收和返回不写业务逻辑Controller RequestMapping(/api/product) public class ProductController { Autowired private ProductService productService; RequestMapping(/list) ResponseBody public Result list(RequestParam(defaultValue 1) Integer pageNum, RequestParam(defaultValue 8) Integer pageSize, Integer categoryId, String keyword) { return Result.success(productService.getProductList(pageNum, pageSize, categoryId, keyword)); } }Service接口定义业务方法public interface ProductService { PageResult getProductList(Integer pageNum, Integer pageSize, Integer categoryId, String keyword); }ServiceImpl具体实现分页逻辑和条件拼接Service public class ProductServiceImpl implements ProductService { Autowired private ProductMapper productMapper; Override public PageResult getProductList(Integer pageNum, Integer pageSize, Integer categoryId, String keyword) { PageHelper.startPage(pageNum, pageSize); ListProduct list productMapper.selectByCondition(categoryId, keyword); PageInfoProduct info new PageInfo(list); return new PageResult(info.getTotal(), info.getList()); } }这里用到了MyBatis的分页插件PageHelper配置一行拦截器即可实现自动分页能省掉手写limit的麻烦。Mapper接口public interface ProductMapper { ListProduct selectByCondition(Param(categoryId) Integer categoryId, Param(keyword) String keyword); }最后是XML文件对应SQL语句select idselectByCondition resultTypecom.example.music.entity.Product SELECT * FROM product where if testcategoryId ! null AND category_id #{categoryId} /if if testkeyword ! null and keyword ! AND name LIKE CONCAT(%, #{keyword}, %) /if AND status 1 /where ORDER BY create_time DESC /select这条链路的核心是Controller只做参数接收和结果返回Service层写业务逻辑Mapper管SQL。为什么要分层因为每一层的职责单一出问题时能精确定位论文里“分层架构设计”也专门有内容可写。3.4 MyBatis动态SQL多条件组合搜索怎么写交叉筛选是乐器销售系统的刚需用户可能想搜“2000元以下的雅马哈民谣吉他”也可能想搜“电钢琴88键”。关键在于MyBatis的if动态标签配合where使用注意一个常见的坑——多个条件拼接时前面的if多了个AND我见过不少人在where标签外面自己加WHERE导致SQL语法错误。正确做法是把所有条件写在where里让MyBatis自动处理第一个条件的AND前缀。条件多起来之后Mapper接口的参数建议用一个查询对象封装public class ProductQuery { private Integer categoryId; private String keyword; private String brand; private Double minPrice; private Double maxPrice; private Integer status; // getter/setter省略 }这样传参更清晰也方便后续加筛选条件。3.5 登录拦截器与跨域联调时最折磨人的两个问题SSMVue联调最常碰到的两个问题分别是登录拦截和跨域。登录拦截的坑在于很多学生把/api/user/login、/api/user/register、/api/product/list这些不需要登录也能访问的接口也拦截了导致前端怎么调都报“未登录”。解决方案是在拦截器配置里维护一个白名单数组public class LoginInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { HttpSession session request.getSession(); // 已登录用户直接放行 if (session.getAttribute(user) ! null) { return true; } // 判断是否是登录接口 String uri request.getRequestURI(); if (uri.contains(/api/user/login) || uri.contains(/api/user/register)) { return true; } // 未登录返回401前端跳转登录页 response.setStatus(401); return false; } }注册拦截器时把静态资源和放行路径配置好。跨域问题来自浏览器同源策略前端跑在8080端口后端跑在8081端口直接请求会报CORS错误。后端加一组配置即可解决Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }注意allowedOriginPatterns如果写成allowedOrigins(*)在部分Spring版本里会和allowCredentials(true)冲突导致前端请求失败这是一个很隐蔽的兼容性问题。4. Vue前端从页面到接口的对接实战4.1 环境准备与项目初始化前端开发环境需要先装Node.js最新版本只要不是太老都行。创建项目时不一定非要手动搭Webpack配置用Vue CLI初始化一个Vue2项目足够npm install -g vue/cli vue create music-frontend按需选上Router、Vuex或者不用Vuex用简单的store安装组件库Element UI和请求库axiosnpm install element-ui axios这里有个经验Element UI默认适配Vue2Vue3要用Element Plus两个名字不同安装时别搞混。毕设用Vue2生态更成熟稳定网上资料也多。路由设计方面分用户端和管理员端两块。用户端的/是首页包含/productList商品列表、/productDetail/:id详情、/cart购物车、/order订单、/login登录注册管理员端用/admin前缀下面挂/admin/product商品管理、/admin/order订单管理、/admin/user用户管理等子路由。路由懒加载用component: () import(...)可以减小首屏加载体积。4.2 axios封装与token携带整个项目所有请求都走一个axios实例统一在请求拦截器里加token在响应拦截器里处理错误码import axios from axios import { Message } from element-ui import router from /router const request axios.create({ baseURL: http://localhost:8081, // 后端地址 timeout: 10000 }) // 请求拦截器携带token request.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers[Authorization] token } return config }) // 响应拦截器统一处理401和错误提示 request.interceptors.response.use( response { const res response.data if (res.code 401 || response.status 401) { localStorage.removeItem(token) router.push(/login) } if (res.code ! 200) { Message.error(res.msg || 请求失败) return Promise.reject(new Error(res.msg || 请求失败)) } return res }, error { Message.error(网络异常请检查后端服务) return Promise.reject(error) } ) export default request一个值得提醒的细节如果后端用Session存登录态前端不需要塞token只要保证withCredentials: true即可如果后端用的是JWT方案前端就要把token存到localStorage并放在Header里。两种方案任选其一不要混用。我在这个项目里比较推荐Session方案因为SSM做Session登录更简单去掉跨域配置里的allowCredentials冲突也更少。4.3 用户端的商品展示与购物车用户端首页是给答辩演示用的重点页面。首页顶部是搜索栏主体是分类侧边栏和商品卡片网格商品卡片展示图片、名称、价格、销量。点击卡片跳转到详情页。商品列表页的关键逻辑是监听路由参数变化重新请求数据。如果用户从首页点“民谣吉他”分类跳到商品列表页前端需要在watch里监听$route的变化重新调用接口更新页面数据而不是只在mounted里加载一次。这个交互细节很多学生忽略导致点击分类后页面不刷新答辩演示时特别尴尬。购物车的实现思路是“前端都做后端存数”。进入购物车页面时调用GET /api/cart/list获取该用户的购物车数据点击“加入购物车”时调用POST /api/cart/add传productId和quantity购物车页面上修改数量、删除商品也都调用对应接口。不要把购物车数据只存在Vuex里一旦刷新页面就丢失了管理员端也就看不到用户的购物车状态了。购物车数量的加减有并发隐患但毕设场景下问题不大。稳妥一点的做法是每次加减都直接传新的数量给后端由后端重新判断库存上限。4.4 后台管理界面与Element Admin布局管理员端可以参考vue-element-admin的布局思路但不必真的引入整套框架那套代码对毕设来说太厚重了。自己做的话一个Element UI的el-container就能搞定左侧是el-aside放侧边菜单右侧是el-container顶部用el-header放标题和管理员信息中间的el-main放路由视图。菜单项对应到路由用vue-router的el-menu的router模式点击菜单就能切换路由。商品管理页面是后台最核心的部分包含一个表格列有商品ID、名称、价格、库存、状态、操作按钮。操作按钮有“编辑”“上下架”“删除”。新增和编辑共用一个对话框组件里面是表单包含分类下拉选择、名称、品牌、材质、价格、库存输入框以及图片上传和富文本详情编辑器。富文本编辑器推荐用vue-quill-editor它是轻量级的Quill编辑器支持图片插入和格式调整存到数据库的detail字段里。展示时前端用v-html渲染注意要做简单的XSS过滤至少把script标签去掉。4.5 Vue Devtools在联调中的具体用法联调阶段调试工具是效率的关键。Vue Devtools在浏览器里能看到组件的props、data、Vuex状态这些不用多说我讲两个平时容易被忽略的用法。一个是快速定位问题比如页面上某个字段显示为undefined打开Vue Devtools点中那个组件右侧的data和props里会直接显示当前值来自哪里一眼就能看出是接口没返回还是字段名拼错了。另一个是配合network面板排查请求。当页面莫名其妙空白时顺序是先在Devtools的Components面板看组件有没有正常渲染再到Network面板看接口是否报错如果是401就检查token或Session是否过期如果是404就检查后端路由映射和前端baseURL是否匹配。这套排查顺序能帮你省下大量瞎改代码的时间。5. 下单扣库存的事务设计论文里的“系统优化”章节素材5.1 订单创建过程的事务边界购物车结算、提交订单、扣减库存这三件事必须放在同一个事务里否则就会出现订单生成了但库存没扣、或者库存扣了订单却没创建成功的数据不一致问题。Service层加Transactional注解是最简便的方案Transactional(rollbackFor Exception.class) public void createOrder(OrderParam param) { // 1. 创建订单主表状态置为待付款 // 2. 批量创建订单项 // 3. 清空购物车中已勾选的商品 // 4. 预扣减库存或标记序列号 }rollbackFor这一项要记得写否则默认情况下只在遇到RuntimeException时回滚遇到受检异常可能不会回滚这个细节丢事务的时候能坑一晚上。5.2 乐观锁扣库存的SQL与原理下一单抢购、库存只有1件、两个人同时下单如果先SELECT stock FROM product WHERE id ?再在代码里判断库存大于0再UPDATE两个人可能都通过判断但库存只能扣一次就会出现超卖。解决方式在毕设里最实用的就是乐观锁update idreduceStock UPDATE product SET stock stock - 1 WHERE id #{productId} AND stock 1 /update关键点在于WHERE条件里加上了stock 1数据库自带原子性同一时刻只有一个请求能把stock从1改成0另一个请求受影响行数为0前端就能识别为“库存不足”。这个SQL的巧妙之处是它把“判断库存”和“扣减库存”在数据库层面合并成了一个原子操作不需要显式加锁也不需要分布式锁。在论文里写并发部分时这个乐观锁方案是一个很好的“系统优化”素材配合执行测试说明扣减正确率比空谈“高并发”实在得多。5.3 超时未支付订单的补救方案用户提交订单后如果一直不支付库存就一直是锁定的其他用户无法购买。现实中电商系统的处理方式很多毕设里最简单的方案是Spring的Scheduled定时任务Component public class OrderTimeoutTask { Autowired private OrderService orderService; Scheduled(cron 0 0/5 * * * ?) public void closeTimeoutOrders() { // 找出创建时间超过30分钟且状态仍为待付款的订单 ListOrder timeoutOrders orderService.findTimeoutOrders(30); for (Order order : timeoutOrders) { // 回滚库存 orderService.rollbackStock(order.getId()); // 更新订单状态为已取消 orderService.updateStatus(order.getId(), 4); } } }在Spring配置里记得开启定时任务task:annotation-driven schedulertaskScheduler /这个方法虽然简单粗暴但对毕设来说完全够用而且能在论文里写清楚“超时订单处理模块”的设计思路。5.4 可以在论文中写的性能与并发测试结论答辩论文和代码里若是有一份简单的测试结论会很加分。我自己在做这个系统时用JMeter模拟过库存扣减场景商品库存初始100件并发50个用户同时下单压测结果是没有出现超卖扣减成功数和实际库存变化一致。测试数据和结论直接放论文章节“系统测试-性能测试”老师会觉得你确实做了验证工作。前端性能方面商品列表页如果数据量大可以在后端接口的SQL里用LIMIT配合PageHelper分页也可以给列表页加上前端缓存。这些都能作为“系统优化”的论据不过不用过度写点到为止。6. 论文写作与答辩准备的拆解6.1 论文目录与“代码→论文章节”的映射毕设论文的核心是让老师相信这不是网上搬来的代码是你自己设计的系统。最有效的方式是让论文章节和你的代码结构一一对应。这里给一份常见目录结构和对应的代码内容论文章节对应内容绪论背景意义、国内外研究现状、本文主要工作相关技术SSM框架、Vue、MySQL、Maven、前后端分离需求分析角色分析、功能需求用用例图、非功能需求系统设计总体架构图、功能模块图、数据库E-R图、表设计系统实现按模块贴关键代码和页面截图逐一说明实现逻辑系统测试测试环境、功能测试用例表、性能测试、测试结论总结与展望项目完成情况、不足与后续改进关键技巧是每写一个实现小节就贴一张对应功能的页面截图和一段核心代码再加两三句解释。图片占版面、代码显工作量、解释显理解三者结合论文内容自然充实。6.2 数据库表、流程图和时序图从哪来很多学生不会画UML图和流程图其实可以借助工具生成。数据库E-R图可以用Navicat或MySQL Workbench直接根据表结构生成然后简单整理放论文里。功能模块图用Visio或draw.io手绘即可结构是树形层级关系系统分成前台和后台两个顶层节点逐级往下展开。时序图是展示Controller、Service、Mapper之间调用关系的最直观手段也是答辩时老师喜欢问的“说说购买流程”。画时序图时按“用户→Controller→Service→Mapper→数据库”的顺序画配合5.1节的事务边界能把订单创建的全过程讲清楚。6.3 答辩高频问题整理根据近几年毕业答辩的情况围绕这个系统老师最爱问的问题集中在下面几类提前背熟可以避免现场慌乱架构理解类SSM中Spring、SpringMVC、MyBatis各自的职责是什么和Spring Boot有什么区别为什么用前后端分离业务与数据库类乐器商品相比普通商品在设计上有什么特殊性为什么要有序列号表订单状态如何流转技术细节类分页是怎么实现的多条件查询的动态SQL怎么写登录怎么控制权限事务怎么保证一致性并发与优化类库存扣减怎么防止超卖哪个方法保证了原子性如果用户量变大系统的瓶颈在哪里这些问题基本都在这篇文章覆盖的范围内。像我前面说的乐观锁SQL就是回答“防止超卖”的标准答案把UPDATE ... WHERE stock 1的原子性原理讲清楚老师基本不会再追问。6.4 演示Demo的8分钟脚本答辩现场演示程序顺序比内容更重要。我建议的脚本是打开项目先展示数据库表结构和核心表数据用Navicat说明数据库设计思路。启动后端演示前台页面走一个完整流程注册/登录→筛选乐器→查看详情→加入购物车→结算→模拟支付→查看订单状态变化。切管理员账号演示订单管理发货、商品管理上架新乐器、数据统计销售排行。回到代码里展示一个核心接口比如订单创建的事务方法和乐观锁扣库存的SQL简单讲解逻辑。最后切到论文里的E-R图和架构图把系统整体结构串一遍。整套演示控制在8分钟以内重点放在业务流程走通和核心代码讲解上。提前把测试账号和测试数据准备好避免现场临时输入数据出错。7. 部署避坑记录把程序变成能演示的成品7.1 前后端合并部署的两种方式答辩时演示环境可能是自己的电脑也可能是教室的电脑把项目跑起来是最关键的。前后端部署有常见的两种方式。第一种是前端打包后放进后端一起运行。在前端项目执行npm run build把生成的dist目录下的文件拷到SSM项目的src/main/webapp下重新打包成war部署到Tomcat。这样做的好处是一个Tomcat端口就能搞定不用处理跨域。缺点是前端每次改动都要重新打包拷贝开发过程不要用这种方式。第二种是开发时前后端分离后端跑在Tomcat的8081端口前端用npm run serve跑在8080端口通过跨域配置联调。答辩时建议用第一种方式省环境问题。7.2 装机后最容易踩的五个坑每次帮人调试系统翻来覆去几乎都是这几个问题提前列出来避雷问题现象根本原因解决方案启动报ClassNotFoundMaven依赖没有引入完整比如缺少mybatis-spring、mysql-connector检查pom.xml对照官方文档补齐依赖访问接口报500控制台显示mapper绑定异常Mapper接口和XML文件没有在同一个包路径下或没有扫描到检查applicationContext和mybatis配置里的mapperLocations路径数据库中文乱码连接串没有指定UTF-8或建库时字符集不是utf8mb4URL加上characterEncodingutf8建库语句指定字符集前端请求接口报404baseURL端口写错或后端没有部署启动确认后端地址和端口先浏览器直接访问接口测试页面刷新后404Vue Router用的是history模式Tomcat没有配置支持改用hash模式或者在后端配置一个转发规则这些坑基本覆盖了我会话里被打听最多的内容把这份清单抄在部署文档里答辩前把运行环境完整演练一遍能救命的。写到最后想分享一句实在话如果你真的想把毕业设计做出点样子不要把精力花在找“项目难度高不高”的答案上而是花在把自己的业务逻辑讲圆。乐器销售管理系统这个题目本身难度中等偏上一点点只要数据库设计能体现乐器特征、订单链路能跑通、论文前后能自圆其说答辩通过没有悬念。我见过太多人花半个月去纠结要不要用Redis却连购物车和订单的状态都没理顺那才是真正的问题。先把基础链路走通再谈优化这是做这套系统最稳妥的路径。
