董云舟做小程序商城这个方向，我见过太多“买椟还珠”的项目。不少同学拿到一套源码，跑起来能看首页、能加购物车，就觉得完事了，结果答辩时被问一句“订单状态是怎么流转的”就卡壳。我整理的这套在线购物系统，更想强调的不只是“能跑”，而是整套项目如何从需求、表设计、接口、前后端联调一路走到最终交付。这篇文章我就把这个项目里真正有价值的零件拆开，讲清楚技术选型怎么定、核心模块怎么实现、文档怎么组织、调试时哪些坑最常见，给正在做课程设计、毕业设计或者打算接私活做小程序的你一份可以直接照抄的作业。
1. 项目全貌：这套商城系统的定位与技术选型
1.1 为什么选“原生微信小程序 + Spring Boot + MySQL”这套组合
技术选型这事儿，最忌讳跟风。我当时定方案之前，也纠结过要不要用 uni-app 一把梭，毕竟 HBuilderX 发行微信小程序的流程确实方便，一套代码还能再生出 App 端。但最终还是选了原生小程序加重构后端，原因很简单：这套系统的定位是教学演示和交付级 Demo，要的是“逻辑透明、文档齐全、调试容易”。
原生微信小程序的好处在于，整个生命周期、API 调用、组件层级都是微信官方的一套。出了问题去搜解决方案，资料最多、回复最快。比如“微信小程序顶部导航栏高度”这个问题，原生里用 wx.getMenuButtonBoundingClientRect() 拿胶囊位置，再结合系统状态栏高度就能精确算出导航栏真实高度，这些代码在原生环境里是稳定可复现的。换成 uni-app 虽然也能做，但中间多了一层框架的兼容和转换，对于新手来说，排查问题时就多了一道干扰。后端选 Spring Boot 则是因为它生态成熟，Idea 里启动、断点、热部署都很顺手，而且 Java 技术栈在大多数学校的课程设计、毕业设计里是“安全牌”，答辩时老师认可度高。MyBatis-Plus 负责减少重复的 CRUD 代码，Redis 做缓存和 token 存储，这套组合在中小型项目中已经被验证过无数次，属于典型的“稳妥方案”。
1.2 项目目录结构与工程组织方式
拿到这套系统源码，先别急着按启动按钮，建议先把目录结构过一遍。好的工程组织能帮你节省大量后期维护时间，这套项目的目录设计如下：
text复制shopping-mall-frontend/ # 微信小程序前端
pages/
index/ # 首页：商品列表、轮播图
category/ # 分类页：左侧分类、右侧商品
goods/ # 商品详情：SKU选择、加入购物车
cart/ # 购物车：增删改、结算入口
order/ # 订单：确认订单、订单列表、订单详情
user/ # 个人中心：登录、地址管理、我的订单
shopping-mall-backend/ # Spring Boot 后端
src/main/java/
controller/ # 接口层：接收参数、返回结果
service/ # 业务层：核心逻辑处理
mapper/ # 数据访问层：MyBatis-Plus
entity/ # 实体类
config/ # 全局配置：拦截器、跨域、swagger
src/main/resources/
application.yml # 数据库、Redis、端口配置
docs/ # 项目文档：需求、设计、接口、部署
前端每个页面文件夹里放 .wxml、.wxss、.js、.json 四个文件，这是小程序的标准结构。后端按经典的四层结构分包，清楚明了。docs 目录我习惯专门放需求文档、数据库设计文档、接口文档、部署文档，这些文档后面单独讲。这种组织方式最大的好处是，前后端完全分离，前端调试时只需要关注接口返回值，后端调试时只需要关注逻辑正确性，不会互相干扰。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 核心业务模块的设计与实现要点
2.1 登录鉴权这块，最容易被“跳过”的环节
很多同学做小程序商城，第一件事就是写商品列表接口，登录往后放。我的建议恰恰相反，先把登录打通，因为后续所有接口都依赖用户身份。小程序的登录流程和传统网页登录不太一样，它的核心是 wx.login() 拿到临时 code，然后后端用 code 去微信的 code2Session 接口换 openid 和 session_key。代码如下：
java复制// 小