简介这是一套基于SpringBootVue2微信小程序架构的胖东来生鲜超市微信小程序设计源码面向需要实现生鲜电商小程序的前后端开发者、毕业设计学生及微信小程序学习者。压缩包共349个文件包体约5.45MB涵盖71个JavaScript交互逻辑、64个JSON配置、57个WXML页面模板与51个WXSS样式、46个Java后端业务处理、14个Vue组件、21个PNG图片资源等文件类型覆盖小程序前端、管理后台与后端接口等多个层面目录结构便于按需检索。目前已有633人学习下载。整套代码可帮助读者理解微信小程序与SpringBoot的接口对接方式、Vue组件化复用方法、后端业务分层及权限控制等关键点同时readme.txt中也提供了项目说明方便快速启动和二次开发适合作为课程设计、毕业课题或实战练手参考。1. 从345个文件反推生鲜电商全栈结构拿到这份源码包第一件事先别双击 index.html会扑空。345 个文件里同时躺着 46 个 Java 和 71 个 JavaScript说明它不是一个静态网页而是一套横跨微信小程序、Vue2 管理后台、SpringBoot 接口服务的完整链路。顶层文件很能说明问题trade.iml 提示工程可以被 IDEA 以 Maven 模块方式直接导入index.html、favicon.ico 加上那个拼写不太严谨的 gloable.css应为 global.css说明后台前端是标准 SPA 结构。真正有价值的信息不在页面效果而在文件之间的边界感UserController 和 UsersController 同时出现意味着用户端和管理端在接口层就已经分开设计。想一次搞懂三端如何联调的新手或者打算拿现成商城做二次改造、先评估工程质量的开发者都值得把这套目录翻一遍。2. SpringBoot 后端46 个 Java 文件如何支撑订单与用户体系2.1 trade.iml 与目录分层Maven 模块的文件组织方式trade.iml 是 IntelliJ IDEA 的模块描述文件记录模块名、JDK 级别、源码目录和依赖关系。根目录里出现它意味着这套代码不需要手动配 Tomcat直接以 Maven 方式导入 IDEA 就能识别出 SpringBoot 启动类。对一份来路不明的源码我会先看有没有 .gitignore没有的话很可能只是文件快照丢了版本历史这里出现了 3 个 .gitignore说明项目确实进过 Git不是随手打包的结果。46 个 Java 文件属于典型的中型单体工程按 SpringBoot 约定通常会切成 controller、service、mapper、pojo、config、common 几层。下面是这套结构最常见的切片方式也是评估项目时最优先看的目录形态trade ├── pom.xml ├── src/main/java/com/trade │ ├── controller │ │ ├── UserController.java │ │ └── UsersController.java │ ├── service │ ├── mapper │ ├── pojo │ ├── config │ └── common ├── src/main/resources │ ├── application.yml │ └── mapper └── target逻辑说明pom.xml 决定 SpringBoot 版本和第三方依赖application.yml 决定启动端口、数据库连接和微信相关配置resources/mapper 目录放 MyBatis 的 XML 映射文件。参数说明controller 只做请求分发service 写业务编排mapper 负责 SQLpojo 放实体common 里放统一响应、异常和工具类。config 里常见的是 WebMvcConfig拦截器、CORS和 MyBatis 配置。这种分层最大的收益是后续接 Redis 缓存或者把订单模块拆成独立服务时controller 和 service 不用重写。分包预期文件职责controllerUserController.java小程序端登录、下单等接口入口serviceOrderService.java订单与库存的核心业务编排mapperUserMapper.javaSQL 与数据访问pojoUserInfo.java数据库表对应的实体configWebMvcConfig.java拦截器、跨域、静态资源映射commonResult.java统一响应包装这是按行业惯例做的预期不是从源码里逐字读出的类名。看项目的顺序应该是先看 controller 里是不是直接写了 SQL 和 if/else如果 controller 只是收参数和返回结果说明分层意识合格如果满屏业务逻辑基本可以判断这是赶工期堆出来的代码。2.2 Controller 层边界UserController 与 UsersController 的分工同时出现 UserController 和 UsersController不是命名重复。前者管小程序 C 端用户后者管后台管理端的用户列表、禁用、搜索。按「数据表」设计只会写一个 UserController按「使用者视角」设计才会拆成两个。C 端的登录、收货地址、订单列表与 B 端的用户分页、状态变更、导出本质上是两套接口放在一起会让权限控制和参数校验变得混乱。/** * 小程序 C 端用户接口 */ RestController RequestMapping(/api/user) public class UserController { Resource private UserService userService; PostMapping(/login) public ResultString login(RequestBody LoginRequest request) { // 用 wx.login 返回的 code 换取 openid再生成自定义 token return Result.ok(userService.login(request.getCode())); } GetMapping(/info) public ResultUserInfo info(RequestHeader(Authorization) String token) { return Result.ok(userService.getUserInfo(token)); } }逻辑说明RestController 会把返回值序列化成 JSONResult.ok 是统一响应包装前端拿到后先判断业务 code 再取 datatoken 放在 Authorization 请求头里由后端拦截器统一校验业务方法里不再重复解析。参数说明RequestBody 接收小程序 POST 过来的 JSON 对象LoginRequest 里只有 code 字段RequestHeader 从请求头取 token取不到或者过期时应该返回 401而不是抛出业务异常。这里有一个常见误用把 token 校验写进每个 controller 方法导致同一段鉴权逻辑散落十几个文件后续从 UUID token 换成 JWT 要改一大圈。正确做法是写一个 HandlerInterceptor在 preHandle 里统一处理只放行登录接口和白名单路径。UsersController 那边的分页接口预期是 GET /api/users/page?pageNum1pageSize10pageSize 要用校验注解限制上限防止一次把整张用户表拉进内存。2.3 Service 事务与库存扣减生鲜订单的常见方案生鲜订单比普通商品多两个特殊性一是按份和按斤计量二是库存实时性要求高超卖直接影响配送履约。做单体项目时我一般会把下单和扣库存放进同一个事务用乐观锁风格的 UPDATE 防止并发穿透。Service public class OrderService { Resource private OrderMapper orderMapper; Resource private InventoryMapper inventoryMapper; Transactional(rollbackFor Exception.class) public Long createOrder(OrderCreateDTO dto) { // 扣库存时加上 stock quantity 条件影响行数为 0 说明超卖 int updated inventoryMapper.deductStock(dto.getSkuId(), dto.getQuantity()); if (updated 0) { throw new BizException(库存不足或商品已下架); } orderMapper.insert(dto.toOrder()); return dto.getOrderId(); } }对应的 Mapper SQL 是这样写的UPDATE inventory SET stock stock - #{quantity} WHERE sku_id #{skuId} AND stock #{quantity}逻辑说明UPDATE 影响行数为 0要么是 skuId 不存在要么是 stock 不满足条件这时直接抛异常回滚比先查库存再 UPDATE 更安全。参数说明rollbackFor Exception.class 表示遇到任何异常都回滚确保不会出现「库存扣了、订单没建」的脏数据deductStock 返回 int 类型MyBatis 会自动把受影响行数映射出来。这个方案在低并发单体场景完全够用等出现秒杀和抢购时才需要把库存预热到 Redis、用 Lua 脚本保证原子性。2.4 配置与数据访问64 个 JSON 和 9 个 XML 的用途46 个 Java 之外还有 64 个 JSON 和 9 个 XML很容易被当成配置文件打包进来的噪音。其实这里有两类关键内容pom.xml 这类构建文件以及 MyBatis 的 Mapper XML。配置中心的 application.yml 负责把数据库和微信参数统一收口server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/trade_mall username: root password: 123456 servlet: multipart: max-file-size: 10MB wx: appid: wx1234567890abcdef secret: 一串密钥逻辑说明spring.datasource 管理数据库连接max-file-size 控制上传图片大小wx.appid 和 wx.secret 是后端调微信 code2Session 接口时使用的。参数说明appid 可以出现在小程序代码里secret 必须只存在服务端一旦泄漏别人就能拿它伪造登录。生产环境部署时不要直接改这个文件而是用 application-prod.yml 加 spring.profiles.activeprod 切换避免本地配置把线上数据库覆盖掉。3. 小程序端WXML、WXSS、JS、JSON 四件套的协作方式3.1 页面结构、样式与导航栏配置小程序端 57 个 WXML、51 个 WXSS、64 个 JSON、71 个 JS基本对应「每个页面四件套 公共组件」的组织方式。WXML 负责页面结构WXSS 负责样式JS 控制交互和数据请求JSON 管理页面配置。四件套的分工可以这样理解文件类型作用对应 Web 技术WXML页面结构HTMLWXSS页面样式CSSJS数据、事件、请求JavaScriptJSON页面导航、组件注册配置文件我改页面时习惯先动 JSON因为导航栏标题、下拉刷新、组件注册这些能力都在这一个文件里决定。默认导航栏的高度由微信客户端和机型决定不需要手动计算只有做自定义导航时才需要调用 wx.getMenuButtonBoundingClientRect 拿胶囊按钮的位置再反过来推算顶部高度。{ navigationBarTitleText: 生鲜自提, enablePullDownRefresh: true, usingComponents: { product-card: /components/product-card/index } }逻辑说明navigationBarTitleText 接收字符串决定顶部导航栏文字enablePullDownRefresh 开启下拉刷新后需要在同页面的 JS 里实现 onPullDownRefresh 方法否则只会看到转圈没有动作。参数说明usingComponents 里的 key 是页面内使用的标签名value 是组件路径路径相对整个小程序根目录来写。组件化做得好不好直接看这里的注册数量公共组件抽得越多页面代码越短。3.2 商品列表与 wx.request 请求商品列表页是生鲜商城的主入口。小程序端请求后端接口只能用 wx.request它不像浏览器那样自动带 Cookie所以每次请求都要手动附加身份信息。开发阶段最容易踩的坑是域名白名单微信开发者工具里需要勾选「不校验合法域名」否则请求直接报错。view classgoods-wrap block wx:for{{goodsList}} wx:keygoodsId product-card >Page({ data: { goodsList: [] }, onLoad() { wx.request({ url: https://api.trade-mall.com/api/goods/list, method: GET, header: { Authorization: wx.getStorageSync(token) }, success: (res) { this.setData({ goodsList: res.data.data }); } }); } });逻辑说明wx:for 循环渲染商品列表wx:key 绑定 goodsId 作为唯一标识避免数据更新时整个列表重建setData 是触发视图更新的唯一入口不要在 success 里直接修改 this.data。参数说明url 是后端接口地本文还有配套的精品资源点击获取
