最近帮几个准备做毕业设计的朋友看项目选型发现Java Web方向的题目还是占了大头其中电子类产品销售系统这类“经典商城业务”几乎是每年都出现的熟面孔。但和三五年前清一色的SSH、SSM单体架构不同现在稍微有点竞争力的项目基本都是前后端分离的路子SpringBoot2负责后端接口Vue3做前端页面MyBatis-Plus操作数据库MySQL8.0当存储底座。这套组合在GitHub上随便一搜就是一大堆但真到自己动手搭起来从环境准备到联调部署处处都有坑。这篇文章我就以“Java Web电子产品销售系统”这个实战项目为线索把这套SpringBoot2 Vue3 MyBatis-Plus MySQL8.0技术栈从选型逻辑到实操要点完整过一遍重点说清楚那些教程里不会明说的细节。不管你是拿它做毕业设计还是刚入职想快速上手公司里的前后端分离项目这篇都能给你省下不少折腾的时间。1. 从“为什么是这套技术栈”说起版本选型的底层逻辑先聊点务虚的因为很多新手拿到源码第一步就急着跑起来结果环境版本一塌糊涂报错报得怀疑人生。你首先要理解SpringBoot2 Vue3 MyBatis-Plus MySQL8.0这个组合不是随便拼的每一个版本选择都有它的现实理由。1.1 SpringBoot2企业级项目的中坚力量SpringBoot3虽然已经发布但很多公司的存量项目、教学资源和各种开源脚手架仍然停留在SpringBoot2.x。原因也很实际SpringBoot2基于Java 8生态兼容性极广——老的第三方库、自己封装的基础组件、各种老旧系统的对接都不需要额外费劲适配。而SpringBoot3强制要求Java 17一些机构的教学环境、云服务器里装的还是JDK 8硬上新版本反而处处掣肘。从毕业设计的角度来说SpringBoot2的资料量也是碾压级的遇到问题一搜就有答案不像SpringBoot3有些坑还在靠社区慢慢填。从企业项目角度来说在JDK8仍被大量使用的现实背景下SpringBoot2就是最稳妥的生产选择。1.2 Vue3不是单纯升级是写法的换代Vue3带来的核心变化不是“更快了”这么简单而是Composition API让组件的逻辑复用方式彻底改变了。在Vue2时代你写一个功能可能要靠mixin把逻辑散落到各个组件里项目一大根本分不清数据是从哪来的。Vue3用一套setup语法加组合式函数hooks可以把登录逻辑、购物车逻辑、商品列表逻辑各自封装成独立模块需要的地方直接引入。另外Vue3对TypeScript的支持是Vue2没法比的。电子销售系统这种涉及商品多规格、订单状态流转、库存增减的项目数据结构的约束特别重要用TypeScript写起来心里踏实得多。虽然这套源码未必用了TS但你理解了Vue3的语法思维后面自己加模块、改逻辑都会顺很多。1.3 MyBatis-Plus告别“数据库操作焦虑”如果你用过原生MyBatis一定记得写基础CRUD时那种“明明就是一条SQL的事偏偏要写一堆xml映射”的无语。MyBatis-Plus的价值就在这儿单表操作直接继承BaseMapper方法名都不用自己起分页、条件构造、逻辑删除全部内置。它的底层思路是通过Java反射机制在运行时根据实体类的元信息动态生成SQL。我举个直观例子// 传统方式要先写接口、xml、resultMap再写SQL ListProduct selectByCategory(String category); // MyBatis-Plus方式继承BaseMapper后直接用 LambdaQueryWrapperProduct wrapper new LambdaQueryWrapper(); wrapper.eq(Product::getCategory, 手机) .gt(Product::getStock, 0) .orderByDesc(Product::getSales); ListProduct list productMapper.selectList(wrapper);注意Product::getCategory这种写法这是Lambda表达式配合SFunction接口生成的方法引用MyBatis-Plus拿到这个引用再分析出对应的数据库列名从而避免了字符串硬编码。实体类字段改了查询条件自动跟着改重构起来很舒服。1.4 MySQL8.0不是新功能的问题是坑不一样MySQL8.0相比5.7默认字符集变成了utf8mb4意味着emoji表情也能正常存进去支持窗口函数、公共表表达式这些新特性。但很多人在安装环节就卡住了尤其是Windows环境下的zip版本安装、Navicat连接时的caching_sha2_password认证插件问题我后面专门用一节来写这块。2. 电子销售系统的核心模块拆解拿到源码后先读懂这四张表一个电子产品销售系统表面上看就是个“商家卖货、用户买货”的简单逻辑但真正落地到数据库设计和后端接口你会发现需要处理的东西比想象中多。我建议拿到源码别急着跑先把下面四个核心模块的数据流梳理清楚。2.1 商品模块分类、参数与库存的三角关系商品模块是整个系统的地基它的核心是SPU标准产品单元和SKU库存量单位这两个概念。简单说SPU是“iPhone 15 Pro”这个商品条目SKU是“iPhone 15 Pro 黑色 256G”这个具体可下单的规格。在你看到的数据库里SPU相关的信息可能放在商品主表里SKU则挂在子表里字段差异主要体现在价格、库存、规格JSON这几个地方priceSKU级别才有实际意义因为不同规格可以定价不同stock必须放在SKU级别不然“黑色卖完了蓝色还有”这种场景没法处理specs多数项目用JSON字段存规格组合比如{颜色: 黑色, 存储: 256GB}MySQL8.0的JSON类型在这里就派上用场了你可以直接用JSON_EXTRACT去查询某个规格的商品灵活性比传统字符串拼接好得多。就拿我帮朋友调过的一个项目来说商品详情页展示规格选择器时前端需要把当前商品的所有SKU一次性拉下来。如果后端只提供“商品列表”接口前端就要自己做聚合很容易把规格颜色和规格存储搞错层级。所以这套系统里比较科学的接口设计是这样的GetMapping(/sku/{spuId}) public ResultListSkuVO listBySpu(PathVariable Long spuId) { ListSku skuList skuService.list( new LambdaQueryWrapperSku().eq(Sku::getSpuId, spuId) ); // 按规格键分组方便前端渲染规格选择器 MapString, ListString specGroup skuList.stream() .collect(Collectors.groupingBy( Sku::getSpecKey, Collectors.mapping(Sku::getSpecValue, Collectors.toList()) )); // 返回给前端时同时带上原始SKU列表 return Result.success(skuList); }这里的LambdaQueryWrapper避免了手写SQLstream().collect()则把规格数据聚合好前端拿到之后直接渲染选择器不用再做二次处理。2.2 用户与购物车会话状态的两种玩法用户模块的常见玩法是JWTJSON Web Token鉴权——用户登录成功之后后端签发一个带过期时间的token前端把它存在localStorage或pinia里每次请求通过Authorization头带回来。后端用一个拦截器解析token、拿到userId然后塞到ThreadLocal里供后续业务使用。购物车则是另一个值得细看的地方。新手项目最常见的做法是单纯把购物车数据放前端用localStorage存这样做确实省事但一换设备购物车就丢了。稍微像样一点的项目都要求购物车数据落库后台要能统计用户的加购行为。落库的逻辑其实不复杂核心就一个防重复public void addToCart(Long userId, Long skuId, Integer count) { CartItem exist cartItemMapper.selectOne( new LambdaQueryWrapperCartItem() .eq(CartItem::getUserId, userId) .eq(CartItem::getSkuId, skuId) ); if (exist ! null) { exist.setCount(exist.getCount() count); cartItemMapper.updateById(exist); } else { CartItem item new CartItem(); item.setUserId(userId); item.setSkuId(skuId); item.setCount(count); item.setChecked(true); cartItemMapper.insert(item); } }这个逻辑体现了MyBatis-Plus另一层价值通用的单表CRUD写起来非常直给你只需要关心业务规则本身不用关心SQL怎么拼。selectOne配合LambdaQueryWrapper天然规避了拼接字符串的SQL注入风险——所有条件都通过参数化处理这一点在写实体查询时要形成肌肉记忆。2.3 订单与支付事务和状态机的真实考场电子销售系统里最考验代码功力的就是订单创建。扣库存、生成订单、清购物车、算优惠这四个操作必须在一个事务里完成任何一个失败都要整体回滚。SpringBoot提供的Transactional注解在这里是标配Transactional(rollbackFor Exception.class) public Long createOrder(Long userId, ListOrderItemParam items) { // 1. 锁定库存乐观锁先查版本号再更新 // 2. 生成订单主记录状态为待支付 // 3. 生成订单明细 // 4. 清空购物车中已下单的商品 return orderId; }注意rollbackFor Exception.class这个细节。Spring默认只回滚RuntimeException如果你在业务方法里抛了个受检异常事务可能不会回滚数据就出问题了。写事务注解时一律指定rollbackFor是最稳妥的习惯。订单状态这里我强烈建议你用枚举而不是直接存int数字。一个订单有待支付、已支付、已发货、已完成、已取消、已退款。如果你在代码里到处写if(status 1)过两周你自己都忘了1是已支付还是待支付。用下面这种枚举代码的可读性和健壮性都会好很多public enum OrderStatus { PENDING_PAYMENT(待支付), PAID(已支付), SHIPPED(已发货), COMPLETED(已完成), CANCELLED(已取消), REFUNDED(已退款); private final String desc; OrderStatus(String desc) { this.desc desc; } }2.4 后台管理权限模型和报表统计后台管理模块是区分“普通增删改查”和“真正可交付项目”的分水岭。电子产品销售系统的后台至少需要商品管理、订单管理、用户管理、统计看板。权限模型推荐经典的RBAC基于角色的访问控制也就是用户—角色—菜单三层结构。落到代码里就是管理员登录后后端根据角色查出对应菜单权限前端根据权限动态生成侧边栏菜单。MyBatis-Plus的selectList配合in条件可以非常优雅地完成权限数据的批量查询不用自己手拼SQL。统计看板是另一个让项目加分的设计。比如“近七天销售额趋势”这样的功能用MySQL8.0的窗口函数可以写得很优雅SELECT DATE(create_time) AS day, SUM(amount) OVER (PARTITION BY DATE(create_time) ORDER BY create_time) AS daily_sum FROM orders WHERE create_time DATE_SUB(CURDATE(), INTERVAL 7 DAY)顺带说一句MySQL8.0相比5.7对GROUP BY的语义检查严格了很多假设你开了ONLY_FULL_GROUP_BY8.0默认开启查询列必须全部出现在GROUP BY里或用聚合函数包住否则直接报错。这也是很多5.7老项目迁移到8.0后第一个暴露的问题。3. Vue3前端搭建的实战细节从环境搭建到组件通信的踩坑记如果你之前是Vue2的写法习惯刚切Vue3一定会有一段“这代码怎么这么写”的阵痛期。这一节我按前端项目的搭建顺序把容易出问题的地方一个一个过一遍。3.1 环境搭建使用Vite还是Vue CLIVite现在已经是Vue3项目的事实标准创建速度快、热更新快配置文件也简洁。建议直接用官方推荐的方式npm create vitelatest electronic-shop-front # 进入项目目录后安装依赖 npm install # 启动开发服务 npm run dev比起Vue CLIVite在开发依赖的安装上有个明显区别它默认按需编译所以首次启动时内容少页面会极快内容多时也不必等整个项目做完整编译——只有浏览器请求到的模块才会实时编译这是开发体验上的巨大提升。不过Vite也有坑。最典型的就是环境变量命名Vite只暴露以VITE_开头的环境变量到客户端代码如果你在.env文件里写了个API_BASE_URL前端是访问不到的必须写成VITE_API_BASE_URL。我见过好几次团队里有人把变量名写错结果一直拿不到后端地址报404报了半天。3.2 Pinia比Vuex更轻的状态管理方案Vue3时代官方推荐用Pinia读音“皮尼亚”它和Vuex最大的区别是不再需要写那么多mutations样板代码store里的state可以直接通过函数修改。拿购物车状态来举例用Pinia可以这样写export const useCartStore defineStore(cart, () { // state const items ref([]) const totalCount computed(() items.value.reduce((sum, i) sum i.count, 0)) // actions function addItem(product) { items.value.push(product) } return { items, totalCount, addItem } })computed(() ...)在组合式写法里承担了Vuex中getter的角色reduce()方法负责累加计算逻辑非常直观。Pinia底层的响应式机制也是基于Vue3的ref和computed实现上手门槛反而比Vuex低了不少。3.3 组件通信父子传值、事件通信与全局状态组件通信是Vue3前端开发中最容易写乱的地方。我的建议是遵守下面这套原则1. 父传子用props。注意Vue3里props是只读的子组件不能直接修改否则会得到警告。正确的做法是子组件内部用一个ref接收初始值然后自行维护// 子组件 const props defineProps({ currentCategory: { type: Number, required: true } }) // 用 ref 接收一次之后内部操作这个ref const activeCategory ref(props.currentCategory)2. 子传父用emit。比如删除购物车某项// 子组件 const emit defineEmits([remove]) const handleRemove (id) emit(remove, id)3. 跨组件共享状态用Pinia。别再用$bus事件总线那一套了多个组件依赖同一个数据源的时候统一放store里通过store来计算衍生数据如总金额、总数量比手动传递清晰百倍。前端开发的核心思维是状态驱动视图页面上出现什么内容完全取决于store或组件内部的数据。写好数据流页面渲染自然就对数据流混乱改一个显示就要连带改五六处地方。3.4 页面路由与异步组件提升首屏不开发的懒加载技巧商品列表页、商品详情页、购物车、结算页、后台管理……一个系统几十个页面如果全部打包进首屏js白屏时间会非常长。解决办法就是路由懒加载const routes [ { path: /, component: () import(../views/Home.vue) }, { path: /product/:id, component: () import(../views/ProductDetail.vue) } ]箭头函数形式的() import(...)会把对应代码拆分成独立分块只有访问到该路由时才加载。这个“按需加载”的思路在后台管理这种模块较多的系统里尤其受益——管理员只访问自己管辖的页面其他模块的代码就不用提前下载。如果你发现某个动态路由加载时总要先转圈圈还可以配一个全局loading组件配合router.beforeEach((to, from, next) { // 在这里做页面标题、登录鉴权、loading开关的统一处理 if (!document.title) document.title to.meta.title || 电子商城 next() })这段全局前置守卫是Vue Router老用法到Vue3依然有效你把它当作所有路由跳转的“统一入口检查点”来理解就行。4. SpringBoot2后端开发重点MyBatis-Plus的进阶使用与常见坑前端只是皮肉后端才是这套系统的骨架。这一节我把MyBatis-Plus在真实电子商城项目里的用法展开讲透顺带把它们在同项目中踩过的常见坑都抖出来。4.1 条件构造器不要再用字符串拼接查询条件很多从JDBC时代过来的老手写查询第一反应是拼SQL字符串。这在MyBatis-Plus里是大忌你应该用LambdaQueryWrapper它既能防注入又能保证字段名经过编译期检查。对比一下// 错误示范字符串拼接 QueryWrapperProduct wrapper new QueryWrapper(); wrapper.eq(category, 手机); // 列名硬编码重构实体字段时不会报错 // 推荐写法Lambda表达式 LambdaQueryWrapperProduct wrapper new LambdaQueryWrapper(); wrapper.eq(Product::getCategory, 手机);如果你在一个项目里看到大量QueryWrapper写法强烈建议改成LambdaQueryWrapper的版本。前者在SQL注入上虽然框架层做了转义但字段名的拼写错误查起来非常隐蔽——你只会得到一条“字段不存在”的数据库报错而这类报错排查起来特别费时。4.2 分页插件不要把内存分页当饭吃MyBatis-Plus的分页插件PaginationInnerInterceptor是物理分页也就是说通过拦截器在SQL尾部拼接LIMIT ? OFFSET ?而不是把所有数据查回来再在内存里截取。配置方式要在配置类里注入拦截器Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }页面上的商品列表、订单列表、用户列表全部通过这个分页插件做前端传页码和页大小后端返回带总数和当前页数据的Page对象。一个特别注意的地方是count查询在数据量大时会自动优化但遇到多表关联的复杂查询分页插件生成的count SQL可能不够精准需要你手动提供count查询否则分页总数不准。4.3 逻辑删除用状态位代替真实DELETE电商系统的用户、订单、商品都不能真正物理删除否则历史数据就没了对账、审计全没依据。MyBatis-Plus支持逻辑删除你只需在实体类的删除标志字段上加上注解TableLogic private Integer deleted;之后你调用deleteById时框架自动把它转成UPDATE ... SET deleted 1 WHERE id ?而所有查询都会自动加上deleted 0条件。这个能力一旦用好项目的安全性和数据完整性都会上一个台阶。唯一的坑是如果你的数据库里有些表已经有物理删除记录的旧习惯切换逻辑删除后已有的统计报表要重新核对基数。4.4 代码生成器从表结构到实体类的自动化产出写到后端时你可能会嫌一堆实体类、Mapper接口、Service接口写起来太重复。MyBatis-Plus官方提供了一个代码生成器连接数据库后自动从表结构生成Entity、Mapper、Service、Controller这四层代码生成完你只需要补充业务逻辑和SQL效率直接翻倍。它的底层逻辑是读取数据库元数据information_schema里的表结构信息把列类型映射成Java类型把下划线表名转换为驼峰类名再通过Freemarker或Velocity模板渲染出代码文件。特别注意代码生成的表格结构设计要求是列名带下划线而不是驼峰这样生成的资料才能与默认配置匹配。如果你数据库里已经浑水摸鱼用了驼峰列名生成代码时要么配置了map-underscore-to-camel-case要么手动改字段映射不然运行时会报列不存在的错。4.5 跨域与统一返回体让前端不发愁前后端分离有个绕不开的问题——跨域。开发环境下前端跑在5173端口后端跑在8080端口浏览器默认会拦截异源请求。解决方式有很多但我建议后端统一配置一个CorsFilter一次配好全部路径生效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); } }同时后端要统一设计响应体结构。我习惯用这样一个泛型包装类Getter public class ResultT { private Integer code; private String message; private T data; public static T ResultT success(T data) { ResultT result new Result(); result.code 200; result.message success; result.data data; return result; } public static T ResultT error(Integer code, String message) { ResultT result new Result(); result.code code; result.message message; return result; } }前端只认200是成功其他code统一进错误分支这样联调效率极高。需要注意的是任何接口返回结构都裹上Result后前端代码里取数据层的路径结构也统一了统一是res.data.data或者封装好的hooks里再解一层不会出现有的接口返回数组、有的接口返回对象、有的是裸string这种要人命的混乱。5. MySQL8.0安装与配置指南开发环境最容易翻车的节点这一节是很多人实际动手跑项目时第一个卡住的地方我把从下载到连接的全流程拆开把你可能遇到的所有坑提前排一遍。5.1 Windows环境zip版还是installer版MySQL官方提供两种安装方式installer图形化安装最省心适合不常折腾环境的人zip压缩包版适合想彻底掌握配置的人。zip版本的安装步骤是到MySQL官网下载mysql-8.0.x-winx64.zip解压到指定目录比如D:\mysql-8.0.36-winx64在解压目录下新建my.ini配置文件这是zip版与installer版最大的区别。以下是一个最简可用配置[mysqld] basedirD:/mysql-8.0.36-winx64 datadirD:/mysql-8.0.36-winx64/data port3306 character-set-serverutf8mb4 default-authentication-pluginmysql_native_password配置里的datadir指向数据库物理文件目录第一次启动时如果目录不存在mysql会尝试创建。default-authentication-plugin这一行我建议不要略过因为后面Navicat连接时很多报错都是认证插件不兼容引起的。以管理员身份打开命令行进入bin目录执行mysqld --initialize-insecure这条命令会生成data目录并创建一个免密码的root账户。如果你用--initialize则会生成一个随机root密码放在日志文件里新手容易找不到。注册Windows服务并启动mysqld --install mysql8 net start mysql85.2 Navicat连接报2059错误认证插件不兼容这是MySQL8.0时代最经典的坑。Navicat老版本连接8.0数据库时往往会报Authentication plugin caching_sha2_password cannot be loaded原因是MySQL8.0默认的认证插件换成了caching_sha2_password老版客户端不认识。解决办法有两种推荐第一种ALTER USER rootlocalhost IDENTIFIED WITH mysql_native_password BY 你的新密码; FLUSH PRIVILEGES;不过需要提醒的是在MySQL8.0较新版本中官方已经不推荐再用mysql_native_password了所以你如果用的是最新版Navicat或DBeaver直接保留默认认证插件即可不需要改动。只有当你必须使用老客户端时才需要把账号切回mysql_native_password。5.3 重置忘记的root密码如果你自己装了MySQL之后又把密码忘了这几乎是每个人都会经历一遍的操作流程分两步。先以跳过授权表方式启动net stop mysql8 mysqld --skip-grant-tables此时再开一个新命令行窗口直接输入mysql -u root无需密码就能进去执行FLUSH PRIVILEGES; ALTER USER rootlocalhost IDENTIFIED BY 新密码;注意第5.2节里的mysql_native_password在第5.3节场景下不需要写因为--skip-grant-tables跳过了授权验证。5.4 Docker方式安装MySQL8.0云服务器上的最佳实践如果你用的是云服务器或没有图形界面的Linux环境Docker安装MySQL8.0是效率最高的方式。一条命令搞定docker run -d \ --name mysql8 \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORDyourpassword \ -e MYSQL_DATABASEelectronics \ -v /opt/mysql/data:/var/lib/mysql \ mysql:8.0一键起跑的背后有个需要注意的点-v /opt/mysql/data:/var/lib/mysql这个数据卷挂载让MySQL的数据文件落在宿主机磁盘上容器删了重建数据还在。生产环境绝不能为了省事而不挂数据卷否则容器一删数据库就全没了。另外Docker容器里的MySQL默认时区是UTC要把时区改成北京时间在运行参数里加--default-time-zone08:00否则插入时间会比正常时间早8个小时。6. 从能跑到能答辩文档撰写与演示话术的实战经验标题里写着“含文档”这也是很多源码项目的标配卖点同时也是很多同学最容易轻视的部分。我见过太多人代码跑通了最后答辩却被问“这个表为什么这么设计”而卡壳。文档的意义其实是帮你把系统的设计逻辑系统梳理一遍。6.1 一套合格的技术文档至少包含哪些内容系统概述项目背景、技术栈、核心功能、模块划分数据库设计ER图、每张表的字段说明、外键关系、索引设计接口文档每个接口的URL、请求方式、参数表、返回结构环境部署JDK版本、MySQL初始化脚本、前端构建命令、启动步骤数据库设计这块花点时间用工具把字段表和索引列清楚比页面截图管用得多。它同时也是你答辩时应对“为什么这个字段要这么命名”这种问题的底气。再分享一个答辩演示的小技巧准备一份“功能演示清单”把系统的主要页面和操作路径按顺序列出来比如登录→浏览商品→查看详情→添加购物车→下单→支付→后台发货→前台查看订单状态照着清单演示既不会漏功能也不会因为临时想不起菜单位置而冷场。6.2 代码质量自查老师总会注意到的几个点很多人交完源码就被扣分常常不是功能问题而是下面这些代码卫生问题是否使用了魔法值代码里直接写if(status 1)而不是用枚举或常量是否处理了异常分支比如扣库存时库存不足有没有返回友好提示而不是静默失败是否统一了响应结构所有接口是否都返回Result还是有的返回Map有的直接返回实体是否写了必要的校验商品价格是否能传负数下单数量是否能传0最加分也最容易被忽略的一点是在事务方法里正确设置rollbackFor Exception.class以及使用MyBatis-Plus的逻辑删除而不是物理删除。这两点只要在答辩时稍微提一嘴老师就知道你是懂业务约束和工程实践的。7. 这套系统的下一步演进从毕业设计到生产级项目如果你已经把这个系统跑通了甚至顺利答辩了接下来想让它变得更有含金量可以从下面几个方向继续演化。这些方向不仅能丰富简历也能帮助你把技术栈理解得更深。7.1 检索与推荐优化当前的商品列表基本靠关键词或分类查询这是基于LIKE %keyword%的简单实现。但数据量一上去这种写法效率极低也谈不上“智能”。你可以升级到Elasticsearch做商品搜索或者至少用MySQL8.0的全文索引加MATCH ... AGAINST让排序、分词、相关性打分全部升级。7.2 缓存与性能提升Redis在这套系统里的价值空间非常大商品详情页的流量通常远高于下单页把高流量商品信息缓存到Redis再用实时库存做兜底能明显降低数据库压力购物车适用以用户ID为key的hash结构存储读写效率极高首页轮播图、分类菜单等几乎不变的数据直接用本地缓存或Redis缓存需要注意缓存与数据库的一致性问题。最稳的做法是先更新数据库再删除缓存然后配合延迟双删或消息队列来做最终一致。7.3 安全管理与限流系统上线后第一道考验往往是恶意请求。当前你的后台管理接口如果用简单的登录token就能访问权限粒度可能还不够。建议结合拦截器对管理员接口做角色校验对登录接口做验证码对高频接口如评论、搜索做限流。SpringBoot2集成spring-boot-starter-data-redis后用Redis的INCR和EXPIRE做一个简单的滑动窗口限流并不复杂。7.4 部署与运维毕业设计如果只跑在本地演示时要带着电脑到处走遇到网络问题还会翻车。把系统部署到云服务器是加分项。部署链路通常是后端mvn clean package打成jar包上传服务器后用nohup或systemd跑起来前端npm run build生成dist目录交给Nginx托管静态文件并配置代理转发数据库用Docker跑MySQL8.0导入初始化SQL配置后端application.yml里数据库地址、Redis地址改为服务器内网地址或公网可访问地址这个过程中你还会遇到配置文件环境隔离的问题——本地一套、测试一套、生产一套。用SpringBoot的profile机制application-dev.yml、application-prod.yml就能优雅解决这也是面试时经常被问到的点。说实话从“把源码跑起来”到“把整个系统彻底搞懂”中间隔着一次完整的重构调试。我建议你把这个项目当成自己亲手写一遍而不是当成一个黑盒跑通就完事。把所有Controller打开看一遍、把每张表字段对照实体类捋一遍这个过程长出来的本事比收藏十个源码都值钱。