每年都会有一批人拿到“网上超市系统”这个课题无论是课程设计、毕业设计还是期末大作业题目本身看起来平平无奇但真正动手之后会发现页面能打开只是一个开始订单、库存、购物车、后台管理、数据库设计、文档编写每一块都能把你折腾到怀疑人生。这篇博文我就围绕“网上超市系统(源码数据库文档)”这套最经典的项目组合从项目定位、技术选型、表结构设计、核心业务链路、实战踩坑到文档整理完整复盘一遍。如果你正好在做这个题目或者想拿一套现成的数据库脚本和源码改造成自己的项目这篇文章可以直接当参照。网上超市系统的本质不是让你做一个真的能和京东对抗的电商平台而是通过一个完整的企业级业务场景把软件开发全流程走一遍需求分析、数据库建模、业务编码、前后端联调、测试、部署、写文档。所以不要一上来就纠结“商城要多少页面”而是先搞清楚这套系统的边界在哪里。1. 项目定位与功能边界先想清楚要做多大1.1 这套系统到底解决什么问题网上超市系统是典型的B2C电商模型用户通过浏览器浏览商品、加入购物车、下订单、支付或模拟支付管理员在后台维护商品信息、处理订单、管理用户。它的核心业务闭环是用户登录 → 浏览商品 → 加入购物车 → 生成订单 → 订单状态变更。很多初学者拿到这个题目第一反应是“先做个几百张表的系统”这是典型的过度设计。课程设计和毕业设计的评审核心不是功能多而是逻辑完整、结构清晰、文档齐全。一套标准的网上超市系统前台功能至少要有用户注册登录、商品分类展示、商品搜索、商品详情、购物车操作、订单生成与查看、个人信息修改后台功能至少要有管理员登录、商品分类管理、商品信息管理增删改查图片上传、订单管理发货、状态流转、用户管理。如果还想加分可以加商品推荐、销量统计、Excel报表导出、验证码、分页搜索、订单状态定时关闭。这些属于锦上添花不是核心分。1.2 前后台功能边界怎么划功能边界是很多人第一次做项目最容易模糊的地方。比如“搜索”到底属于前台还是后台答案很简单凡是用户C端用到的都算前台凡是管理员B端操作的都算后台。哪怕它们的代码在一个工程里也要在包结构上严格分开。我见过最糟糕的代码结构是所有功能写在同一个类里一个Controller有十几个方法前台后台混在一起数据库表命名也没有统一规则。这种项目就算功能全跑通了评审老师一看代码分数直接掉档。所以我建议从一开始就按controller/user、controller/admin、service、mapper、entity这样的包结构分层后期维护和写文档都会轻松很多。还有一个容易被忽略的点权限控制。管理员的后台操作必须做权限拦截不能只靠隐藏入口。比如用户直接访问/admin/goods/list这个URL是否能打开后台如果没做登录拦截那就是严重漏洞。这个问题在答辩演示时是高频抽查点。1.3 适合哪些人拿去改网上超市系统的源码网上很多GitHub一搜一大把但直接下载下来跑通并不等于你会做。我建议分三种情况对待这套源码如果你是纯小白目的是课程设计过关那先把系统跑起来然后逐个功能走一遍弄清楚每个页面背后调用了哪个接口、操作了哪张表再把数据库脚本拿出来自己建一遍库完成“理解-复现”的过程。如果你有一定基础想拿这个项目做毕设那必须做一定程度的改造。比如把技术栈换成Spring Boot 3.x、引入Redis缓存、加个支付模拟接口这些改动是你答辩时最能说清楚的东西。如果你是想学习技术那这套系统的价值在于“业务链路的完整性”不要只盯着CRUD要把订单的事务处理、购物车的状态同步、分类的树形结构这些业务逻辑吃透。2. 技术选型复盘为什么是Spring Boot MyBatis MySQL组合2.1 需求倒推技术栈我给这套系统定的技术栈是Spring Boot 2.x MyBatis MySQL 8.x Thymeleaf或JSP Bootstrap Layui。这个组合不是最前沿的但恰恰是课程设计和毕业设计中最稳、最容易出文档、最好答辩的组合。为什么选Spring Boot而不是传统的SSMSpring SpringMVC MyBatis核心原因是配置量。SSM需要手写大量XML配置Spring Boot通过自动配置把这些封装好了你能把更多精力花在业务代码上。而且Spring Boot内置Tomcat部署时一个jar包直接跑部署文档也好写。为什么用MyBatis而不是JPA因为MyBatis的SQL是显式写在Mapper里面的评审老师问“你怎么查商品列表的”你直接打开XML给他看SQL比讲ORM的字段映射直观得多。更重要的是MyBatis对复杂SQL友好比如多表联查、分类统计写起来可控性强。2.2 前端方案模板引擎还是前后端分离这是第二个容易纠结的问题。网上超市系统要不要用Vue Spring Boot前后端分离我的建议是除非你被明确要求用前后端分离否则优先用服务端渲染模板引擎Spring Boot的Thymeleaf或者JSP都行。原因有二第一课程设计的重点在业务实现和数据库设计前端分离意味着多一套前端工程、多一套接口文档、多一堆跨域问题总分没有明显提升但工作量翻倍第二模板引擎天然支持页面直接在服务端渲染用户中心、购物车这些需要携带用户信息的页面Session存取非常自然不用额外处理Token鉴权。如果非要用Vue我建议只做局部嵌入比如商品列表页用Vue做筛选排序其余页面还是服务端渲染。这样既能在文档里写“采用了前后端分离的部分实践”又不会把自己坑进跨域和鉴权的泥潭。2.3 关键配置项的实战取值配置层是很多同学拿到源码后第一个失败的地方。不要小看application.yml这里至少有四个坑能让你项目启动失败端口与上下文路径server.port8080如果机器上端口被占用启动会报错改成8081或者别的未被占用的端口即可。数据源配置spring.datasource.url写法是jdbc:mysql://localhost:3306/online_supermarket?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai注意后面三个参数一个都不能少。serverTimezone不配MySQL 8.x 一般会报时区错误characterEncoding不配中文大概率乱码。MyBatis配置mybatis.mapper-locationsclasspath:mapper/*.xml这个一定要写对否则Spring Boot容器启动时报Invalid bound statement当时我排查这个错误花了整整一个下午最后发现是mapper路径少写了一层目录。静态资源映射网上超市肯定要传商品图片默认上传目录是运行目录临时文件夹重启就丢了。我一般会配一个虚拟路径映射把file:D:/upload/映射到/img/**这样图片不随应用重启丢失部署文档里也说得清楚。3. 数据库设计网上超市的核心是表结构不是页面3.1 核心表拆解六张表打底网上超市系统的数据库设计核心是六张表用户表t_user、商品分类表t_category、商品表t_goods、购物车表t_cart_item、订单表t_order、订单明细表t_order_item。如果功能涉及收货地址再加一张t_address。这就是源码包中数据库脚本的主体。这六张表之间的关系是用户表与订单表一对多一个用户可以有多个订单。订单表与订单明细表一对多一个订单包含多个商品项。商品表与分类表多对一一个分类下有多个商品。购物车表同时关联用户和商品是典型的中间表。设计的时候要注意购物车表不一定要建实体表把购物车数据放在Redis或者Session里面也是一种方案。但课程设计阶段建议老老实实建表这样数据库文档有内容可写而且用户关闭浏览器后购物车不丢。3.2 关键字段的设计与取舍每一张表的字段设计都有讲究我挑几个关键的展开说。用户表t_user字段必须包含用户ID、用户名、密码、昵称、手机号、邮箱、注册时间、状态。密码字段注意长度MD5加密后是32位BCrypt加密后是60位如果只用varchar(20)后面加密太弱别人可以爆破加密太强存不进去。建议直接给varchar(64)保守可靠。商品表t_goods是这张设计的重头戏。字段包括商品ID、分类ID、商品名称、副标题、商品图片、商品原价、商品现价、库存、销量、是否上架、创建时间。这里有两个细节很多人想不到第一价格用decimal(10,2)不要用float或double。浮点数在电商金额计算中会丢失精度一单没问题统计一个月订单总额的时候误差就出来了。第二商品的“是否上架”字段每次删除必须软删除也就是is_delete或status字段控制而不是物理删除。否则历史订单明细里关联的商品被删掉订单详情页就会空引用。订单表t_order字段包括订单号、用户ID、总金额、收货人、联系电话、收货地址、订单状态、下单时间、支付时间、发货时间、完成时间。这里要注意订单号不要用自增ID要自己生成一个业务唯一编号。最常用的方案是时间戳 用户ID 随机数拼接后保证唯一。数据库自增ID对外暴露容易被爬虫遍历。订单明细表t_order_item必须冗余存储商品信息快照包括商品ID、商品名称、商品图片、购买单价、购买数量。为什么叫快照因为商品可以改名、改价、甚至下架但订单一旦生成这份交易信息必须保持下单时刻的原样这是电商系统的基本规则。3.3 外键、索引与数据库脚本的组织外键是新手最爱用又最容易搞砸的东西。在这套系统里我的建议是逻辑外键用物理外键少用。也就是在实体关系设计图上画清关系但建表语句里不写FOREIGN KEY约束。原因很简单物理外键在后期删除或插入数据时会限制了灵活性很多互联网公司的生产库都是不用物理外键的。课程设计文档里你照常画ER图和关系图代码里通过业务逻辑控制数据一致性这在项目答辩中是说得通的。索引方面在t_goods表的category_id上建普通索引在t_order表的user_id上建普通索引在t_cart_item表的user_id和goods_id上建联合索引。千万别全表都加索引过度索引会影响写入性能还让数据库备份文件变大这些都是数据库文档里能写出来的优化点。数据库脚本的组织方式也值得说。不要只给一个db.sql文件了事标准的项目结构应该是sql/ init.sql -- 建库建表语句 data.sql -- 初始测试数据分类、商品、账号 update.sql -- 后续变更记录init.sql里建表的语句要保证可重复执行最简单的方式是在建表语句前加DROP TABLE IF EXISTS这样可以反复初始化。data.sql里的测试数据一定要准备20条以上的商品记录覆盖至少5个分类否则前台页面每个分类只有一两个商品演示效果会非常难看。4. 源码模块拆解从登录到下单的完整业务链路4.1 用户模块登录态与权限拦截用户模块是整个系统的入口。登录逻辑不能只做“查一下用户表密码对就放行”至少要考虑三件事密码加密存储、登录状态保持、敏感操作权限控制。密码加密方面我推荐用BCrypt而不是MD5。MD5加盐虽然也能做但BCrypt是自适应哈希强度可调业界口碑和经验都更多。实现不复杂BCryptPasswordEncoder的方法抡几下就能接好。登录状态的保持在Spring Boot Thymeleaf方案下用Session就行。登录成功后把用户实体塞进Session通过拦截器HandlerInterceptor统一检查。注意拦截器要放行登录页、注册页、静态资源、商品浏览和商品详情这些公开页面拦截/cart/**、/order/**、/user/**这些需要登录的路径后台/admin/**单独配置拦截规则检查管理员标识。我见过一个特别隐蔽的权限漏洞后台接口只做了“前端菜单不显示”没有做后端拦截。用户如果能猜到/admin/order/list直接URL访问就能看到所有订单和用户信息。这个漏洞在答辩时被老师抓到过后面的同学一定要长记性。4.2 商品模块分类、检索与分页商品模块是整个系统数据量最大的地方代码层面主要有三块分类展示、商品搜索、商品详情。分类展示这里如果做一级分类就是一个简单的列表查询如果做二级分类就需要在t_category表加parent_id字段通过递归组装成树形结构。很多同学在这里会卡住我给的方案是用一个goodsList方法把分类列表嵌套进ListCategory的层级结构里代码实现逻辑不复杂用树结构遍历拼接即可还能在文档里写“支持无限级分类”展示效果是远超一级分类的。商品搜索最简单的方案是SQL的LIKE %keyword%用goods_name和goods_subtitle两个字段做模糊匹配。如果你觉得全文搜索更专业可以引入Elasticsearch但这样成本很高不建议课程设计阶段碰。普通LIKE查询在数据量不超过一万条的演示环境里完全够用。分页是必考内容MyBatis配PageHelper插件是主流方案。用法很简单PageHelper.startPage(pageNum, pageSize)后面跟的查询自动分页。这里有三个细节要注意前端传来的pageNum要做空值校验否则传一个负数会导致SQL异常。分页后返回的PageInfo对象要取total设置到前端否则前端分页条无法计算总页数。排序规则要在SQL里写清楚比如默认按上架时间倒序ORDER BY create_time DESC这样新商品才能显示在前面。4.3 购物车与订单事务边界与并发扣库存这是整个系统业务复杂度最高的部分如果你想在答辩时拿出“高光时刻”就把这块吃透。购物车逻辑加购、改数量、删商品、计算总价。购物车界面展示的金额永远要实时从t_cart_item关联t_goods表算出当前价不能把商品价格直接存到购物车表里。否则后台改价后用户购物车还显示旧价体验极差。下单逻辑是整个系统最该上事务的地方。标准流程是根据购物车记录查出商品清单计算总金额。校验商品是否上架、库存是否足够。扣减商品库存同时增加销量。生成订单主表和订单明细表。清空购物车对应项。事务提交。这六步必须放在同一个事务里任何一步失败都要整体回滚。实现上就是给Service方法加Transactional注意这个注解要加在public方法上且不能同类内部调用否则事务不起作用。这是很多同学都会踩的坑事务注解加了但异常被自己try-catch吞掉了导致脏数据写入数据库测试阶段怎么查都查不出原因。再一个经典场景是并发扣库存。两个用户同时下单库存只剩一件如果SQL写的是UPDATE t_goods SET stock stock - 1 WHERE goods_id ?这个原子操作能防超卖。但如果你是先SELECT stock再在Java代码里判断if (stock 0)后UPDATE并发下就会出现超卖。答辩时老师特别喜欢问这个问题我建议在代码里用带条件的更新语句作为面试中“乐观锁”思想的简单落地。5. 后台管理端少不了的CRUD怎么做才不Low5.1 商品管理的实现细节后台商品管理是标准的CRUD但有几个实现细节值得打磨。商品列表要分页按分类筛选这个用MyBatis动态SQL写where条件注意条件为空时不能拼接SQL片段否则可能出现WHERE AND的语法错误。新增和修改商品时图片上传是最容易出问题的环节。表单用enctypemultipart/form-data后端用MultipartFile接收。要注意保存图片时不能直接用原始文件名会存在路径穿越和重名覆盖问题建议用UUID.randomUUID().toString() 原文件后缀名重命名并按日期分目录存储比如/upload/2025/04/12/xxx.jpg。修改商品时有个坑前端表单没有上传新图片时后端拿到的MultipartFile是空的如果直接保存会把原来的图片路径覆盖为空。正确做法是空对象判断没传新图就保留原图片字段不变。5.2 订单状态流转与发货逻辑订单状态是后台管理的“生命线”。标准状态机可以设计成待付款 → 待发货 → 已发货 → 已完成另外有已取消状态。后台发货操作是最核心的一个动作用户点“待发货”列表找到订单点击发货状态变更为已发货同时记录发货时间。这张状态流转图在数据库文档里用一个枚举表t_order_status记录会比单纯字段注释讲得更清晰。注意在代码里不要用魔法数字判断状态建议定义常量类或者在枚举里管理状态值否则if (status 1)这种代码一周后你自己都不知道1代表什么。5.3 让后台值回票价的统计报表大部分网上超市源码里的后台管理都是纯CRUD的列表平庸且没有亮点。如果你想拉开和别人差距加一个可视化统计首页今日订单数、今日销售额、累计用户数、商品总数。不需要引入任何复杂框架用ECharts画一个近七日的订单量折线图和各分类商品销量柱状图就行数据源就是两张核心表的分组聚合查询。统计功能在实现上并不复杂写四条聚合SQL就出来但它给项目文档带来的收益非常大需求分析里可以写“提供数据可视化决策支持”测试用例里可以写“图表数据与数据库记录一致”答辩时这一页PPT能讲三分钟。6. 真的会踩的坑与排查链路6.1 问题一图片上传后访问404这是我见过频率最高的问题。现象是图片上传成功D:/upload目录里能看到文件但浏览器访问http://localhost:8080/img/xxx.jpg报404。排查链路是这样的首先确认上传路径是对的其次确认数据库存的图片路径是/img/xxx.jpg最后发现Spring Boot默认的静态资源映射里没有/img/**。解决办法是写一个配置类注册资源映射Configuration public class WebConfig implements WebMvcConfigurer { Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/img/**) .addResourceResolver(file:D:/upload/); } }这里还有个隐藏的坑如果D:/upload/路径最后没有斜杠映射也可能失败。另外Windows和Linux环境的路径写法不一样部署到Linux要改成file:/usr/local/upload/。6.2 问题二下单时库存变成负数现象是测试阶段用两个浏览器同时下单同一商品数据库库存变成负数但是订单还是生成成功了。排查过程从代码入手。原代码逻辑是Goods goods goodsMapper.selectById(goodsId); if (goods.getStock() 0) { goods.setStock(goods.getStock() - 1); goodsMapper.updateById(goods); // 创建订单 }这个写法的问题在于“先查再改”有两个时间窗口两个请求同时查到的库存都是1然后都能通过校验都执行减一库存变成0甚至-1。解决办法是换成原子更新UPDATE t_goods SET stock stock - 1 WHERE goods_id ? AND stock 0然后通过update方法的返回影响行数判断是否扣减成功如果返回0说明库存不足直接抛异常回滚事务。这个方案简单、有效、可解释在中小型项目里完全够用。6.3 问题三MyBatis映射文件找不到现象是项目启动时直接报错控制台一串Invalid bound statement (not found)每个Mapper方法都调不了。我当时的排查路径先确认接口和XML的命名空间匹配再确认Mapper接口的方法名和XML里的id一致最后发现问题在pom.xml或application.yml没配置resources路径。Maven默认只把src/main/resources下的文件打进去你把mapper目录放在了src/main/java下面运行时就找不到XML。解决办法有两种要么把XML放到resources下的同级目录要么在pom.xml里加resource配置把XML也打包进去。这个问题属于环境配置类问题碰到一次记住以后就能避免。7. 文档组织数据库脚本、设计说明和部署文档怎么写7.1 数据库脚本的整理标准项目交付时的数据库目录至少应该有init.sql和data.sql两个文件。init.sql包含建库建表的完整语句注意建表语句里每个字段都要有COMMENT备注。data.sql准备测试数据时密码不要是明文注册用户的数据要和代码加密逻辑匹配上管理员账号要单独插入。数据库文档部分建议写清楚三块内容ER图、数据字典、核心表关系说明。ER图用工具生成截图放进文档即可数据字典用表格列出每张表的字段、类型、是否为空、默认值、备注。这个数据字典不用手抄用工具从数据库里导出后整理工作量不大但文档完整度提升明显。7.2 设计说明文档的结构建议很多人的课程设计文档是“框架填充”老师的评审印象就是敷衍。我建议按这个顺序写项目背景与意义 → 需求分析功能需求用例图 → 系统设计架构图功能模块划分 → 数据库设计ER图数据字典 → 核心功能实现选2-3个业务逻辑详述比如下单的事务处理 → 系统测试测试环境测试用例测试结果 → 总结与展望。其中最容易拉开分数差距的是“核心功能实现”这一part。不要泛泛而谈“实现了购物车管理”而是画一个时序图再贴一段核心代码说明这段逻辑解决了什么问题。比如下单接口把事务回滚、库存校验、订单编号生成逻辑写清楚这就体现了“不是你只会CRUD而是你懂业务逻辑”。7.3 部署文档让别人按你的文档能跑起来部署文档的核心目标是一个完全不懂这个项目的人照着文档能把系统跑起来。所以至少包含开发环境要求JDK版本、Maven版本、MySQL版本、数据库初始化步骤执行哪个SQL脚本、配置文件修改项数据库账号密码、端口、启动步骤以及常见启动失败问题对照表。常见失败问题对照表这个设计很实用。比如“端口8080被占用怎么办”、“数据库连接报错怎么办”、“账号密码不对怎么办”把这些写进文档说明你不是只写了流程而是真的踩过坑。这在评审时是一个小小的加分项。8. 项目验收与演示从能跑到能过还差最后一步8.1 测试用例怎么设计不少同学在测试环节直接交差打开页面点了几下说“一切正常”。这显然不够。至少要设计一份功能测试用例表包含用例编号、测试项、操作步骤、预期结果、实际结果、是否通过。测试用例要覆盖正常流程注册→登录→浏览→加购→下单异常流程重复注册用户名、库存不足下单、未登录访问购物车边界测试商品名关键字搜索无结果、购物车数量改为0或负数。测试用例这张表既是文档材料也是你心中对系统功能结构的梳理。写一遍你会发现自己系统里哪些逻辑没有闭环提前把问题解决掉。8.2 演示的先后顺序把故事线讲完整答辩演示和自行测试不一样不是在界面上乱点而是按一条演示主线走从首页开始 → 展示商品分类和搜索 → 注册一个新账号 → 加入购物车 → 下单 → 模拟支付成功 → 切换管理员登录 → 后台处理订单发货 → 回前台确认订单状态变更。这条线走完整个系统的业务闭环就全了。演示中最容易翻车的环节是“在答辩现场临时操作引发了报错”。我的建议是演示环境不连打包时的数据库而是准备一套独立演示数据避免现场网络异常或数据库被同学改过。页面和数据库操作都预演至少三遍。我自己做这套系统时最大的体会是不要追求把项目做成“大而全”而要把每个环节做扎实。数据库设计、核心业务逻辑、文档一致性这三件事比多写两个页面重要得多。很多项目可以从仓库直接跑起来但如果你能把“为什么这样设计表结构”“为什么下单要用事务”“为什么扣库存要用原子更新”这三个问题回答利落这个项目的含金量就完全不一样了。最后分享一个小技巧全部完成后把整个项目按“报告→源码→数据库脚本→部署说明”四段重新归档一遍你就得到了一套完整规范的网上超市系统项目可以直接交作业也可以作为简历里的项目经验认真写上几笔。