做了很多年开发看过不少学生的毕设选题印象最深的不是那些复杂炫技的系统而是我当年自己做的“藏区特产销售平台”这个毕业设计。当时就想着与其再去做一个千篇一律的图书商城、二手交易平台不如扎进一个真实存在的业务场景里。高原特色产品确实有销售难、信任难的问题把这些真实痛点落到系统功能上这套电商系统就一下子“活”了。这篇博文就完整复盘一下这个毕设从选题、需求拆解、表设计、核心功能实现到部署和答辩的全过程想拿来做毕设或者想完整学一遍全栈电商开发的可以直接照着这条链路去落地。1. 选题动机与需求边界特产电商比“百货商城”好在哪1.1 为什么是特产类电商电商老题目的差异化切口电商系统是计算机专业毕设里最不缺的题目但大多数人都做成了“图书商城”“数码商城”的换皮版本。这类题目有个致命问题业务太薄。商品表、订单表、购物车表一建增删改查一写系统就没了答辩的时候除了CRUD什么都讲不出来。特产类电商不一样它天然带了一批普通商城没有的业务属性。我第一次走访调研时发现高原特色产品牦牛肉干、青稞制品、高原菌类、民族手工艺品的销售场景里有几个非常具体的诉求第一消费者对“是不是正宗原产”极度敏感买到假货是最大顾虑第二同类特产价格差异大几十块到几百块都有规格还五花八门散装、礼盒装、袋装第三食品类的保质期和储存条件必须在商品页显著展示第四偏远地区发货物流周期长用户下单前需要明确提示。这些诉求直接转译成系统功能就是商品需要多规格SKU、商品详情需要“产地/海拔/采摘时间/质检信息”的溯源展示、订单流程需要精细的状态管理和物流提示。这些东西一旦做出来答辩时讲的就是“我如何用系统解决真实业务问题”而不是“我封装了一个分页查询”。1.2 需求边界毕设不要贪大控制成“小而完整”我见过太多同学一上来就规划十多个模块多商家入驻、分销裂变、直播带货样样都要最后做了三个月连主流程都没跑通。做毕设一定要有边界意识。当时我把范围严格控制在“自营模式”下拆成三类角色角色核心诉求主要功能游客看商品、了解产地信息商品浏览、分类检索、溯源信息查看注册用户购买商品、管理订单注册登录、购物车、下单支付、评价、收藏、积分平台管理员维护商品和订单商品/分类管理、溯源信息录入、订单发货、用户管理、数据统计再往下做需求分层。基础功能必须完整注册登录、商品浏览、加入购物车、下单、模拟支付、订单状态流转、后台发货管理。亮点功能要做透商品溯源信息模块和订单状态机这两个是能拿出来打的东西。加分项能做就做优惠券满减、签到积分、基于浏览记录的简单推荐。这样划分之后工作量和答辩亮点都清晰了。2. 技术选型与数据库设计稳妥组合里的门道2.1 为什么是Spring Boot Vue 3这套组合我当时选型时没有追求新潮用的是最成熟、资料最多、也最容易自圆其说的一套后端Spring Boot 2.7 MyBatis Plus MySQL 8 Redis前端Vue 3 Element Plus Axios Pinia认证用JWT。选这个组合的理由很实在。Spring Boot生态成熟遇到任何问题都能搜到解决方案MyBatis Plus能把单表CRUD的代码量砍掉大半省出来的时间可以投入业务逻辑Vue 3 Element Plus做后台管理界面效率很高而且前后端分离的结构本身就比传统的JSP模板工程化程度高答辩时可以把“工程化实践”作为一个亮点来说。也有同学问为什么不直接上微服务、用Spring Cloud。我的判断是毕设的复杂度要合理。一个自营特产电商单体应用完全够用微服务引入的分布式事务、服务治理问题自己都解释不清反而成为答辩的减分项。技术选型的关键不是“用得新”而是“说得清”。2.2 核心表结构订单表和商品表是重中之重数据库设计是整套系统的地基我最终沉淀出这些核心表用户表user、分类表category、商品表product、SKU表product_sku、购物车表cart_item、订单表orders、订单项表order_item、商品溯源表product_traceability、评价表comment、收藏表favourite、优惠券表coupon、用户优惠券表user_coupon、用户行为记录表user_behavior。商品表product是前台所有页面的数据源头关键字段包括商品名称name、副标题subtitle、分类idcategory_id、主图main_image、展示价格price、最低起售规格、状态status上架/下架、产地origin_place、保质期shelf_life、销量sales、库存总数字段red还有关联溯源信息的traceability_id。这里有个经验商品表一定要保留“销量”字段并定时更新前台排序功能直接依赖它不要每次都去订单表里聚合计算否则数据量一大接口就变慢。订单表orders我格外强调两个设计点第一使用自增主键id做内部标识同时生成业务订单号order_no比如时间戳用户id随机数订单号加唯一索引。这个设计后来在做沙箱支付回调时帮了大忙幂等判断直接查order_no即可非常干净。第二订单状态status字段用整数枚举从0到5分别代表“待付款→待发货→待收货→已完成→已取消→退款/售后”状态流转全部通过枚举常量控制而不是散落的字符串判断。还有一张容易被忽略但很关键的表商品溯源表product_traceability。字段包括溯源编号trace_no、产地origin_place、海拔altitude、采摘/生产时间harvest_time、质检报告编号inspection_report、认证图片cert_images、详细描述description。这是特产电商区别于普通商城的功能差异化来源也直接支撑了后面的“信任设计”。数据库的核心建表逻辑可以用下面这几个片段概括简化版CREATE TABLE product ( id BIGINT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(128) NOT NULL, category_id BIGINT NOT NULL, main_image VARCHAR(255), price DECIMAL(10,2), origin_place VARCHAR(64), shelf_life VARCHAR(32), sales INT DEFAULT 0, status TINYINT DEFAULT 1, version INT DEFAULT 0, traceability_id BIGINT, detail TEXT, create_time DATETIME ); CREATE TABLE orders ( id BIGINT AUTO_INCREMENT PRIMARY KEY, order_no VARCHAR(32) NOT NULL UNIQUE, user_id BIGINT NOT NULL, total_amount DECIMAL(10,2), status TINYINT DEFAULT 0, receiver_name VARCHAR(32), receiver_phone VARCHAR(16), receiver_address VARCHAR(255), pay_type TINYINT, out_trade_no VARCHAR(64), create_time DATETIME );2.3 文件存储与图片处理毕设阶段本地存储就够了特产商品的图片质量直接决定用户的购买欲所以图片上传是刚需。我最终没有接入云存储OSS而是用了最直接的方案前端将图片上传到后端接口后端把文件保存到服务器指定目录比如/usr/local/upload并通过一个ResourceHandler把/upload/**路径映射为静态资源访问路径。前端商品图直接使用“域名路径”访问。为什么不用OSS因为毕设阶段要考虑成本、配置复杂度以及答辩时的可解释性。本地存储的逻辑一句话就能讲清楚不会给自己挖坑。不过有一个细节必须注意Nginx配置静态资源目录时一定要确保运行用户对上传目录有读写权限否则文件传上去会返回403。这个坑我后面单独讲。3. 从商品上架到订单完成核心业务链路的落地实现3.1 多级分类与商品检索高原特产品类多粗分成“特色食品”“手工艺品”“滋补养生”几大类还不够食品下面还要分“牛肉干”“青稞制品”“菌菇干货”。所以分类表我设计成自关联结构字段id、parent_id、name、level、sort。递归层级最多三级后台创建分类时选择父分类前台导航栏按顶级分类聚合展示。这里有个实践经验展示商品分类树时不要写递归循环去反复查数据库否则性能很难看。正确做法是一次性把所有分类查出来在Java内存里组装成树形结构然后缓存到Redis或应用本地缓存数据变更时再刷新。代码逻辑大概是ListCategory all categoryMapper.selectList(null); MapLong, ListCategory tree all.stream() .collect(Collectors.groupingBy(Category::getParentId));商品检索则比较简单用商品名称和副标题做模糊查询再配合分类筛选、价格区间、销量/价格排序。MyBatis Plus的LambdaQueryWrapper就能搞定关键是在SQL里给category_id和status字段建好索引不然商品多了以后筛选会慢。3.2 购物车与下单事务库存不能减成负数购物车表cart_item的核心字段就是user_id、sku_id、quantity、checked是否选中。加入购物车、修改数量、删除、勾选这些都是常规CRUD但有一个细节购物车里展示的商品价格、商品名称要从SKU表实时联表查询而不能在加入购物车时把价格固定存进去因为后台改价后购物车数据会失真。下单流程是整个系统里最考验基本功的部分。我当时把下单拆成几个步骤放在同一个事务里执行根据请求参数生成订单项快照商品名、SKU规格、单价、数量、小计计算订单总金额扣除用户可用的优惠券金额乐观锁扣减库存生成订单主记录状态为“待付款”删除对应的购物车记录。为什么库存扣减要用乐观锁当时我第一个版本用的是“先查询库存再执行update扣减”结果并发测试时直接出现库存变成负数的情况。这是典型的超卖问题。原理解释一下两个请求同时读到库存为1然后各自执行减1最后库存变成-1。解决方式很简单在SQL层面加条件判断UPDATE product_sku SET stock stock - #{quantity}, version version 1 WHERE id #{skuId} AND stock #{quantity} AND version #{version}如果更新影响行数为0说明库存不足或版本号冲突就抛出“库存不足”的异常回滚事务。事务加乐观锁既简单又能把超卖问题彻底解决。这段代码在答辩时被评委专门问过能讲清楚原理是加分项。3.3 订单状态机与沙箱支付回调必须做幂等订单状态是整个系统的“脊梁骨”所有业务流程都在围绕它转用户提交订单后状态为待付款用户点击支付跳转到支付沙箱页面支付成功后系统收到异步回调将订单状态变为待发货管理员在后台发货后变为待收货用户确认收货后变为已完成。用户也可以在待付款状态取消订单或者发起退款申请。这里最难的是支付回调的处理。我当时接的是沙箱支付环境支付流程是后端统一下单拿到支付链接→前端跳转支付→沙箱环境支付成功后向回调地址发送通知→后端接收通知、验签、更新订单状态。这个链路里有两个必须处理的坑第一个坑是回调重复通知。支付平台为了保证通知一定送达会发多次回调如果每次回调都直接改状态就会出现重复操作。解决方案是幂等处理收到回调先根据order_no查询订单如果已经是“待发货”状态直接返回成功不重复更新。第二个坑是回调顺序和用户操作冲突。比如用户支付前取消了订单回调才姗姗来迟如果代码不校验就会把“已取消”的订单改成“已支付”。所以每次状态流转都必须做合法性校验我封装了一个状态流转校验的方法private void checkOrderStatus(Order order, int expectStatus) { if (order.getStatus() ! expectStatus) { throw new BusinessException(订单状态异常当前状态 order.getStatus()); } }只允许从合法状态流转到目标状态非法流转直接拒绝这套规则能挡住绝大多数的订单状态错乱问题。4. 平台差异化亮点把“信任”做成功能4.1 商品溯源信息模块买得放心的核心逻辑特产电商最大的痛点是信任。线下买特产担心假货线上买更担心。我在设计时专门做了一个“商品溯源”模块每一款商品都关联一条溯源记录详情页用独立的区块展示产品产地、海拔范围、采摘/生产时间、质检报告编号、认证图片。用户点进商品详情第一屏是商品图和价格往下滑就能看到这块溯源信息。后台对应一个溯源信息管理页面管理员维护每个商品的溯源数据。这个模块看起来不复杂但业务价值很高。在毕业设计里它是“我有意识地将业务问题转化为系统功能”的证明比多做十个CRUD接口都有说服力。数据上就是前面说的product_traceability表前端展示时用卡片式布局把产地信息和证书图片罗列清楚设计感也上来了。4.2 基于浏览记录的轻量推荐低成本实现“猜你喜欢”完整的推荐系统需要复杂的算法和离线计算毕设根本不用上。我就做了一个基于用户行为记录的轻量推荐定义一张user_behavior表记录用户浏览过哪些商品、点击过哪些分类、搜索过哪些关键词推荐逻辑是查询当前用户最近查看过的商品所属分类从这些分类下找出销量靠前的其他商品按照浏览时间加权排序展示在商品列表底部的“猜你喜欢”。虽然逻辑简单但演示效果很生动在测试账号里先浏览几个青稞制品刷新首页“猜你喜欢”区块就出现了青稞类的其他热销商品。这种即时反馈会让评委觉得系统是“活”的而不是一堆静态页面。4.3 优惠券与积分花小力气加分的促销闭环促销是电商的标配我加了两个轻量功能优惠券和签到积分。优惠券表coupon记录面额、使用门槛、有效期、发行数量用户可以在“领券中心”领取结算时选择可用券抵扣。签到积分更简单用户每天签到增加积分积分可以按比例抵扣金额。这两块功能的数据表和业务逻辑都不复杂但能让整个系统的业务完整性上一个台阶尤其适合在答辩时演示“从领券到抵扣再到订单金额变化”的完整闭环。5. 开发过程实录三个把我折腾够呛的坑5.1 中文乱码问题一层一层查出来的第一次部署到云服务器我立刻发现两个诡异现象数据库里存入的商品名称变成了“???”接口返回的JSON里中文正常但导出报表时中文全部乱码。这是典型的编码链路问题。排查思路是从上到下检查前端请求头带的是UTF-8后端Spring的字符编码过滤器默认也是UTF-8问题就出在数据库连接串上。我的解决方案是在JDBC URL中加入参数characterEncodingutf8并且显式指定useSSLfalse、serverTimezoneAsia/Shanghai。字符编码这种问题最迷惑人的地方在于它不一定在哪个环节出错所以排查一定要按“请求→后端→数据库连接→表结构”逐层确认。5.2 并发扣库存超卖问题从出现到修复这个坑前面提过这里把完整排查过程复盘一遍。当时我写了个简单的接口测试工具模拟两个线程同时购买同一件只剩1件库存的商品。跑完一看库存变成了-1两个订单居然都“下单成功”了。第一反应是检查Service方法是否加了事务确认有Transactional然后又检查了SQL发现是“先select库存判断大于0再update减1”的老写法。两个请求并发执行时都通过了判断都执行了更新自然就超卖了。修复方案就是换成乐观锁的原子更新把“检查库存”和“扣减库存”合并成一条SQL。这个修复不只是改一行代码而是理解了并发环境下“检查与执行分离”的问题本质。后来我又顺手给商品SKU表加了version字段并在更新条件里带上版本号双保险。5.3 支付回调与订单状态冲突取消后还能被改成已支付有一次测试时发现用户取消订单后那条订单居然在几分钟后变成了“待发货”。查日志之后真相大白用户点击取消订单时支付平台的异步回调已经在网络链路里了等回调到达服务端时代码没有校验当前订单状态直接把状态改成了待发货。修复方案就是前面提到的状态校验方法所有状态变更都必须显式传入期望的当前状态。同时我还加了一个判断如果订单已取消但支付回调到达自动为用户发起原路退回并记录备注。这个场景在答辩时非常有故事性评委问“支付和业务状态怎么保持一致”我直接给出这个案例和解决方案比自己背概念强得多。6. 部署、演示与答辩准备别让前期努力毁在最后一步6.1 云服务器部署跑通一遍后面就顺了部署环境我用了最朴素的方式一台云服务器安装JDK 8、MySQL、Redis、Nginx。前端打包成dist目录放到Nginx的html路径下后端打成jar包用nohup方式启动。核心命令大概是这样# 构建前端 npm run build # 启动后端 nohup java -jar specialty-platform.jar \ --spring.profiles.activeprod app.log 21 # Nginx 配置 server { listen 80; server_name example.com; root /usr/share/nginx/html/dist; location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } location /upload/ { alias /usr/local/upload/; } }部署过程里最大的教训是先本地通、后服务器通。很多同学本地一切正常一上服务器就白屏多半是前端打包后的静态资源路径问题或后端配置的数据库连接串不对。我在服务器上部署时前后端分离接口报错第一件事就是去看app.log日志根据堆栈提示去调整配置而不是一头扎进Nginx配置里折腾半天。6.2 演示数据与演示脚本细节决定答辩效果答辩演示是最容易被忽视的部分。当时我准备了完善的演示数据八个分类下面总共放了二十多个商品每个商品都有高清主图、完整溯源信息和适量库存注册了三个测试账号一个专门用于演示领券和签到。演示时我按照“新用户注册→首页浏览→搜索“牦牛肉”→查看溯源详情→加购→下单→领取优惠券抵扣→沙箱支付→管理员后台发货→用户确认收货→发表评价”的顺序走。这套脚本走下来系统的主要功能全部覆盖故事线完整评委不用中途问“这个功能在哪”。答辩最常见的问题我提前准备了答案为什么要做这个选题答案是特产电商有真实业务痛点溯源设计解决了信任问题和普通商城形成差异化。为什么用这套技术栈答案是生态成熟、资料多、前后端分离结构清晰、个人能完全掌控。并发超卖怎么解决讲上面的乐观锁方案并说明事务边界。如果用户量变大了怎么办讲优化方向Redis缓存热点商品、读写分离、静态资源上CDN、按业务拆分服务。当初做完这个毕设最大的感受是电商平台最难的从来不是增删改查而是那些藏在业务里的边界情况——并发、状态冲突、重复通知、编码错乱。把它们一个个解决掉系统才算真正立住了。最后再分享一个我后来一直沿用的小习惯核心表在建模阶段就把唯一索引和状态流转规则定死比如订单号order_no字段建唯一索引后面接支付、接对账、接任何外部系统都会少踩很多坑。做毕设不要怕改代码怕的是不知道自己要解决什么问题。把这份思路理清楚你的项目就已经赢了一半。
做了很多年开发看过不少学生的毕设选题印象最深的不是那些复杂炫技的系统而是我当年自己做的“藏区特产销售平台”这个毕业设计。当时就想着与其再去做一个千篇一律的图书商城、二手交易平台不如扎进一个真实存在的业务场景里。高原特色产品确实有销售难、信任难的问题把这些真实痛点落到系统功能上这套电商系统就一下子“活”了。这篇博文就完整复盘一下这个毕设从选题、需求拆解、表设计、核心功能实现到部署和答辩的全过程想拿来做毕设或者想完整学一遍全栈电商开发的可以直接照着这条链路去落地。1. 选题动机与需求边界特产电商比“百货商城”好在哪1.1 为什么是特产类电商电商老题目的差异化切口电商系统是计算机专业毕设里最不缺的题目但大多数人都做成了“图书商城”“数码商城”的换皮版本。这类题目有个致命问题业务太薄。商品表、订单表、购物车表一建增删改查一写系统就没了答辩的时候除了CRUD什么都讲不出来。特产类电商不一样它天然带了一批普通商城没有的业务属性。我第一次走访调研时发现高原特色产品牦牛肉干、青稞制品、高原菌类、民族手工艺品的销售场景里有几个非常具体的诉求第一消费者对“是不是正宗原产”极度敏感买到假货是最大顾虑第二同类特产价格差异大几十块到几百块都有规格还五花八门散装、礼盒装、袋装第三食品类的保质期和储存条件必须在商品页显著展示第四偏远地区发货物流周期长用户下单前需要明确提示。这些诉求直接转译成系统功能就是商品需要多规格SKU、商品详情需要“产地/海拔/采摘时间/质检信息”的溯源展示、订单流程需要精细的状态管理和物流提示。这些东西一旦做出来答辩时讲的就是“我如何用系统解决真实业务问题”而不是“我封装了一个分页查询”。1.2 需求边界毕设不要贪大控制成“小而完整”我见过太多同学一上来就规划十多个模块多商家入驻、分销裂变、直播带货样样都要最后做了三个月连主流程都没跑通。做毕设一定要有边界意识。当时我把范围严格控制在“自营模式”下拆成三类角色角色核心诉求主要功能游客看商品、了解产地信息商品浏览、分类检索、溯源信息查看注册用户购买商品、管理订单注册登录、购物车、下单支付、评价、收藏、积分平台管理员维护商品和订单商品/分类管理、溯源信息录入、订单发货、用户管理、数据统计再往下做需求分层。基础功能必须完整注册登录、商品浏览、加入购物车、下单、模拟支付、订单状态流转、后台发货管理。亮点功能要做透商品溯源信息模块和订单状态机这两个是能拿出来打的东西。加分项能做就做优惠券满减、签到积分、基于浏览记录的简单推荐。这样划分之后工作量和答辩亮点都清晰了。2. 技术选型与数据库设计稳妥组合里的门道2.1 为什么是Spring Boot Vue 3这套组合我当时选型时没有追求新潮用的是最成熟、资料最多、也最容易自圆其说的一套后端Spring Boot 2.7 MyBatis Plus MySQL 8 Redis前端Vue 3 Element Plus Axios Pinia认证用JWT。选这个组合的理由很实在。Spring Boot生态成熟遇到任何问题都能搜到解决方案MyBatis Plus能把单表CRUD的代码量砍掉大半省出来的时间可以投入业务逻辑Vue 3 Element Plus做后台管理界面效率很高而且前后端分离的结构本身就比传统的JSP模板工程化程度高答辩时可以把“工程化实践”作为一个亮点来说。也有同学问为什么不直接上微服务、用Spring Cloud。我的判断是毕设的复杂度要合理。一个自营特产电商单体应用完全够用微服务引入的分布式事务、服务治理问题自己都解释不清反而成为答辩的减分项。技术选型的关键不是“用得新”而是“说得清”。2.2 核心表结构订单表和商品表是重中之重数据库设计是整套系统的地基我最终沉淀出这些核心表用户表user、分类表category、商品表product、SKU表product_sku、购物车表cart_item、订单表orders、订单项表order_item、商品溯源表product_traceability、评价表comment、收藏表favourite、优惠券表coupon、用户优惠券表user_coupon、用户行为记录表user_behavior。商品表product是前台所有页面的数据源头关键字段包括商品名称name、副标题subtitle、分类idcategory_id、主图main_image、展示价格price、最低起售规格、状态status上架/下架、产地origin_place、保质期shelf_life、销量sales、库存总数字段red还有关联溯源信息的traceability_id。这里有个经验商品表一定要保留“销量”字段并定时更新前台排序功能直接依赖它不要每次都去订单表里聚合计算否则数据量一大接口就变慢。订单表orders我格外强调两个设计点第一使用自增主键id做内部标识同时生成业务订单号order_no比如时间戳用户id随机数订单号加唯一索引。这个设计后来在做沙箱支付回调时帮了大忙幂等判断直接查order_no即可非常干净。第二订单状态status字段用整数枚举从0到5分别代表“待付款→待发货→待收货→已完成→已取消→退款/售后”状态流转全部通过枚举常量控制而不是散落的字符串判断。还有一张容易被忽略但很关键的表商品溯源表product_traceability。字段包括溯源编号trace_no、产地origin_place、海拔altitude、采摘/生产时间harvest_time、质检报告编号inspection_report、认证图片cert_images、详细描述description。这是特产电商区别于普通商城的功能差异化来源也直接支撑了后面的“信任设计”。数据库的核心建表逻辑可以用下面这几个片段概括简化版CREATE TABLE product ( id BIGINT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(128) NOT NULL, category_id BIGINT NOT NULL, main_image VARCHAR(255), price DECIMAL(10,2), origin_place VARCHAR(64), shelf_life VARCHAR(32), sales INT DEFAULT 0, status TINYINT DEFAULT 1, version INT DEFAULT 0, traceability_id BIGINT, detail TEXT, create_time DATETIME ); CREATE TABLE orders ( id BIGINT AUTO_INCREMENT PRIMARY KEY, order_no VARCHAR(32) NOT NULL UNIQUE, user_id BIGINT NOT NULL, total_amount DECIMAL(10,2), status TINYINT DEFAULT 0, receiver_name VARCHAR(32), receiver_phone VARCHAR(16), receiver_address VARCHAR(255), pay_type TINYINT, out_trade_no VARCHAR(64), create_time DATETIME );2.3 文件存储与图片处理毕设阶段本地存储就够了特产商品的图片质量直接决定用户的购买欲所以图片上传是刚需。我最终没有接入云存储OSS而是用了最直接的方案前端将图片上传到后端接口后端把文件保存到服务器指定目录比如/usr/local/upload并通过一个ResourceHandler把/upload/**路径映射为静态资源访问路径。前端商品图直接使用“域名路径”访问。为什么不用OSS因为毕设阶段要考虑成本、配置复杂度以及答辩时的可解释性。本地存储的逻辑一句话就能讲清楚不会给自己挖坑。不过有一个细节必须注意Nginx配置静态资源目录时一定要确保运行用户对上传目录有读写权限否则文件传上去会返回403。这个坑我后面单独讲。3. 从商品上架到订单完成核心业务链路的落地实现3.1 多级分类与商品检索高原特产品类多粗分成“特色食品”“手工艺品”“滋补养生”几大类还不够食品下面还要分“牛肉干”“青稞制品”“菌菇干货”。所以分类表我设计成自关联结构字段id、parent_id、name、level、sort。递归层级最多三级后台创建分类时选择父分类前台导航栏按顶级分类聚合展示。这里有个实践经验展示商品分类树时不要写递归循环去反复查数据库否则性能很难看。正确做法是一次性把所有分类查出来在Java内存里组装成树形结构然后缓存到Redis或应用本地缓存数据变更时再刷新。代码逻辑大概是ListCategory all categoryMapper.selectList(null); MapLong, ListCategory tree all.stream() .collect(Collectors.groupingBy(Category::getParentId));商品检索则比较简单用商品名称和副标题做模糊查询再配合分类筛选、价格区间、销量/价格排序。MyBatis Plus的LambdaQueryWrapper就能搞定关键是在SQL里给category_id和status字段建好索引不然商品多了以后筛选会慢。3.2 购物车与下单事务库存不能减成负数购物车表cart_item的核心字段就是user_id、sku_id、quantity、checked是否选中。加入购物车、修改数量、删除、勾选这些都是常规CRUD但有一个细节购物车里展示的商品价格、商品名称要从SKU表实时联表查询而不能在加入购物车时把价格固定存进去因为后台改价后购物车数据会失真。下单流程是整个系统里最考验基本功的部分。我当时把下单拆成几个步骤放在同一个事务里执行根据请求参数生成订单项快照商品名、SKU规格、单价、数量、小计计算订单总金额扣除用户可用的优惠券金额乐观锁扣减库存生成订单主记录状态为“待付款”删除对应的购物车记录。为什么库存扣减要用乐观锁当时我第一个版本用的是“先查询库存再执行update扣减”结果并发测试时直接出现库存变成负数的情况。这是典型的超卖问题。原理解释一下两个请求同时读到库存为1然后各自执行减1最后库存变成-1。解决方式很简单在SQL层面加条件判断UPDATE product_sku SET stock stock - #{quantity}, version version 1 WHERE id #{skuId} AND stock #{quantity} AND version #{version}如果更新影响行数为0说明库存不足或版本号冲突就抛出“库存不足”的异常回滚事务。事务加乐观锁既简单又能把超卖问题彻底解决。这段代码在答辩时被评委专门问过能讲清楚原理是加分项。3.3 订单状态机与沙箱支付回调必须做幂等订单状态是整个系统的“脊梁骨”所有业务流程都在围绕它转用户提交订单后状态为待付款用户点击支付跳转到支付沙箱页面支付成功后系统收到异步回调将订单状态变为待发货管理员在后台发货后变为待收货用户确认收货后变为已完成。用户也可以在待付款状态取消订单或者发起退款申请。这里最难的是支付回调的处理。我当时接的是沙箱支付环境支付流程是后端统一下单拿到支付链接→前端跳转支付→沙箱环境支付成功后向回调地址发送通知→后端接收通知、验签、更新订单状态。这个链路里有两个必须处理的坑第一个坑是回调重复通知。支付平台为了保证通知一定送达会发多次回调如果每次回调都直接改状态就会出现重复操作。解决方案是幂等处理收到回调先根据order_no查询订单如果已经是“待发货”状态直接返回成功不重复更新。第二个坑是回调顺序和用户操作冲突。比如用户支付前取消了订单回调才姗姗来迟如果代码不校验就会把“已取消”的订单改成“已支付”。所以每次状态流转都必须做合法性校验我封装了一个状态流转校验的方法private void checkOrderStatus(Order order, int expectStatus) { if (order.getStatus() ! expectStatus) { throw new BusinessException(订单状态异常当前状态 order.getStatus()); } }只允许从合法状态流转到目标状态非法流转直接拒绝这套规则能挡住绝大多数的订单状态错乱问题。4. 平台差异化亮点把“信任”做成功能4.1 商品溯源信息模块买得放心的核心逻辑特产电商最大的痛点是信任。线下买特产担心假货线上买更担心。我在设计时专门做了一个“商品溯源”模块每一款商品都关联一条溯源记录详情页用独立的区块展示产品产地、海拔范围、采摘/生产时间、质检报告编号、认证图片。用户点进商品详情第一屏是商品图和价格往下滑就能看到这块溯源信息。后台对应一个溯源信息管理页面管理员维护每个商品的溯源数据。这个模块看起来不复杂但业务价值很高。在毕业设计里它是“我有意识地将业务问题转化为系统功能”的证明比多做十个CRUD接口都有说服力。数据上就是前面说的product_traceability表前端展示时用卡片式布局把产地信息和证书图片罗列清楚设计感也上来了。4.2 基于浏览记录的轻量推荐低成本实现“猜你喜欢”完整的推荐系统需要复杂的算法和离线计算毕设根本不用上。我就做了一个基于用户行为记录的轻量推荐定义一张user_behavior表记录用户浏览过哪些商品、点击过哪些分类、搜索过哪些关键词推荐逻辑是查询当前用户最近查看过的商品所属分类从这些分类下找出销量靠前的其他商品按照浏览时间加权排序展示在商品列表底部的“猜你喜欢”。虽然逻辑简单但演示效果很生动在测试账号里先浏览几个青稞制品刷新首页“猜你喜欢”区块就出现了青稞类的其他热销商品。这种即时反馈会让评委觉得系统是“活”的而不是一堆静态页面。4.3 优惠券与积分花小力气加分的促销闭环促销是电商的标配我加了两个轻量功能优惠券和签到积分。优惠券表coupon记录面额、使用门槛、有效期、发行数量用户可以在“领券中心”领取结算时选择可用券抵扣。签到积分更简单用户每天签到增加积分积分可以按比例抵扣金额。这两块功能的数据表和业务逻辑都不复杂但能让整个系统的业务完整性上一个台阶尤其适合在答辩时演示“从领券到抵扣再到订单金额变化”的完整闭环。5. 开发过程实录三个把我折腾够呛的坑5.1 中文乱码问题一层一层查出来的第一次部署到云服务器我立刻发现两个诡异现象数据库里存入的商品名称变成了“???”接口返回的JSON里中文正常但导出报表时中文全部乱码。这是典型的编码链路问题。排查思路是从上到下检查前端请求头带的是UTF-8后端Spring的字符编码过滤器默认也是UTF-8问题就出在数据库连接串上。我的解决方案是在JDBC URL中加入参数characterEncodingutf8并且显式指定useSSLfalse、serverTimezoneAsia/Shanghai。字符编码这种问题最迷惑人的地方在于它不一定在哪个环节出错所以排查一定要按“请求→后端→数据库连接→表结构”逐层确认。5.2 并发扣库存超卖问题从出现到修复这个坑前面提过这里把完整排查过程复盘一遍。当时我写了个简单的接口测试工具模拟两个线程同时购买同一件只剩1件库存的商品。跑完一看库存变成了-1两个订单居然都“下单成功”了。第一反应是检查Service方法是否加了事务确认有Transactional然后又检查了SQL发现是“先select库存判断大于0再update减1”的老写法。两个请求并发执行时都通过了判断都执行了更新自然就超卖了。修复方案就是换成乐观锁的原子更新把“检查库存”和“扣减库存”合并成一条SQL。这个修复不只是改一行代码而是理解了并发环境下“检查与执行分离”的问题本质。后来我又顺手给商品SKU表加了version字段并在更新条件里带上版本号双保险。5.3 支付回调与订单状态冲突取消后还能被改成已支付有一次测试时发现用户取消订单后那条订单居然在几分钟后变成了“待发货”。查日志之后真相大白用户点击取消订单时支付平台的异步回调已经在网络链路里了等回调到达服务端时代码没有校验当前订单状态直接把状态改成了待发货。修复方案就是前面提到的状态校验方法所有状态变更都必须显式传入期望的当前状态。同时我还加了一个判断如果订单已取消但支付回调到达自动为用户发起原路退回并记录备注。这个场景在答辩时非常有故事性评委问“支付和业务状态怎么保持一致”我直接给出这个案例和解决方案比自己背概念强得多。6. 部署、演示与答辩准备别让前期努力毁在最后一步6.1 云服务器部署跑通一遍后面就顺了部署环境我用了最朴素的方式一台云服务器安装JDK 8、MySQL、Redis、Nginx。前端打包成dist目录放到Nginx的html路径下后端打成jar包用nohup方式启动。核心命令大概是这样# 构建前端 npm run build # 启动后端 nohup java -jar specialty-platform.jar \ --spring.profiles.activeprod app.log 21 # Nginx 配置 server { listen 80; server_name example.com; root /usr/share/nginx/html/dist; location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } location /upload/ { alias /usr/local/upload/; } }部署过程里最大的教训是先本地通、后服务器通。很多同学本地一切正常一上服务器就白屏多半是前端打包后的静态资源路径问题或后端配置的数据库连接串不对。我在服务器上部署时前后端分离接口报错第一件事就是去看app.log日志根据堆栈提示去调整配置而不是一头扎进Nginx配置里折腾半天。6.2 演示数据与演示脚本细节决定答辩效果答辩演示是最容易被忽视的部分。当时我准备了完善的演示数据八个分类下面总共放了二十多个商品每个商品都有高清主图、完整溯源信息和适量库存注册了三个测试账号一个专门用于演示领券和签到。演示时我按照“新用户注册→首页浏览→搜索“牦牛肉”→查看溯源详情→加购→下单→领取优惠券抵扣→沙箱支付→管理员后台发货→用户确认收货→发表评价”的顺序走。这套脚本走下来系统的主要功能全部覆盖故事线完整评委不用中途问“这个功能在哪”。答辩最常见的问题我提前准备了答案为什么要做这个选题答案是特产电商有真实业务痛点溯源设计解决了信任问题和普通商城形成差异化。为什么用这套技术栈答案是生态成熟、资料多、前后端分离结构清晰、个人能完全掌控。并发超卖怎么解决讲上面的乐观锁方案并说明事务边界。如果用户量变大了怎么办讲优化方向Redis缓存热点商品、读写分离、静态资源上CDN、按业务拆分服务。当初做完这个毕设最大的感受是电商平台最难的从来不是增删改查而是那些藏在业务里的边界情况——并发、状态冲突、重复通知、编码错乱。把它们一个个解决掉系统才算真正立住了。最后再分享一个我后来一直沿用的小习惯核心表在建模阶段就把唯一索引和状态流转规则定死比如订单号order_no字段建唯一索引后面接支付、接对账、接任何外部系统都会少踩很多坑。做毕设不要怕改代码怕的是不知道自己要解决什么问题。把这份思路理清楚你的项目就已经赢了一半。
