每届毕设季都有一批人被做一个什么系统卡住。说句实话JavaWeb方向能选的题目翻来覆去就那么几类新闻管理、个人博客、商城系统、预约平台。稍微有点追求的人都不想做纯粹的增删改查可一上来就上高并发秒杀电商又明显超出课设/毕设的合理工作量。我这些年给不少在校生看过代码、调过bug最后大家选来选去还是图书商城这个方向最稳。它不花哨但能把电子商务最核心的几条链路——商品浏览、搜索、购物车、下单、订单流转、后台管理——完完整整地做出来。这里要讲的就是一个基于SpringBootVueMySQL的图书电子商务网站管理平台。后端用Java生态的SpringBoot提供RESTful接口前端用Vue做页面MySQL存数据全程走前后端分离架构。它适合拿来当毕业设计、课程设计也适合想入门JavaWeb全栈的人当练手项目。接下来我从选题价值、技术选型、数据库设计、后端核心链路、前端重点、联调部署一直到答辩准备把整套东西掰开揉碎讲一遍。1. 选题价值和项目全景图书商城为什么是毕设常青树1.1 业务规模恰到好处不是越大越好一个课设/毕设项目最怕的不是功能少而是功能多到做不完、讲不清。图书商城这个题目的妙处在于它的业务边界非常清晰天然带着分类-商品-购物车-订单这条电商主链路。比起做全品类商城图书的品类结构很简单不需要处理SKU、规格、多级分类这些复杂概念。一本书就是一条商品记录有书名、作者、出版社、ISBN、分类、价格、库存、封面这些字段类型覆盖了字符串、数字、小数、时间、文件上传足够让一个初学者把后端CRUD和前端表单交互练得明明白白。比起做新闻管理系统图书商城又多了一层订单状态和库存扣减的逻辑业务上有深度答辩的时候不至于被老师问住。我经常跟人打比方图书商城是教学楼规模不大但该有的房间都有你走一遍就能知道一栋楼是怎么盖起来的。1.2 功能模块划分前台、后台两条线这个项目按角色可以拆成前台用户端和后台管理端两端共用同一套后端接口和数据库。具体模块如下表。端模块核心功能前台用户模块注册、登录、退出、个人信息查看前台图书浏览分类筛选、关键字搜索、图书详情前台购物车加入购物车、修改数量、单选/全选、删除前台订单模块提交订单、模拟支付、取消订单、确认收货后台管理员登录管理员鉴权、不同角色权限控制后台图书管理图书增删改查、上下架、库存维护、封面上传后台分类管理图书分类的维护后台订单处理查看订单、发货、修改订单状态后台用户管理用户列表、启用/禁用这个划分本身就是一个很好的项目边界练习前台让用户买书后台让管理员管店两者通过订单表连起来。1.3 学习视角做完你能带走什么从学习价值看这个项目覆盖了JavaWeb开发最常被问到的几个点后端分层Controller、Service、Mapper、Entity各司其职理解职责分离。RESTful API 设计如何用HTTP动词和URL表达业务操作。事务与并发基础下单时为什么需要事务库存扣减如何避免超卖。数据库表关系一对多、多对多外键和逻辑关联。前端工程化组件化、路由、状态管理、axios请求封装。前后端联调开发环境代理、跨域、接口对接的完整流程。这套知识栈走通一遍再去看公司里的真实项目至少不会迷路。2. 技术栈选型为什么这套组合是不折腾方案2.1 SpringBoot把SSM的繁琐配置收起来很多教材还在教SSMSpringSpringMVCMyBatis但现实中已经很少有人从零搭SSM项目了。SpringBoot的本质是自动配置它通过大量的AutoConfiguration类把数据源、Web容器、JSON序列化、日志这些基础设施自动装配好。你只要引入spring-boot-starter-web内嵌的Tomcat就起来了不用再部署外置Tomcat也不用写一堆XML。SpringBoot还有一个容易被忽略的好处统一依赖管理。spring-boot-starter-parent里锁定了常用第三方库的版本你在引入MyBatis-Plus、MySQL驱动的时候不需要自己去查该配哪个版本很大程度避免了依赖冲突地狱。选型的时候我特别提醒一句不要盲目追新版本。现在SpringBoot 3.x已经普及但它基于JDK 17且包名从javax改成了jakarta很多课设环境还停留在JDK 8。如果是为了完成课程设计或毕业设计老老实实用SpringBoot 2.7.x JDK 8文档多、资料全、坑少。如果新项目直接上3.x遇到老博客的代码复制过来编译不过排查半天往往就是包名差异属于纯粹的浪费时间。2.2 Vue组件化开发带来的体验优势前端选Vue主要是因为它的学习曲线在国内Java开发者群体里相对平滑。Vue的核心思路是数据驱动视图你把页面状态维护在JavaScript里页面会自动跟着变不需要像jQuery那样手动操作DOM。Vue 2 和 Vue 3 的差异也值得说一句。Vue 3的Composition API把逻辑按功能组织比Vue 2的Options API更灵活组件复用时也更好抽取公共逻辑。如果你是从头学直接上Vue 3 Element Plus是理性的选择如果拿到的源码是Vue 2 Element UI也完全不影响理解——路由、组件的核心思想是相通的。很多人在环境配置这一步就卡住了。npm install是一个高频翻车点国内网络环境下建议把npm registry换成淘宝镜像命令是npm config set registry https://registry.npmmirror.com还有个小坑Vue CLI创建的旧项目可能依赖node-sass它对Node版本非常敏感经常编译报错。如果遇到要么升级到dart-sass要么干脆换用普通CSS或Less不值得在构建工具上耗太久。2.3 MySQL MyBatis-Plus开发效率和可读性的平衡数据库选MySQL无需多言JavaWeb项目的默认选择。真正需要思考的是持久层框架。用纯JDBC太原始大量重复代码不推荐。用Spring Data JPA写起来快但复杂查询和SQL调优不够直观很多人对隐式SQL有心理障碍。用MyBatis灵活但单表CRUD要手写XML课设里难免觉得啰嗦。用MyBatis-Plus它是MyBatis的增强工具单表增删改查直接继承IService和BaseMapper复杂查询再写XML或注解SQL属于两头都占的方案。举个实际例子图书列表的多条件查询MyBatis-Plus的条件构造器写出来非常直观LambdaQueryWrapperBook wrapper new LambdaQueryWrapper(); wrapper.like(StringUtils.isNotBlank(keyword), Book::getName, keyword) .eq(categoryId ! null, Book::getCategoryId, categoryId) .orderByDesc(sort 1, Book::getSales);这段代码能看懂基本就能应付项目里80%的查询场景。数据库连接池方面SpringBoot 2.x默认集成了HikariCP性能好配置少不用额外折腾Druid。如果只是课设HikariCP完全够用。2.4 一套稳定可复现的版本组合给一个我实测过的不折腾版本组合直接照抄能省半天时间。组件推荐版本说明JDK1.8 或 11避开SpringBoot 3.x的JDK17要求Maven3.6.x二进制安装即可SpringBoot2.7.x稳定资料最多MyBatis-Plus3.5.x3.5版本已经比较成熟MySQL5.7.44 或 8.0.x二选一注意驱动版本匹配Node.js16 或 18满足Vue3和Vite要求Vue3.x Element Plus或源码自带的Vue 2版本这套组合最大的优势是网上遇到的每个报错基本都有现成答案对课设来说稳定复现比新奇版本重要得多。3. 数据库设计订单、图书、购物车这些表的背后逻辑数据库设计是很多人会忽视、但答辩护不住脚的重灾区。图书商城这种项目表关系非常典型我把核心表的逻辑讲清楚。3.1 表结构总览和设计原则核心表可以分成两组基础资料表和业务流水表。基础资料表是用户、图书、分类业务流水表是购物车、订单、订单项。设计原则上遵守能拆则拆、冗余可接受分类独立成表图书表只存category_id避免在图书表里堆一堆分类字符串。订单拆成t_order和t_order_item两张表因为一个订单可能包含多本不同的书一对多关系必须用明细表表达。购物车表加(user_id, book_id)唯一约束同一本书只允许一条记录重复加入就更新数量。核心表大致这样表名用途关键字段t_user用户表id, username, password, nickname, role, statust_category分类表id, name, sortt_book图书表id, name, author, publisher, isbn, category_id, price, stock, sales, cover, statust_cart购物车表id, user_id, book_id, quantity, create_timet_order订单表id, order_no, user_id, total_amount, status, create_time, pay_time, ship_timet_order_item订单明细表id, order_id, book_id, book_name, price, quantity, subtotal3.2 图书表字段设计和金额精度图书表的几个字段需要重点解释。第一价格字段必须用DECIMAL(10,2)而不是float或double。Java里的Float/Double是二进制浮点数计算0.10.2会得到0.30000000000000004这在电商金额计算里是绝对不可接受的。对应Java实体类里用BigDecimal。这个点我在答辩和面试里都见过被反复追问值得提前理解。第二ISBN国际标准书号建议加唯一索引。它是一本书的身份证号图书录入时按ISBN重复校验比按书名校验可靠得多。书名可能会有重名或版本差异ISBN基本不会。第三stock和sales两个字段要区分清楚。库存是下单扣减的销量是展示和排序用的。库存扣减用负向更新防止超卖销量则在订单支付成功后累加。很多初学者把这两个混在一起最后查询和扣减逻辑都变得混乱。第四图书封面字段存的不是图片本身而是访问路径。比如/uploads/cover/xxx.jpg由后端静态资源映射对外提供访问。把图片二进制存进数据库是典型的反面教材既拖慢查询又浪费备份空间。3.3 订单表和订单明细表一对多的标准解法订单表是业务核心。这里藏着两个常被问到的设计问题。一是为什么订单金额要冗余到订单明细里。下单时图书表里存着当前价格但以后管理员可能改价。如果不做快照用户翻历史订单时看到的价格就是最新价格这在商业上是不合理的。所以下单时要把book_name、price、subtotal复制到t_order_item让订单自成历史。二是订单表为什么要拆成头和明细。如果只建一张订单表一行存一本书那一次买三本书就会产生三条订单订单状态无法统一管理管理员发货时也只能逐条操作。拆成主表和明细表之后订单头记录整单状态订单明细记录每本书的购买情况这才是电商订单的标准形态。订单号可以不用搞得太复杂。时间戳加用户ID再加随机数就足够比如String orderNo LocalDateTime.now().format(DateTimeFormatter.ofPattern(yyyyMMddHHmmss)) RandomUtil.randomNumbers(4);课设不涉及分布式ID不需要引入雪花算法这类重型方案。3.4 订单状态用数字存用枚举理解订单状态我建议用tinyint存储整个项目里维护一套状态字典例如状态值含义前端显示0待付款待付款1待发货已支付等待商家发货2待收货已发货等待用户确认3已完成交易完成4已取消订单取消为什么用数字存储省、排序方便关键是状态流转可以做成状态机。用数字存但Java代码里建议定义常量或枚举避免魔法数字满天飞。我在项目里通常会写一个OrderStatusEnum里面放getValue()和getDesc()前端拿到状态码自己映射文本。关于用MyBatis-Plus实体类自动生成建表SQL这个操作我的观点是如果你能完全掌控实体类注解用它做单表生成没问题但对有外键关联和时间字段默认值的表自动生成的效果往往不理想最后还是得手调。课设阶段我建议直接提供一份手写的bookstore.sql初始化数据库时脚本导入逻辑清晰、可控性高答辩时也能展示你对表结构的理解。4. 后端核心链路从登录鉴权到订单状态机4.1 分层包结构和项目骨架后端代码建议按功能分包而不是按技术层次分包。一个比较清晰的结构是com.example.bookstore ├── controller // 接收HTTP请求 ├── service // 业务逻辑 ├── mapper // MyBatis-Plus的Mapper接口 ├── entity // 实体类 ├── dto // 前端传参的封装对象 ├── vo // 返回给前端的数据对象 ├── config // 配置类拦截器、分页插件、跨域 ├── common // 统一返回结果、异常处理、常量 └── util // JWT工具等分层的核心价值是可替换。比如以后要把图书查询从MySQL换成Redis缓存只动Service层Controller和前端完全不用改。很多同学上一秒写完代码下一秒就忘了层边界写久了Service里全是SQLController里全是业务判断项目就烂了。分层不是给老师看的是给自己维护项目时省时间的。4.2 统一返回结构和全局异常处理前后端分离接口如果各写各的返回格式前端对接时会非常痛苦。我通常规定一个ResultT类public class ResultT { private Integer code; private String message; private T data; }成功时code 200未登录时code 401业务错误时code 500或自定义错误码。再配合RestControllerAdvice做全局异常处理这样Controller里不用写一堆try-catch。一个实际收益库存不足、购物车为空、参数校验失败这些业务异常统一抛一个BizException前端响应拦截器看见message直接弹出提示。这样代码干净而且线上排查问题时错误信息是统一格式一眼就能找到问题位置。4.3 登录鉴权用JWT还是Session前后端分离项目里JWT比Session更常见。核心区别一句话Session把状态存在服务器内存JWT把状态存在客户端令牌里。图书商城用JWT的流程是用户提交用户名密码后端校验通过后生成token返回前端。前端将token存在localStorage每次请求在Authorization: Bearer token头里带回来。后端写一个拦截器从请求头里解析token解析成功就把用户信息放到ThreadLocal或请求属性里后续代码随时能拿到当前用户。后台管理接口额外校验用户角色是否为管理员。密码存储必须强调数据库里不能存明文。至少用MD5加盐或者直接用BCrypt。BCryptPasswordEncoder是Spring Security里的标配安全性比MD5高一个量级。我建议项目里直接用BCrypt实现的代码量也就多两行答辩时却是一个加分项。4.4 图书列表查询条件构造器、分页和排序图书列表是前台最常调的接口核心需求是分类筛选关键字搜索排序分页。分页直接使用MyBatis-Plus分页插件使用方式// 配置类里注册分页插件 Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; }排序字段有讲究。如果按价格排序前端传sortprice_asc或price_desc按销量排序就按sales字段倒序。这里要注意排序字段不能直接用前端字符串拼进SQL否则有SQL注入风险。用条件构造器里的orderBy字段名在代码里定死只允许前端选择几种枚举值。另外图书表的量级在课设里很小几十上百本哪怕LIKE %keyword%这种写法不走索引也没关系。但如果以后数据大了就得考虑全文索引或Elasticsearch这个可以在扩展思路里提不用在课设里提前优化。4.5 购物车的增删改查购物车的接口不多但有三个细节值得注意。第一添加购物车时要先查一下当前用户购物车里是否已有这本书。有就加数量没有才新增记录。如果每次点击都无条件插入就会产生同一本书的多条购物车记录前端展示和结算都会出问题。有了唯一约束后端判断起来也简单先查询命中则更新数量否则插入。第二修改数量时要做库存上限校验。用户可以输一个很大的数比如999后端必须和stock比对超过库存直接拒绝或者截断到库存值。前端也可以限制输入框最大值但后端校验才是真正的防线。第三购物车属于强用户维度的数据。所有操作接口都要先取当前登录用户的userId再执行业务。很多初学同学漏掉用户维度结果A用户的购物车被B用户看得到这种bug在验收演示时非常尴尬。4.6 下单事务和库存扣减整个项目最该讲清楚的地方下单是整个项目最核心的链路也是答辩老师最爱深挖的地方。完整流程是获取当前用户ID。查询用户选中的购物车项前端传购物车记录ID列表或全选标志。逐项检查图书是否存在、库存是否足够。用数据库里的图书价格重新计算总金额不信任前端传过来的价格字段。插入订单头和订单明细状态为待付款。扣减库存删除对应购物车项。提交事务。第3到第6步必须放在同一个事务里用Transactional标注。道理很简单订单创建成功、库存扣减失败或者库存扣了、订单没建成都会让数据变得不一致。事务保证这些操作要么全部成功要么全部回滚。库存扣减的SQL建议写成这样UPDATE t_book SET stock stock - 1 WHERE id #{bookId} AND stock 1用受影响行数判断扣减是否成功如果返回0说明库存不足也没扣成功直接抛异常回滚。这种写法比先查库存再Update库存安全因为它在数据库层做了原子限制。虽然课设没人在意并发但答辩时能说出我用带条件的更新防止超卖已经是超过平均水平的回答。4.7 订单状态流转和模拟支付订单状态不能随便跳。待付款的订单可以取消也可以模拟支付已支付的订单管理员才能发货已发货的订单用户确认收货后变已完成。我的做法是写一个OrderStatusService只暴露几个语义化方法pay(orderId)cancel(orderId)ship(orderId)confirm(orderId)每个方法内部校验当前状态是否允许流转到目标状态。比如ship只接受状态为待发货的订单如果用户对一个待付款订单调ship直接抛当前订单状态不允许此操作。这种集中式状态管理比在Controller里散着一堆if判断要清晰得多。模拟支付不需要真的接第三方支付在订单支付接口里把状态从待付款改成待发货记录支付时间就算完成了。但要在代码注释里说明这里只模拟了支付回调结果真实项目对接支付宝/微信支付时是通过异步通知来更新订单状态的。4.8 封面上传和静态资源映射图书封面走文件上传。后端接收MultipartFile校验文件类型和后缀保存到一个本地目录返回/uploads/cover/xxx.jpg这样的访问路径。保存路径和URL映射是经常踩坑的地方。开发环境下需要写一个配置类把本地目录映射成URLOverride public void addResourceHandlers(ResourceHandlerRegistry registry) { String uploadPath System.getProperty(user.dir) /upload/; registry.addResourceHandler(/upload/**) .addResourceHandler(ResourceUtils.FILE_URL_PREFIX uploadPath); }注意Windows和Linux的路径分隔符不同建议路径拼接用File.separator或者直接写成/upload/让Java自己适配。演示时如果封面图显示不出来十有八九就是上传路径和映射路径对不上。5. 前端重点路由、组件通信和接口对接的实战细节5.1 前端目录结构和路由划分前端项目建议按页面组织目录而不是按类型堆文件。src ├── api // 所有接口请求方法 ├── assets // 静态资源 ├── components // 公共组件分页、上传、菜单等 ├── router // 路由配置 ├── store // 状态管理Pinia/Vuex ├── views // 页面组件 │ ├── front // 前台页面 │ └── admin // 后台页面 └── utils // axios封装、工具函数路由配置是前后端的桥梁。前台以/front为父路径子路由是首页、图书列表、图书详情、购物车、订单、个人中心后台以/admin为父路径子路由是图书管理、分类管理、订单管理、用户管理。用meta字段做角色标记管理端路由挂在admin父路由上路由守卫里统一判断。router.beforeEach((to, from, next) { const token localStorage.getItem(token); if (to.meta.requiresAuth !token) { next(/login); } else if (to.meta.role admin getRole() ! admin) { next(/); } else { next(); } });5.2 axios封装拦截器和统一错误提示axios封装的核心是拦截器。请求拦截器里把token塞进Header响应拦截器统一处理codeservice.interceptors.request.use(config { const token localStorage.getItem(token); if (token) config.headers.Authorization Bearer token; return config; }); service.interceptors.response.use(res { const { code, message } res.data; if (code 200) return res.data; if (code 401) { localStorage.clear(); router.push(/login); } ElMessage.error(message); return Promise.reject(res.data); });这样做的直接收益是业务页面里不需要每次请求都写错误弹窗逻辑接口报错有一处兜底。另一个隐蔽收益是后端凡是改状态、改数据的地方返回信息是否合理前端一眼就能看出问题方便联调时快速定位是前端还是后端的问题。5.3 组件通信不要什么都塞进全局状态Vue组件通信有三档方案按需选择父子组件用props和emit这是最常见的场景。比如图书卡片组件接收一个book对象点击时emit(click-book, bookId)。跨越多个层级、多页共享的数据用Pinia/Vuex。比如购物车数量角标、当前登录用户信息全局只存一份。页面跳转传参用query或路由参数比如详情页传入bookId。很多初学者一上来就把所有数据放进全局状态结果页面刷新后状态全没了又要重新请求接口反而更复杂。我的建议是能用路由解决的用路由能用props的用props只有跨页面共享的才用全局状态。购物车数量角标这种需要全局刷新的数据放store图书列表的筛选条件不要放store放页面内部就行。Vue插槽是一个容易被忽略但很实用的特性。页面布局里后台管理端的页面结构几乎一样只有内容区不同。把布局抽成公共组件内容区域用slot /占位子页面只需填充自己的内容代码量会少很多。理解插槽的概念相当于理解了布局组件的写法对阅读项目源码很有帮助。5.4 图书列表页搜索防抖和分页联动图书列表页是前台最复杂的交互页面我在里面遇到过不少细节问题。搜索框如果每次都触发请求用户输入一个词会发出十几次请求。实操中给输入事件加防抖比如停止输入300ms后再请求let timer; function onSearch(keyword) { clearTimeout(timer); timer setTimeout(() { loadBooks(keyword); }, 300); }分页和筛选条件必须联动。分类切换时应该把页码重置为1否则在第5页切换分类当前页可能已经超出总页数列表会空。排序方式变化同样的道理。这是我调试时踩过的一个真实问题纯粹是逻辑顺序没设计好。加载状态也要处理请求期间显示loading空数据显示暂无相关图书。这些细节不会写进课程设计报告里但演示的时候体验完全不一样。5.5 购物车数量和结算的并发交互购物车的数量调整我建议做成改完即调接口哪怕看起来多了一些请求也比本地改完再统一提交要稳妥。本地先改UI再批量提交一旦中途有接口失败前端状态和后端数据就同步不上了。还有一个容易被忽略的问题是请求竞态。用户连续点按钮两次请求的响应可能后发先至导致购物车数量显示成旧值。简单处理方案是数量增减按钮在请求期间禁用等上一次请求完成再允许下一次点击复杂方案是给每次请求加请求序号响应返回时只采用最新序号的结果。课设用禁用方案就足够了。结算按钮点击后如果后端返回401token过期或者库存不足前端要能还原购物车页面而不是白屏。响应拦截器里已经统一弹错页面只要保证不跳转崩掉就行。6. 联调与部署本地跑通和演示的关键步骤6.1 环境准备MySQL在Windows上的安装细节环境问题占了项目跑不通原因的一半我把最常用的MySQL 5.7.44在Windows上的安装步骤写清楚按这个流程能少走很多弯路。step1去官网下载MySQL 5.7.x的ZIP版不要追求最新版5.7.44是这个系列的最后一个版本稳定。 step2解压到一个纯英文路径例如D:\mysql-5.7.44-winx64。 step3在根目录新建my.ini文件内容至少包含[mysqld] basedirD:/mysql-5.7.44-winx64 datadirD:/mysql-5.7.44-winx64/data port3306 character-set-serverutf8mb4step4以管理员身份打开cmd进入bin目录执行mysqld --initialize-insecure。这一步生成data目录--initialize-insecure表示初始root账号密码为空。 step5安装服务并启动mysqld -install然后net start mysql。 step6执行mysql -u root -p回车进入用ALTER USER rootlocalhost IDENTIFIED BY 你的密码;设置密码。这个流程我在多个问题上验证过比msi安装包少很多弹窗也更容易排查问题。MySQL 8.0的安装流程类似只是默认认证插件是caching_sha2_passwordJDBC连接时驱动版本要用新一些的mysql-connector-java否则可能报认证错误。如果发现连接时报Public Key Retrieval is not allowed在JDBC URL后加allowPublicKeyRetrievaltrue。6.2 数据库初始化SQL脚本导入和字符集检查项目一般会附带bookstore.sql用数据库管理工具Navicat、DataGrip或命令行导入即可。导入完成后建议做三件事一是确认字符集。表与库都建议用utf8mb4因为utf8在MySQL里实际上是utf8mb3存不了emoji和一些生僻字。查询表内是否有乱码直接看图书简介字段。二是检查自增主键。如果导入时表结构里没有AUTO_INCREMENT新增记录时主键可能冲突。查看建表语句确保主键字段是BIGINT或INT UNSIGNED且带自增。三是检查订单表的时间字段默认值。create_time建议直接设DEFAULT CURRENT_TIMESTAMP这样插入时可以省去手动填时间。关于前面提到的用MyBatis-Plus实体类自动生成建表SQL这个方案只适合表结构非常简单的场景像订单明细这种带外键、带逻辑关联的表手写SQL更靠谱。项目里提供一份结构清晰的SQL脚本也方便答辩时老师看数据库设计。6.3 后端配置和启动后端application.yml里最需要关注的是数据源配置和上传路径。spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/bookstore?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 你的密码 server: port: 8080serverTimezoneAsia/Shanghai和characterEncodingutf8是必选项不带的话很可能出现时间差8小时、中文乱码的问题。数据库驱动SpringBoot 2.7.x会自动匹配com.mysql.cj.jdbc.Driver不用手写依赖版本。启动类上加MapperScan(com.example.bookstore.mapper)否则Mapper接口不会被扫描到运行时报找不到Mapper。这个错误非常常见我建议直接规定死所有项目Mapper接口集中在mapper包下启动类配一个MapperScan就够了。后端启动成功的标志是控制台出现Started BookstoreApplication并且localhost:8080能访问到接口示例。如果端口被占用改server.port或者查占用进程。6.4 前端运行npm install 和开发代理前端目录下运行npm install npm run serve如果npm install报错最常见的原因是Node版本和依赖不匹配。Vue 3 Vite对Node版本有要求建议16Vue 2 Webpack老项目对Node要求较低。遇到not found、else之类的报错先看报错的前几行往往写着requires Node.js x.y.z。开发环境跨域问题用Vue CLI的话在vue.config.js里配代理module.exports { devServer: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } };前端请求写/api/...开发环境会代理到后端8080浏览器里不会出现CORS报错。生产部署时由Nginx或后端把静态文件和接口放到同一个域代理职责交给服务器层。还有一个经常被问的问题项目源码怎么发给别人。只打包压缩源码是不够的压缩包之外至少要附带三个说明后端JDK/Maven版本、前端Node版本、数据库初始化脚本的名称。很多人发完源码对方跑不起来不是代码问题是对方环境版本不对。我习惯再写一个README.md把启动步骤从零开始列一遍这个习惯到了正式工作里也非常有用。6.5 演示前必须踩掉的几个坑我把演示前最容易翻车的问题列出来每一件都是实际发生过的事图书封面图显示不出来 → 检查后台上传路径和后端静态资源映射是否一致。前端请求接口变成401 → 检查请求拦截器是否真的带上了token很多情况是登录后没有把token存进localStorage或者拦截器没读对字段。下单报库存不足 → 检查图书表里是否填了库存初始化数据如果都是0客户就会连一本书都买不了。前端构建报tsconfig not found类的错误 → 如果项目使用了TypeScript而你的Node/IDE没有按项目要求加载配置把tsconfig.web.json等文件确认存在即可如果压根不用TypeScript选JavaScript版本的项目源码或者删掉构建配置里对tsconfig的引用。后台管理页面空白 → 多半是接口报错打开浏览器F12看Network按接口逐个排查。演示用的数据也要提前填好至少十个图书分类每个分类两三本带封面的书一个待付款订单、一个已发货订单、一个已完成订单。这样演示时每个状态都能点开看老师想验证的页面都有料。6.6 部署到服务器了解即可不用强求毕设阶段本地演示足够但如果学有余力可以了解部署流程后端打包mvn package生成jarjava -jar运行前端npm run build生成dist目录用Nginx托管把/api请求反向代理到jar端口。用宝塔或用Docker部署都只是手段核心思路是静态页面 后端接口 数据库三方跑通。Docker部署MySQL遇到端口冲突或数据卷权限问题的时候先在本地把MySQL启动方式确认好再上容器化否则排查问题会叠加容器层和数据库层两重难度。7. 答辩与学习建议除了跑起来还要能讲明白7.1 高频答辩问题提前准备不慌场毕设答辩老师不一定读过你的代码但一定会问你为什么这样设计。我把高频问题列一下并给出建议回答思路。问题一前后端分离是什么意思回答思路前端只负责页面渲染和用户交互后端只提供JSON接口两边通过HTTP通信。好处是前端团队和后端团队可以并行开发接口定义清楚就行同一个后端接口可以服务Web、小程序、App多端。问题二你的订单超卖问题怎么解决的回答思路库存扣减用的是UPDATE t_book SET stock stock - ? WHERE id ? AND stock ?这种带条件的SQL数据库在原子操作层面保证了不会扣成负数。同时下单的多个步骤放在一个事务里避免出现订单建了库存没扣的情况。可以坦白说课设场景没有真正的高并发但方案是从防超卖角度设计的。问题三JWT和Session有什么区别回答思路Session由服务器保存适用于单机应用缺点是扩展时需要共享SessionJWT由客户端保存服务端不存状态适合前后端分离和分布式场景。JWT需要处理好过期时间和密钥管理。问题四为什么用MyBatis-Plus不用JPA回答思路MyBatis-Plus既有MyBatis的SQL可控性又封装了单表CRUD学习成本低配合条件构造器写查询比较直观。JPA适合领域驱动设计但复杂查询时的方言差异和SQL调优不算直观课设场景下MyBatis-Plus更合适。问题五数据库有几张表关系是什么回答思路把用户、分类、图书、购物车、订单、订单明细这六张表的关系说清楚重点讲订单和订单明细的一对多为什么拆表。建议答辩前画一张简单的ER图自己在纸上能画出来即可现场讲起来会流畅很多。问题六事务在哪里用到了回答思路下单接口用到了事务。创建订单、扣库存、清购物车必须一起成功或一起失败。用Transactional声明Spring在方法前后自动做事务提交和回滚。7.2 拿到源码后的正确读代码顺序很多人拿到项目源码习惯从pom.xml和package.json开始然后一头扎进某个类里最后什么都没看懂。我建议按业务链路读顺序是先把项目跑起来所有功能点一遍脑子里建立这个系统能干什么的印象。看bookstore.sql理解每张表存什么表之间怎么关联。从登录注册开始前端登录页 → 后端LoginController→UserService→ JWT工具 → 前端路由守卫。这一条链路能让你理解请求是怎么从页面走到数据库又返回页面的。再看图书列表接口的多条件查询和分页理解LambdaQueryWrapper的用法。最后精读下单接口这是整个项目逻辑最集中的地方值得一行一行看。读代码的时候要有打断点的习惯。在关键方法里打上断点用Debug模式跑一遍看每个变量的值是怎么变化的比盯着代码猜快得多。我见过太多同学把代码背下来了但Debug模式一开就懵就是因为平时没有真正追踪过代码执行过程。7.3 时间充裕的话可以延展的方向如果毕设要求较高或者自己想学得再深一点有几个扩展方向性价比很高。给首页热点图书加Redis缓存图书列表访问频率高缓存到Redis后能明显减少数据库压力也能顺理成章地学会缓存穿透、缓存击穿这些概念。引入支付宝沙箱支付把模拟支付替换成真实的沙箱环境流程会复杂一些但演示时非常有说服力。给搜索加Elasticsearch图书搜索体验会大幅提升但部署和索引同步需要额外时间适合学有余力的同学。做接口幂等性处理用户重复点击下单按钮防止生成重复订单。可以用唯一订单号约束或者前端按钮防重。用Docker部署整套环境把MySQL、后端、前端做成容器写一份docker-compose配置以后部署到任何机器上都方便。这些方向不用全做挑一个感兴趣的做到位答辩时的差别就很明显了。老师通常不会要求你把所有东西都做完但希望看到你对下一步能做什么有思考。7.4 学习心态项目是载体能力才是目的最后说点掏心窝的话。这套源码的作用是参考和借鉴不是让你交差了事。我见过不少人直接拿网上的源码改个名字就交了答辩时连自己系统的登录接口在哪个文件里都不知道被老师一问就露馅。正确做法是把它当成一个参考答案自己动手把关键模块敲一遍特别是订单和库存这两条链路哪怕写得慢也值得。改一两个功能是很好的起步练习。比如把图书换成课程把分类改成两级分类或者给订单加一个申请退款的流程。这些改动会让你被迫理解原有代码的结构一旦你能独立完成这类小改动这套技术栈就算是真正入门了。做课设和毕设本质上是在证明一件事你能独立把一个想法拆成功能、设计成表、写成代码、跑通演示并且能讲清楚每一步为什么这么做。技术会过时但这套拆解问题和交付结果的能力是能一直带走的。我个人在带人做这类项目时的体会是跑不起来远比功能少更致命。所以环境版本一定锁死SQL脚本一定要全README一定要写清楚。这些看似不起眼的工程习惯才是托管源码和即兴开发之间真正的差距。希望这份图书商城项目的拆解能帮你把每一步都走得踏踏实实。
