ki-pi毕设辅导做多了之后有个很明显的体感：论题名单里“社区便利店购物”这类项目永远不缺，难的不是把商品列表和购物车写出来，而是你能不能把“下楼买东西”这件日常到不能再日常的事，完整地转译成一套前后端能协作、数据库能闭环、答辩能讲清楚的生产系统。最近我刚带完一个基于SpringBoot的社区便利店购物平台系统项目，小程序端叫“优购在线”，整体的设计、联调、文档到现在都保留在一套可交付的流程里。这篇就把背后考虑过的业务取舍、数据建模和踩坑过程整理出来，给正在做类似毕业设计或者自己想搭一个全栈练习项目的朋友一点参考。
这个系统面向的是典型社区便利店场景：店铺不大、人流量集中在饭点前后、顾客住得近、客单价不高、复购率却很稳定。比起大而全的电商平台，它更像一个“让附近几百米的人提前下单、到店自提或者叫店员送一下”的接单工具。所以在做方案阶段，我没有直接把传统商城项目照搬过来，而是围绕社区场景把范围收缩到了“选品—下单—支付—备货—签收”这一条主线，再把店主需要的商品、订单管理能力放进后端管理界面。技术栈上也尽量贴近毕设主流的SpringBoot加小程序组合，保证代码结构清晰、演示方便、文档也好展开。
1. 先想清楚：便利店小程序的“业务闭环”到底在哪
1.1 从收银台到后台，系统被“角色”切成了两半
社区便利店数字化以后，最重要的不是做一个看起来很唬人的商城首页，而是还原门店每天发生的“人货场”关系。顾客站在货架前，挑东西、问价、买单，这套动作被线上化以后，就变成了两个截然不同的角色入口。
第一个入口是顾客端的微信小程序“优购在线”。用户不需要下载App，微信里扫一下就能打开。他们在这个端上做的是：看店铺里实际有货的商品、按分类找东西、把酸奶和泡面丢进购物车、选择自提还是配送、下单以后查看订单走到哪一步。第二个入口是平台管理后台，主要给店主或者收银员用。店员在这个端上维护商品上下架、改价格、调整库存、处理顾客提交的新订单，并且把“已支付”的订单改成“备货中”“待自提”或“配送中”，直到顾客签收。
只从功能清单来看，这套东西确实不复杂，但它有个容易被忽略的关键点：订单状态。便利店最怕的就是顾客下单后发现缺货或者店员漏看，所以整个系统都在围绕“订单状态的每一次变更要有迹可循”来设计。顾客下完单看到的是“待支付”，支付成功变成“待接单”，店员点一下“接单”之后又进“备货中”，最后“待自提/配送中”再到“已签收”。这一个状态机的闭环，基本上就是整套业务运转的主干。
1.2 毕设里为什么要额外做“小程序端”这一半
不少学生会问，既然有SpringBoot后端，为什么还要再搭一个小程序前端？直接用管理后台下单不行吗？这里有个非常现实的理由——毕设评审老师的关注点不仅是功能做没做出来，还包括你站没站在真实应用场景里理解系统边界。
如果用纯Web管理端做顾客购物，整个项目会退化成普通的CRUD练习；而引入微信小程序，则额外覆盖了微信登录鉴权、小程序端音频限制规则、跳转配置、以及和第三方平台（微信）的双端联调。这些都是将来在企业里做全栈开发绕不开的内容，同时它也在文档和演示视频里变成容易表现增量功能的部分。用户在手机上打开微信、点进“优购在线”下单，这个过程比打开电脑浏览器访问一个后台系统更有说服力，也更好展示。
1.3 哪些功能被我有意“砍掉”了
这可能是很多同学做系统时最纠结的地方。便利店购物，听起来要不要做优惠券？要不要做会员等级？要不要接入物流查询？我当时的判断是：要克制。
社区便利店采购决策通常是几块钱到几十块钱，顾客看中的是“近”和“方便”，如果引入复杂的营销系统，购物车价值反而会淹没在无休止的规则判断里。毕设答辩时间有限，如果功能遍地开花但每块都浅尝辄止，老师几个追问就会露馅。所以这套系统里只保留了用户最刚需的部分：用户管理、分类浏览、关键字搜索、购物车、订单、地址管理、支付模拟、商品管理、库存管理、订单处理和基础统计。把一个高频链路做深做透，远比堆二十张表要更有价值。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 从微信登录到订单签收：主链路实现中的取舍与步骤
2.1 微信登录不是“输入用户名密码”，而是code换身份
做小程序端第一件事就是处理登录。和Web端不同，微信小程序里很少让用户去注册登录账号，常见的做法是用微信官方提供的 wx.login() 接口拿到一个临时code，再把code发到SpringBoot后端，由后端调用微信的 code2Session 接口换取 openid 和 session_key。openid 在小程序应用范围内是用户唯一标识，所以用它作为用户的业务主键再合适不过。
代码上大致是这样：
java复制@PostMapping("/wx/login")
public Result<String> wxLogin(@RequestBody WxLoginDTO dto) {
// dto.getCode() 来自小程序端 wx.login 的成功回调
String url = "https://api.weixin.qq.com/sns/jscode2session" +
"?appid=" + wechatProperties.getAppId() +
"&secret=" + wechatProperties.getAppSecret() +
"&js_code=" + dto.getCode() +
"&grant_type=authorization_code";
String response = restTemplate.getForObject(url, String.class);
JSONObject json = JSON.parseObject(response);
String openid = json.getString("openid");
// 根据 openid 查用户，不存在则自动注册
User user = userService.getOrCreateByOpenid(openid);
// 签发自定义登录态，后续请求头带上 token
String token = jwtUtil.generateToken(user.getId());
return Result.success(token);
}
前端小程序这边先调 wx.login 拿到code，然后向上面的登录接口发请求，后端把token带回以后存储在本地，之后的商品浏览、加购、下单请求都会在header里带 Authorization: token。这里有一个值得夸的设计点：我们并不需要在前台手工实现注册页面，用户第一次打开小程序授权登录后就自动建号。对业主来说是零学习成本，对毕设评分来说又多了一个前后端联合鉴权的知识点。
2.2 购物车状态放在后端数据库，还是放在小程序本地？
购物车是一个很容易被想简单的地方。很多教程图省事，会在小程序端用一个全局数组当购物车，关闭页面服务以后再次重新加载，购物车数据就全丢了；或者为了应付，把购物车塞进 wx.setStorageSync，这虽然能保存，但换一台手机登录，购物车就不一致。
我在这个项目里将购物车模型设计成后端数据库表来维护。前端每点击一次“加入购物车”，就向后端提交商品编号和数量，做增量的更新。查询购物车，也永远以后端计算出来的价格和商品信息为准。这么设计还有一个隐藏的好处：库存校验、促销逻辑能在同一事务里控制，将来切换App端或者做Web商城时，购物车服务可以直接复用，不依赖任何终端缓存。
购物车加购的表单以及后端处理：
java复制@PostMapping("/cart/add")
public Result<Void> addCart(@RequestBody CartAddDTO dto) {
// 校验商品是否存在、是否上架、数量是否大于0
Product product = productService.getById(dto.getProductId());
if (product == null || product.getStatus() != 1) {
throw new BizException("商品不存在或已下架");
}
// 后端购物车表中已存在则累加数量
boolean result = cartService.addOrUpdate(userContext.getUserId(), dto);
return result ? Result.success() : Result.fail("添加失败");
}
由于用户信息和商品信息都在后端，购物车可以在完全没有前端storage的情况下保持一致，配合项目文档也更容易解释清楚“表关系”这一章节。
2.3 下单接口里的“三件事”：扣库存、生成订单、锁定快照
到了提交订单这一步，我选择将整个流程做成一个事务。一次下单会做几件事：校验购物车非空，按商品维度把购买数量汇总；校验每个商品的状态和库存；锁定主订单需要的总金额；生成一个主订单，再细化订单明细项；最后一次性清理当前用户的购物车记录。
很多初学SpringBoot的同学在“下单”这个接口上只做了两步——插入订单表、插入订单明细表，但忘了对库存做校验和扣减，这就会在演示环境里出现“明明库存是3件却能下单10件”的刺头bug。事务注解 @Transactional 在这里是刚需，否则库存扣减一半时发生异常，会出现订单未生成、库存却少了的脏数据。
模拟的核心逻辑类似下面这样：
java复制@Transactional(rollbackFor = Exception.class)
public Long createOrder(Long userId, OrderCreateDTO dto) {
List<CartItem> selectedItems = cartService.listSelected(userId, dto.getCartItemIds());
if (selectedItems == null || selectedItems.isEmpty()) {
throw new BizException("没有可结算的商品");
}
// 组装订单主表
Order order = new Order();
order.setUserId(userId);
order.setTotalAmount(calculateTotal(selectedItems));
order.setStatus(OrderStatus.PENDING_PAYMENT.getCode());
order.setOrderNo(generateOrderNo());
orderService.save(order);
// 扣减库存 + 保存订单明细
for (CartItem item : selectedItems) {
boolean deducted = productStockService.deductStock(item.getProductId(), item.getQuantity());
if (!deducted) {
throw new BizException("库存不足: " + item.getProductName());
}
OrderItem orderItem = buildOrderItem(order.getId(), item);
orderItemService.save(orderItem);
}
// 清空购物车已结算数据
cartService.removeByItemIds(dto.getCartItemIds());
return order.getId();
}
2.4 支付模块和订单状态扭转的观察窗口
众所周知，普通的个人微信小程序没有真实开通微信支付的条件，所以毕业设计项目里常见做法是做一个“模拟收银台”：前端点击“去支付”，弹窗显示一笔待支付订单，点击确认后调用后端支付回调接口，直接把订单从“待支付”改为“待接单”。
这种设计是得体的，既绕开了无法申请商户号的现实，又不失对支付回调状态的模拟。我在后端留了 PaymentNotifyService 这样的独立接口，将来接真实支付时只需替换PayService实现，而订单状态机部分保持不变。订单管理的后台端可以看到商品、明细和实时状态。如果结合WebSocket给小程序的用户推送“你订单状态变化了”的消息，会更出彩；不过考虑到篇幅和稳定性，我在最小版本里用JS定时轮询也能让用户在订单页看到最新动态。
3. MySQL建模细节：如何用四张核心表撑起整个便利店闭环
3.1 数据表设计与命名的小心思
由于“order”是MySQL里比较特殊的保留字，我在表设计上采用了 t_ 前缀：t_user、t_product_category、t_product、t_cart_item、t_order、t_order_item。这样做能让字段语义更清晰，SQL里也不容易因为关键字冲突而报错。下面给出核心表的一段简化DDL，读者在搭建自己的项目时可以基于它扩展：
sql复制CREATE TABLE `t_product` (
`id` bigint(20) NOT NULL AUTO_INCREMENT,
`category_id` bigint(20) NOT NULL COMMENT '所属分类id',
`name` varchar(128) NOT NULL COMMENT '商品名称',
`sub_title` varchar(255) DEFAULT '' COMMENT '副标题',
`main_image` varchar(255) DEFAULT '' COMMENT '商品主图',
`detail` text COMMENT '商品详情',
`price` decimal(10,2) NOT NULL COMMENT '销售价',
`stock` int(11) NOT NULL DEFAULT '0' COMMENT '库存',
`status` tinyint(4) NOT NULL DEFAULT '1' COMMENT '1上架 0下架',
`create_time` datetime DEFAULT NULL,
`update_time` datetime DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `idx_category_id` (`category_id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4;
CREATE TABLE `t_order_item` (
`id` bigint(20) NOT NULL AUTO_INCREMENT,
`order_id` bigint(20) NOT NULL COMMENT '订单id',
`product_id` bigint(20) NOT NULL COMMENT '商品id',
`product_name` varchar(128) NOT NULL COMMENT '商品快照名称',
`product_image` varchar(255) DEFAULT '',
`product_price` decimal(10,2) NOT NULL COMMENT '成交快照价格',
`quantity` int(11) NOT NULL COMMENT '数量',
`total_price` decimal(10,2) NOT NULL COMMENT '小计',
PRIMARY KEY (`id`),
KEY `idx_order_id` (`order_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
3.2 为什么订单明细里要冗余一份“商品快照字段”
这一点在论文和答辩里非常加分，也希望每个做商城类系统的同学真的去领悟它。
假设你不冗余商品名称和价格，只存一个 product_id，表面上看第三范式做到位了，但后台上架人员一旦商品价格从3.5元改成4.5元，历史订单就会跟着“变价”，订单重新查询时“用户当时到底花了多少钱”就再也说不清了。更严重的是，如果商品被删除，外键会失效，订单明细变成一堆指向空数据的孤儿记录。
因此，t_order_item 的设计里，我把商品名称、图片、成交价格完整复制了一份。这些字段是下单那一刻的“事实记录”，之后商品库里怎么改都影响不到已成交订单。实际在便利店场景里这非常常见：牛奶昨天搞活动卖2.8元，今天恢复原价3.5元，昨天的订单仍旧按2.8元对账。
3.3 库存扣减与并发抢购的现实拷问
便利店系统虽然不会面临大促级别的瞬时流量，但依然可能出现两个人同时买最后一瓶汽水的并发情况。为了稳妥可靠，我在商品表里没有只用一个stock字段，同时还引入了乐观锁版本号。
实现上，每次扣减库存时使用类似下面的SQL：
sql复制UPDATE t_product
SET stock = stock - #{quantity},
version = version + 1
WHERE id = #{productId}
AND stock >= #{quantity}
AND version = #{version};
如果更新影响行数为0，就说明库存不足或者版本已经被其他人改过了，此时终止下单并抛出友好提示，而不是让两个订单都对最后一个库存做扣减。这种做法在毕业设计里说出来，会明显高于“直接 update stock = stock - ?”的普通写法，也让数据库设计更有纵深可言。
4. SpringBoot后端工程结构：如何让代码不像“课程作业”
4.1 分层结构与包命名的标准套路
代码结构很大程度上决定了答辩老师对项目的第一印象。如果全部业务逻辑都堆在Controller里，Service层形同虚设，项目跑起来没问题但很难看。我沿用的是常见且清晰的分层：
code复制com.ugou.platform
├── common
│ ├── result/Result.java
│ └── exception/BizException.java
├── config
│ ├── WebMvcConfig.java
│ └── JwtInterceptor.java
├── controller
│ ├── admin/xxxController.java // 后台管理端接口
│ └── wx/xxxController.java // 小程序端接口
├── service + service.impl
├── mapper
├── entity
└── dto / vo
这样的结构有一个我很看重的优点：小程序端和管理后台虽然是两套用户界面，但都在同一个SpringBoot服务里对接，API路径通过 /api/wx/** 和 /api/admin/** 分开。写拦截器时，只需要拦截需要鉴权的路径，放行登录和商品浏览等公开接口。
4.2 统一响应对象与全局异常处理
为了让微信小程序端能像解析“同一套格式”一样处理所有请求结果，我定义了一个通用泛型返回体 Result<T>，规范是：code为200表示成功，错误码则对应业务异常、参数校验异常或未登录异常。
java复制@Data
public class Result<T> implements Serializable {
private Integer code;
private String message;
private T data;
public static <T> Result<T> success(T data) { ... }
public static <T> Result<T> fail(String message) { ... }
}
同时在全局建议加一个 @RestControllerAdvice，统一捕获异常，避免SpringBoot默认抛出一大串堆栈给前端。前端拿到 { code: 401, message: "未登录" } 以后会统一跳转登录页。对便利店小程序这种轻客户端来说，统一封装的意义不是花架子，而是真正把大量错误处理收敛到一个地方，代码写起来也更有工程感。
4.3 配置文件与环境切换：别把密码写死在代码里
很多毕设里的报错都是“我本机跑得好好的，拍照的时候怎么就连不上数据库了”。究其原因，数据库连接信息、微信小程序密钥、上传目录这些配置被写死在Java类里，换一台演示机器就必须要重新编译。
SpringBoot的天然优势就是多环境配置，我会在项目里拆出 application-dev.yml、application-prod.yml，将数据库地址、Redis地址、文件上传路径、微信密钥等全部放到配置文件中，运行环境的切换只需要在启动参数里指定 --spring.profiles.active=prod。这样一个项目既能在开发机快速调试，也能打成一个生产jar包部署到云服务器上演示。
5. 小程序端的耗时细节：图片上传、域名校验、动态更新
5.1 微信开发者工具里的“合法域名”卡住一大批人
在微信小程序里发起 wx.request 到SpringBoot后端，目标服务器域名必须在小程序管理后台配置为“request合法域名”，否则只能勾选开发者工具里“不校验合法域名”的临时选项来调试。
不少同学在本地用127.0.0.1或localhost启动SpringBoot，手机扫码预览时怎么都不出数据，就是因为开发者工具的地址是电脑本机，而手机访问不到。如果要用真机预览，最直接的办法是后端跑在云服务器上，后端地址替换成服务器公网IP或已完成备案的域名。这一点放在“使用说明”和“部署文档”里也值得特意标注，能帮后续使用者少掉很多坑。
5.2 uploadFile和静态图片资源映射的“成长烦恼”
商品图片往往不像学生初期设想的那样硬编码一个链接，需要由管理员在后台选择本地图片上传。后台把图片文件传到服务器的某个目录，例如 /home/ubuntu/shop-images/，然后SpringBoot提供 /images/** 映射到这个外部目录：
java复制@Override
public void addResourceHandlers(ResourceHandlerRegistry registry) {
String uploadPath = fileProperties.getImagePath();
registry.addResourceHandler("/images/**")
.addResourceLocations("file:" + uploadPath);
}
但如果你把文件直接写到项目“运行目录”里，下次重新打包部署就会被覆盖清空，所以务必在配置文件中把上传路径独立出来。配合一个独立的数据库字段存储图片相对路径 /images/goods/xxx.jpg，小程序端就能通过 https://你的域名/images/goods/xxx.jpg 访问到。
5.3 小程序页面生命周期与“购物车角标”刷新策略
小程序前端另一个容易出细节问题的地方是页面切换时的数据刷新。便利店顾客通常一边挑着商品，一边切到不同分类看价格，再把商品一瓶一瓶地加进购物车。如果购物车角标不同步，顾客很可能以为没加成功而重复提交。
解决思路也很朴素。购物车相关页面要在 onShow 生命周期里重新拉取后端购物车数量，而不是在 onLoad 里只初始化一次。这样从详情页切开回列表页、又从分类页切回购物车tab时，数值始终对齐服务端，不会出现“页面还停在旧数据上”的错觉。
这里给出小程序端一个请求封装的小思路：
js复制function request(path, method = 'GET', data = {}) {
return new Promise((resolve, reject) => {
wx.request({
url: getApp().globalData.baseUrl + path,
method,
data,
header: {
'Content-Type': 'application/json',
'Authorization': wx.getStorageSync('token') || ''
},
success: (res) => {
if (res.data.code === 200) {
resolve(res.data.data);
} else {
wx.showToast({ title: res.data.message, icon: 'none' });
reject(res.data);
}
},
fail: reject
});
});
}
6. 从“可运行”到“能过答辩、能交付”的最后一公里
6.1 整理演示流程：三分半钟讲完一套业务闭环
系统做出来到答辩之间，只差一套清晰完整的演示脚本。很多同学会在答辩现场临时从首页开始一路点点点，结果讲了五分钟还在录入商品，老师根本没看到下单页面。合理的方式是提前按“角色+流程”来安排：先用管理员账号登录后台，介绍商品分类和上架功能；切到小程序用户端，演示微信登录、浏览商品、搜索、加购、下单、模拟支付；再切回后台，看到订单进来，把订单状态改成“备货中”；最后再回到小程序展示订单状态的更新。
这条演示路径只需要按顺序操作一遍，业务闭环就清楚跳出来了。配套的“项目截图”也可以用这个顺序去截图存档，之后写文档和做PPT时直接取用。
6.2 配套文档里最容易被忽略但老师大概率会翻的几页
毕业设计文档一般包含开题、需求分析、数据库设计、系统设计、测试和总结。很多同学只关心怎么写程序，结果交文档时才发现数据库设计章节连每张表的字段注释都没有。
做这套系统时，我建议把所有SQL导出带注释版本，尤其是 t_order_item 的快照字段。需求分析里可以把“订单状态流转图”讲清楚。测试部分则不用写花哨的自动化测试，但至少要有“功能测试用例表”，比如：正常下单的流程、库存不足时的返回提示、未登录时访问个人订单返回401、商品下架后不能加购。这些用例表格能直观证明系统测试做得完整，答辩时十分讨喜。
6.3 常见追问与应对思路
答辩时老师基本会围绕几个高频问题展开。比如“购物车为什么要存数据库而不放本地？”这时可以回答：为了跨终端一致，也为了在后端统一做库存校验和价格计算。再比如“库存扣减时并发怎么办？”可以讲到乐观锁版本号方案。还有“如果微信支付真实接入，要改哪些地方？”则可以说明支付回调接口和支付服务接口已经做了隔离，替换实现即可。
这几个问题我在上文的方案里其实都已经铺垫过。答辩问答场面无非是“用过的思路能不能被自己再讲一遍”的测试，考前花一个晚上把技术选择和备选方案统一顺一遍，心里会踏实很多。
6.4 关于“定制”与二次开发的实际提示
最后说一句掏心窝的话。大部分定制化需求不是要从零写一套新系统，而是要在“不同业态”之间做配置适配。比如有的社区店需要“按件卖”，有的需要“按斤称重”；有的店要允许“到店自提”，有的更依赖“骑手快送”。如果初始代码里把每个业务判断都写在Controller里，后续改一种规则就得牵连一整片。所以尽量把订单金额计算、配送方式校验、库存扣减这些操作全部下沉到Service层，并保留扩展接口。这不仅是毕设评优的亮点，也是项目以后真正落到实际门店时最省力的地基。