基于微信小程序与SSM的高校食堂订餐系统开发解析

我本来没有认真想过给高校食堂做订餐系统，直到有次在学校食堂排队等了近四十分钟，眼看着窗口前那些端着餐盘挤来挤去的同学，才明白一个道理：食堂真正的痛点不是饭菜好不好吃，而是高峰期的点餐效率实在太低。后来结合平时接过的SSM项目，我决定做一套基于微信小程序的高校订餐系统——用户拿着手机就能浏览食堂菜品、加入购物车、下单支付，商家端在后台处理接单出餐，管理员负责审核菜品和统计营收。技术侧选了三个非常成熟的组合：前端微信小程序原生开发，后端由 Spring、SpringMVC、MyBatis 组成的 SSM 框架来承载，数据存储交给 MySQL。这套系统如果做成毕业设计或者课程项目，工作量可控，功能也能覆盖完整的业务闭环，对想摸清前后端联调流程的同学来说非常友好。

整套微信小程序订餐系统说到底就是一个移动端“食堂淘宝”：用户端是学生，商家端是食堂里各窗口，管理端是维护系统运营的后台人员。我希望通过这篇笔记把从需求分析、技术选型、数据库设计，到小程序核心功能实现、后台订单流转、部署上线踩坑的完整链路都梳理出来，尤其会多说一些在真实开发中容易忽略、常规文档又不太会写的东西。如果你正准备做类似的 SSM + 微信小程序全栈项目，可以直接参考这套拆解思路。

1. 为什么高校食堂需要一个专属订餐小程序：需求与痛点拆解

做项目最忌讳一上来就写代码，哪怕是一个校内的课程设计，需求梳理不清楚，后面写多少代码都是白费。这套订餐系统要解决的场景非常明确：高校食堂的就餐人数集中、高峰时段固定、窗口压力大，而学生希望在到达食堂前就能完成点餐和支付。市面上外卖平台只覆盖周边商家，很难专门处理食堂窗口这种内部供给关系，因此需要一个面向校园场景、轻量级的订餐工具。

1.1 堂食场景中的核心矛盾

如果认真观察过食堂的运营流程，你会发现高峰期的问题来自几个方面：学生需要先慢慢挪到各个窗口看有哪些菜，再排队等着打饭，然后掏出手机扫码支付，最后端着餐盘找座位。这一整条链路里，真正被大量消耗的时间其实不是做饭，而是“选餐”和“排队支付”。比如中午下课时间，一个普通窗口可能会同时涌进二三十个人，前面的同学犹豫几秒钟，后面的队伍就要多等几分钟。

从食堂档口经营者的角度看，还有个更棘手的问题：饭菜是按经验预估做的，做多做少都会造成浪费。如果学生能在课前通过小程序提前下单，商家提前统计出大致的菜品需求量，就可以更准确地控制备餐分量。这种需求是典型的“预约式消费”，外卖平台做不了，普通点餐网站又没有校园场景的便利性，所以系统就需要落到微信小程序上，毕竟学生打开手机就能用，不用额外下载 App。

1.2 三类角色的功能期望拆解

我把用户角色拆成三类，每一类都罗列出明确的功能期望，后边写代码和建表时全靠这张表来指导。

由于是高校项目，很多人会把学生和管理员做成一个后台，然后把商家也塞进去，这种做法在演示时看着省事，但到实际答辩或者需求扩展时容易暴露问题。最好是把小程序端留给学生用户，Web 后台同时支持商家和管理员两种登录入口，用权限字段区分，这样逻辑更清晰，也更能体现出“系统设计”的完整性。

1.3 系统的非功能性需求不能漏

很多同学做这种项目只盯着“能下单、能出列表”这些功能，却忽略非功能性需求。订餐系统用得最多的时间点恰好在中午和傍晚，高并发访问是一个躲不开的实际情况。虽然毕设项目的并发量并不大，但代码里必须有应对思路，比如购物车数据不要频繁请求后端、商家端订单列表要支持状态筛选、菜品库存和订单状态要保证一致性，不能让用户下单成功后商家却看到一份错误的订单。这些内容在后端的接口设计里都会体现。

另外一个很容易被忽略的点是异常兜底。微信小程序会时不时出现网络异常或者用户操作中断的情况，订单状态必须有一整套状态机设计，保证无论用户是支付完成后立即退出，还是商家处理订单过程中刷新页面，数据最终都处于可追踪的状态。最好给每个订单设置创建时间和状态更新时间，方便在用户“我的订单”页面展示进度。

2. 技术选型与总体设计：SSM、微信小程序与MySQL的组合逻辑

很多人在课程设计选型时会纠结：既然 Spring Boot 已经这么流行，为什么还要用 SSM？真实原因是不少高校的教学大纲和毕设要求里仍然把 SSM 当作考核重点，而且 SSM 结构足够清晰——Spring 管对象和事务、SpringMVC 管路由分发、MyBatis 管数据库操作，每一层拆得非常明白，适合用来理解 Java Web 后端的基本骨架。如果你已经有 Spring Boot 基础，反过来用 SSM 也几乎没有什么学习成本，无非是少了很多自动化配置，需要手动写 XML 而已。

2.1 “明明 Spring Boot 更方便”这个问题怎么答

在项目答辩时大概率会碰到老师问，为什么选用 SSM 而不是 Spring Boot，这个问题建议提前想清楚。我的答案一般从三个角度来组织：第一，SSM 是 Spring 生态里最经典的分层实践，SpringMVC 的 DispatcherServlet 机制能够把请求处理流程展示得非常直观，用 XML 配置数据源、事务、拦截器时，每个细节都明确可见，刚好适合演示和学习；第二，很多学校在课程安排中还没有完全切换成 Spring Boot，为了和前置课程保持一致，选 SSM 更容易拿到相关的指导资料；第三，SSM 项目可以很方便地部署在传统 Tomcat 容器中，有利于配合老版本服务器做生产部署演示。

如果团队里有人熟悉 Spring Boot，也完全可以把项目按 SSM 的分层思想改造成 Spring Boot 版本，业务代码基本都是通用的。实际上，我的这套项目在最终部署时，参考过其他团队的优化方式，也有人用 JPA 替换 MyBatis，但最终整个系统的核心逻辑保持不变。你完全可以根据自己熟悉的技术栈灵活调整。

2.2 微信小程序端为什么不用 uni-app

前端部分选原生微信小程序开发，而不是 uni-app 或 Taro，理由也很实际：这套系统只需要跑在微信生态里，没有必要为多端打包额外引入框架层。原生小程序框架包含 WXML、WXSS 和 JS，体积小、生命周期清楚，调用微信的 wx.login、wx.request、wx.navigateTo 等 API 时最为直接。不过需要注意，原生小程序也意味着你只能依赖微信开发者工具做调试，出错时堆栈信息相对简单，需要自己写一些日志辅助排查。

页面设计上，通常拆成首页、分类点餐页、购物车页、订单列表页、我的主页五个 Tab，再嵌套菜品详情页、下单确认页和订单详情页。这些页面之间的路由状态需要仔细处理——比如购物车页面如果是从菜品详情页跳进去的，用户点返回时应该能回到刚才的浏览位置，而不是被重置到首页。

2.3 前后端交互时的接口规范

接口设计如果能保持单一职责，后续联调会舒服很多。我习惯把所有后端返回数据包装成统一的 Result 对象，包含 code、message、data 三个字段。前端每次拿到响应后先判断 code 是否等于 200，再进行接下来的业务处理。为了防止出现“接口自己调通但小程序端一直报错”的问题，务必在微信开发者工具的本地设置里勾选“不校验合法域名”，同时在后端配置好 CORS 跨域过滤，否则浏览器能访问、小程序却会拦截掉请求。

举一个小例子，菜品浏览接口设计如下：

java复制// 请求：GET /api/dish/list?categoryId=1&page=1&pageSize=10
// 响应：
{
  "code": 200,
  "message": "success",
  "data": {
    "list": [
      {
        "id": 12,
        "dishName": "红烧肉套餐",
        "price": 15.5,
        "imageUrl": "https://your-domain.com/upload/dish/12.jpg",
        "sold": 56,
        "stock": 100
      }
    ],
    "total": 30
  }
}

前端页面需要在 onLoad 生命周期接收路径参数，然后请求列表接口，将数据渲染到 WXML；为了保证页面滚动浏览顺畅，最好加上触底分页加载。这个列表渲染逻辑是整套小程序的基础，把这一块写顺手了，后续订单列表、评论列表基本就是照葫芦画瓢。

3. 数据库设计是这类系统的头号工程：核心表的构成与字段选择

凡是做管理系统，数据库设计都值得多花时间，因为后端 Controller 和 Service 写得再好，表结构不合理也是白搭。这套订餐系统的核心实体有用户、商家、菜品、购物车、订单、订单明细、评论，另外还要有管理员和管理端操作日志。表关系比较简单，基本是一对多为主，多对多通过中间表实现。这里给出一个相对成熟、可直接复制到 MySQL 的设计方案。

3.1 用户与商家的用户体系设计

用户表 user 我通常是这么设计的：包含自增 id、微信小程序登录后拿到的 openid（唯一索引）、昵称、头像、手机号、学号、性别、注册时间、最近登录时间。这里其实不太建议直接拿微信 openid 做主键，因为它在展示或外键关联时太长了，而且可能涉及时不时更新微信用户信息的情况，使用自增 id 更稳定。

商家表 merchant 也类似，包含商家登录账号、密码（MD5 加盐或 BCrypt 加密）、所属食堂名称、窗口编号、联系电话、营业状态、评分、创建时间和结算账户等字段。很多同学会把商家的登录信息和用户的 openid 混在一张表里，这个设计在答辩时容易被老师质疑角色边界，最好是拆开，后台管理登录走独立的管理员/商家账号体系，小程序的普通用户走 openid 记录。

在实现上，普通用户和商家的唯一交集就是订单，因此不需要把两张表做成继承式结构，只需要维护好 order 表中的用户外键和商家外键即可。

3.2 菜品、分类与购物车表设计

菜品表 dish 是窗口展示的核心，字段通常有菜品名、菜品描述、价格、原价、图片路径、所属商家、所属分类、月销量、库存、状态（上架/下架）、创建时间和更新时间。这里比较关键的一点是价格精度必须使用 DECIMAL(10, 2)，避免浮点数计算误差。如果你希望在首页做关键词搜索，还可以给 dish_name 加普通索引。

菜品分类可以有两种做法：一种是全局分类，比如“川菜”“鲁菜”“快餐”“饮品”，另一种是每个食堂独立分类。我的思路是设置 category 表，让分类归属到具体商家，这样每个食堂窗口可以维护自己的一套菜单结构。该表字段包括分类名、所属商家、排序号、创建时间，并预留一个是否启用的状态字段。

购物车在数据库表层面其实有很多设计选择。我建议在服务端不建立持久化购物车表，而是把购物车数据直接存在微信小程序的缓存里，用户每次加入菜品后调用后端接口重新计算总价并校验菜品状态。只有当用户进入下单流程时，前端把购物车里的数据组装成订单参数发送给后端。这样做的好处是减少无意义的数据库读写，也避免用户只是在加餐阶段到处乱选菜时产生大量脏数据。

但你要是有足够的精力，做一个 cart 表也完全可以。字段包含用户 ID、菜品 ID、数量、加入时间、勾选状态，然后提供增删改查接口。我的个人建议是课程设计里优先做前端缓存方案，代码简单且不容易出错。

3.3 订单与订单明细表：状态机设计的基础

订单表承担的信息非常多，也是整套系统的核心。有一个很好的习惯，建议你把“订单状态”集中在 status 字段中，用数字表示而不是存字符串，然后在前端通过字典映射显示对应文字。我这里定义这样一套状态值：0 表示待支付，1 表示待接单，2 表示制作中，3 表示待取餐，4 表示已完成，5 表示已取消，6 表示退款中。这种设计让代码在做状态流转判断时非常舒服。

订单表的字段包括：订单号、用户 ID、商家 ID（一次下单可以拆分成多个商家的子订单，但毕设复杂度有限时可以直接一个订单对应一个商家）、商品总金额、实际支付金额、优惠金额、订单状态、收货/取餐信息、备注、支付时间、接单时间、完成时间、创建时间。由于涉及金额和订单状态，在数据库里最好把每个状态更新时间都单独记录，方便后台管理员排查异常订单。

订单明细表 order_item 则用于记录每个菜品在一个订单里的快照信息，包括菜品名称、价格、数量、图片。为什么要存冗余字段而不是直接关联菜品 ID？因为如果商家以后修改了价格或者下架了菜品，用户的历史订单展示仍应保持下单时的原样。这个细节在日常项目里很不起眼，但往往是答辩老师关注的数据一致性考点。

3.4 评论和管理端相关表

评论表 comment 需要关联订单明细或订单 ID、用户 ID、商家 ID，包含评分、评论内容、回复内容、评论时间。为防止用户对同一个订单多次评价，可以对 order_id 建唯一索引。除了评分展示，后台统计商家评分时可以直接从该表聚合查询。

管理员表 admin 是最容易被忽略的。很多新手只写了一套学生用户系统，后台登录直接用固定账号写在代码里，这样并不优雅。建议建表时包含管理员 ID、用户名、密码、真实姓名、角色（超级管理员、普通管理员、商家管理员）、状态、最近登录时间。其中商家管理员需要和商家表关联，方便后台登录后直接管理自己窗口的数据。

4. 小程序端功能逐个落地：微信登录、选餐、购物车与下单流程

微信小程序的开发节奏通常是从首页搭建开始，再到登录授权、菜品数据渲染、购物车和订单页。为了让文章看起来更贴近实际项目，我把实现过程拆成几段来说明，其中登录态处理和下单流程是最容易踩坑，也是最有讨论价值的地方。

4.1 小程序登录：不是简简单单 wx.login 就完事

每次提到微信小程序登录，很多人第一反应就是“调用 wx.login 然后发请求给后端”。这句话没错，但如果不把它们背后的 token 机制搞清楚，项目演示时用户一旦清缓存或者重新打开小程序，就会出现登录态失效、白屏或接口报 401 的情况。

完整流程是这样：小程序调用 wx.login 得到临时凭证 code，再把 code 通过 HTTP 请求传给后端，后端拿着 code 去微信接口服务换取用户的 session_key 和 openid，随后在数据库 user 表里根据 openid 查找或创建用户记录，生成一个自定义登录态 token（可以用 UUID 或 JWT），最后把这个 token 返回给前端。

前端拿到 token 后，一般的做法是存储到 wx.setStorageSync('token', token) 中，后续每个需要登录身份的请求都在 header 里带上 Authorization: token。这样做的目的是让后端不用每次请求都去找微信交换用户信息，只需要根据 token 查询对应的用户即可，也减少微信接口的调用频率。

需要注意的点是：直接拿前端传来的 openid 作为可信身份是不可行的。因为小程序包很容易被反编译抓包，如果前端伪造 openid，后端拿到的数据就不准确了。必须由后端通过 code 向微信官方服务器换取身份，这样才安全。调试时你可以给后端 Controller 打日志，把 wx.login 返回的 code 和最终的 openid 对应关系确认一下。

我在代码里通常是用一个 LoginController 专门处理这个请求，核心步骤如下：

java复制@RestController
@RequestMapping("/api/user")
public class UserController {
    
    @Resource
    private UserService userService;
    
    @PostMapping("/login")
    public Result login(@RequestBody LoginDTO loginDTO) {
        // 1. 用 code 调用微信接口，获得 openid
        String openid = wechatService.getOpenid(loginDTO.getCode());
        // 2. 根据 openid 查询用户，不存在则注册
        User user = userService.findOrCreate(openid);
        // 3. 生成 token 并保存到缓存或数据库
        String token = tokenService.generateToken(user.getId());
        // 4. 返回用户信息 + token
        return Result.success("登录成功", Map.of("token", token, "user", user));
    }
}

4.2 首页展示与分类点餐：关注加载体验

首页的展示决定了用户对小程序的第一印象。点餐首页通常会放轮播图、食堂列表或菜品分类栏。轮播图需要后端提供一个 banner 接口，返回图片 URL；分类栏则是从后端查询全局分类，点击不同分类会触发菜品数据切换。

在开发过程中，有一个体验问题值得注意：菜品图片如果是放在本地服务器，加载速度会比较慢，尤其是高峰期很多学生同时访问时。常规做法是给小程序配一个图片懒加载，<image> 标签加上 lazy-load 属性，只有滚动到可视区域时才加载图片。同时后端在返回菜品列表时，不要一次性把数据库里所有菜品查出来，一定要做分页，每页 10 条或 15 条，这样能够有效减轻服务器压力。

列表页交互还涉及“加入购物车”的动作。点击菜品卡片上的加号按钮，如果当前菜品已经下架或库存为 0，要给出提示；加入成功后可以做一个简单的 Toast 提示，也可以让右上角购物车 Tab 显示角标数量。在小程序里跨页面同步购物车数量时，我建议将购物车数据放在 app.globalData 和本地存储中双写一份，因为很多用户会直接从详情页返回首页，导致购物车页面的数据重新加载时不一致。

4.3 购物车的本地缓存设计

我前面提到，购物车数据优先存在小程序缓存里。具体数据结构可以这样设计：

json复制{
  "items": [
    {
      "dishId": 12,
      "dishName": "红烧肉套餐",
      "price": 15.5,
      "imageUrl": "https://your-domain.com/upload/...",
      "quantity": 2,
      "merchantId": 3,
      "merchantName": "二楼川菜窗口",
      "checked": true
    }
  ]
}

每次执行“加入购物车”操作时，先读取缓存，判断该 dishId 是否已经存在；存在就把原数量加一，不存在就 push 一个对象。购物车列表页渲染时，前端在 data 里维护一个 totalPrice，每次勾选状态或数量变化时重新计算并调用 setData。为了避免点击太快导致计算错误，建议在每次修改缓存后同时重新从缓存读取一次，保证 data 和缓存数据一致。

下单跳转确认页时，把选中的商品集合、总金额、备注等信息通过页面 URL 参数或全局变量传过去。这里有一点要提醒：小程序 URL 长度有限，如果购物车里菜品很多，直接把整个数组放在 URL 上有可能导致数据被截断。更好的方式是打开确认页前先将数据写入本地存储，然后在确认页 onLoad 里读取存储内容。

4.4 下单流程与库存扣减

下单接口是后端压力最大的地方，也是需要小心处理事务的地方。用户从购物车确认页点击“立即支付”后，前端拿到购物车中的菜品数据，计算一个期望总价，连同备注信息一起 POST 到后端。后端收到请求后需要做以下几步：

1. 校验用户 token 是否有效并获取用户 ID。
2. 根据菜品 ID 列表查询所有菜品的最新价格和库存。
3. 将前端传来的总价与后端根据菜品价格累加出的总价做对比，如果不一致则提示前端数据异常。
4. 检查每个菜品库存是否足够，如果不够则返回具体菜品名称提示库存不足。
5. 在同一个事务里插入订单主表和订单明细表，扣减菜品库存。
6. 返回订单 ID 和支付参数，前端引导用户去调用 wx.requestPayment 完成支付。

这里特别要注意第 5 步的原子性。如果插入订单成功，但是扣减库存失败，会让整个系统出现脏数据。在 Spring 中可以把事务注解加到 Service 方法上：

java复制@Transactional(rollbackFor = Exception.class)
public Long createOrder(CreateOrderDTO dto) {
    // 校验菜品
    // 写入订单主表
    // 写入订单明细
    // 扣减库存：UPDATE dish SET stock = stock - #{quantity} WHERE id = #{id} AND stock >= #{quantity}
    // 返回订单号
}

库存扣减的 SQL 必须加上 stock >= quantity 这个条件，否则并发下可能出现超卖，也就是卖出数量比库存还多的情况。至于微信支付接入，如果是毕设没有商户号，一般可以做“模拟支付”，直接把订单状态置为已支付，同时给出一个说明；如果现实中要完整上线，则需要申请微信支付商户号并配置好 mch_id 和证书，接入 wx.requestPayment。

4.5 订单状态在前端完整闭环

用户提交订单后一定会主动或被动地想知道“我的餐现在做到什么程度了”。订单状态在小程序端展示时，建议做一条可视化进度条：待支付 → 待接单 → 制作中 → 待取餐 → 已完成。进度条的数据来源于订单状态值，前端根据 status 字段计算出当前进度索引，再渲染不同的样式。

订单状态要实时刷新，做法有两种：用户进入订单详情页时主动调用轮询接口，每隔几秒查一次最新的订单状态；或者通过 WebSocket 推送。小项目里用轮询完全足够，但要注意小程序端轮询可能比较耗电和耗流量，建议只在订单详情页做，订单列表页上下拉刷新即可。

如果商家长时间没有接单，用户应该能取消订单。这个操作要向后端发送取消请求，后端需要判断订单状态是否是“待接单”。一旦商家已经开始制作，用户侧就无法直接取消了，只能联系商家处理。这种状态限制要在前端 UI 中体现，比如按钮只在对应状态显示，避免用户点出无效操作。

5. 管理后台：菜品管理、订单处理和数据统计的实现思路

这套系统里管理后台用的是 Web 页面方式，和微信小程序是两套独立的前端工程。管理端功能按角色拆分：超级管理员管理商家和系统配置，商家管理员管理自己的菜品、订单、评论。这样做的好处是后台可以针对角色渲染不同菜单，权限边界清晰，答辩时也更容易讲明白。

5.1 后台登录和权限控制

后台登录不能直接用微信的 openid，因为运营人员不会拿个人微信授权去管理平台。我在实现时让后台登录走账号密码模式，管理员表里存用户名和密码，密码用 BCrypt 加密。用户提交登录请求后，后端验证通过，返回一个 token，前端把它存在本地，并在后续请求中放入 header。后台路由守卫在每次页面跳转时都检查本地有没有 token，没有就强制跳回登录页。

权限控制需要在后端拦截器里实现。比如商家只能看到自己窗口的菜品和订单，不能查看别人的数据。所以查询商家订单时，SQL 一定要带上 merchant_id = 当前登录商家ID 的条件，不能只写一个 SELECT * FROM order 然后把数据全部返回。拦截器里还可以判断管理员角色，是超级管理员才有权限访问商家管理、系统统计相关的接口。

5.2 菜品管理的实现细节

菜品管理页面需要展示菜品缩略图、名称、价格、销量、库存、状态。新增菜品时通常会遇到图片上传的问题。由于后台是 Web 项目，最简单的方式是把图片上传到后端的本地目录，然后在数据库里保存访问路径。但要注意，项目如果部署在云服务器上，上传目录的写权限一定要配置正确，并且在 SpringMVC 的配置里注册一个静态资源映射，让上传的图片可以通过 URL 访问到。

我在项目里通常会把图片上传目录配置为可配置项：

xml复制<mvc:resources mapping="/upload/**" location="/upload/"/>

然后上传接口接收 MultipartFile，生成文件名时使用 UUID 拼上原文件后缀，避免重复。上传成功后返回给前端一个图片访问地址，同时把 imageUrl 字段更新到菜品数据里。

菜品编辑时还有一个需要关注的问题是缓存和库存。如果菜品已经产生订单，修改价格后历史订单金额不变，因为订单明细表已经有冗余快照；但用户下次下单时就会按照新的价格计算，所以商家修改价格时要给出明确的提示，避免误解。

5.3 订单处理：从待接单到完成

订单处理是商家端后台每天使用最频繁的功能。订单列表按状态分类，商家进入后先看到“待接单”的订单，点击“接单”后，订单状态从 1 变成 2，用户端立刻能看到“制作中”。接着商家在备餐完成后点击“制作完成”，状态变 3；如果是线下取餐，可以由用户在取餐后点击确认或由商家操作完成，状态变 4。

每当状态变化，后端需要更新订单表并记录时间。我建议给订单状态变更做一个简单记录表或者日志系统，用来跟踪“什么时候接单”“什么时候完成”，不仅答辩演示的时候有据可查，将来排查用户投诉也能快速找到问题。如果项目复杂一些，还可以在状态变更时调用微信订阅消息接口，给学生发送“您的订单已开始制作”的通知。订阅消息在小程序中要求用户主动授权，所以用户下单前需要引导用户勾选“接收订餐进度通知”。

5.4 数据统计与报表展示

高校食堂最关心的问题就是“哪些菜品卖得好” “每天走多少流水”。后台首页的数据统计可以放四个大数字卡片：今日订单数、今日交易额、在售菜品数量、用户总数，下方再来两个趋势图表。如果不想引入太重的前端图表库，也可以直接用 ECharts 的 CDN 文件，或者用简单的 CSS 折线统计图做展示。

后端统计逻辑尽量用 SQL 聚合一次查出来，不要在 Java 代码里循环再聚合。比如统计近 7 天订单量，可以调用如下查询：

sql复制SELECT DATE(create_time) AS day, COUNT(*) AS order_count, SUM(pay_amount) AS total_amount
FROM orders
WHERE create_time >= DATE_SUB(CURDATE(), INTERVAL 7 DAY)
  AND status != 5
GROUP BY DATE(create_time)
ORDER BY day;

返回给前端之后，用数组形式存储日期和数值，再渲染到图表中。这个统计代码如果直接在 Controller 里写，业务层会很乱；建议单独建一个 StatisticsService，专门负责这类查询逻辑。

6. 测试部署中的高频问题：从本地联调到上线审核的避坑记录

项目开发完到真正可以演示、部署，中间还有一段很磨人的路。这套系统由于涉及微信小程序、Java 后端、MySQL 数据库三个部分，任何一个环节配置不对，都会导致整个流程不通。我把自己实际踩过的问题列出来，希望你少走点弯路。

6.1 request 合法域名与 HTTPS 问题

微信小程序在真机预览时默认会校验请求域名必须是 HTTPS，而且域名必须在小程序后台配置到 request 合法域名列表里。很多人在本地开发时后端用的是 http://localhost:8080，开发者工具里勾了“不校验合法域名”可以正常跑，但一拿出手机扫描预览版，所有请求全部失败。

应对办法是：如果只是演示，你可以让后端直接用局域网 IP 加端口，同时手机和电脑连同一个 Wi-Fi，再在开发者工具中把详情里的“不校验合法域名”打开，真机预览也能访问。但如果你要提交正式版本或者发布体验版，就必须申请一个已备案的域名，配置好 HTTPS 证书，同时在小程序管理后台添加 request 合法域名。这里要注意的是，后端服务器上要用 Nginx 做反向代理，把域名 443 端口转发到 Tomcat 的 8080 端口，同时解决跨域问题。

配置 Nginx 时可以采用类似下面的方式：

nginx复制server {
    listen 443 ssl;
    server_name your.domain.com;

    ssl_certificate /etc/nginx/cert/yourdomain.pem;
    ssl_certificate_key /etc/nginx/cert/yourdomain.key;

    location /api/ {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

6.2 前后端跨域配置

浏览器跨域和微信小程序跨域的处理思路略有不同。小程序端不存在传统浏览器那种严格的同源策略，但是后端接口必须允许来自任何来源的请求，否则在线调试时会遇到预检请求失败。在 SpringMVC 项目中，需要配置全局 CORS 过滤器。

我遇到过的情况是：前端请求能通 GET 接口，带 JSON 的 POST 接口却一直报跨域错误。排查后发现服务端没有处理 OPTIONS 预检请求，而浏览器发起跨域 POST 之前会先发送一个 OPTIONS 请求，后端没正确响应它，后续请求就被拦截了。解决办法是增加一个 CorsFilter，在过滤器中直接对 OPTIONS 请求返回 200，并设置好 Access-Control-Allow-Headers、Access-Control-Allow-Methods 等响应头。

一个简单的方式是在 SpringMVC 的 XML 或配置类里注册过滤器，不必每篇文章完整贴出，核心是让后端允许 Authorization 这个请求头、允许 POST/GET/PUT/DELETE/OPTIONS 方法、允许所有来源。

6.3 微信开发者工具中的路径、缓存与用户数据

开发过程中我发现微信开发者工具的“清缓存”功能非常实用。有时候修改了后端返回的数据结构，但小程序端仍显示旧数据，多半是本地缓存或数据前一次请求的返回值没有被清空。建议每次改接口后在开发者工具里点开“清缓存并重新编译”，同时在后端代码中做好日志输出，方便对照响应结果。

真机调试时，还有一个容易踩的坑是：用户删除小程序后再次搜索进入，之前存储在 storage 里的 token 已经被清除，后端如果没有做 token 失效和用户重新自动登录的逻辑，用户在页面上会看到各种数据加载失败。解决办法是：在小程序冷启动时的 app.js 的 onLaunch 中，先检查本地是否有 token，没有则静默登录调用 wx.login；请求后端时如果返回 401，则说明 token 过期，自动重新登录后重发请求。

6.4 并发场景和事务的简单验证

虽然只是课程项目，但如果要体现出你的工程能力，建议至少做一次简单的并发验证。比如用 Jmeter 或 Postman 的 Runner 工具，对“下单接口”连续发送几十个并发请求，检查数据库里是否出现库存扣成负数以及订单数据是否完整。如果发现问题，就要重点检查事务和 SQL 条件是否写对。

之前提到过下单扣库存的 SQL 一定要带库存检查条件，同时 Service 层必须用事务包裹。验证时可以准备一个库存为 3 的菜品，用 Postman 同时发 5 个请求，最后数据库里该菜品的库存不应小于 0，成功订单数最多只能是 3。如果测试结果显示库存出现负数，那说明并发控制没有生效，需要调整方案。

6.5 项目部署上线时的时间线规划

很多同学到答辩前一晚才去部署，结果发现域名备案没办好、服务器安全组端口没开、HTTPS 证书申请流程没走完，手忙脚乱。建议你在开发阶段就把部署环境规划好：云服务器选了之后先安装 JDK、Tomcat 或 Spring Boot 运行环境、MySQL，把后端 war 包部署成功，再开始写小程序，开发完成后直接对接线上接口。这样可以避免项目写完了却发现环境根本无法跑通的尴尬。

如果没有云服务器，也可以使用内网穿透工具配合本地环境做临时演示，但接口域名大概率不是备案过的 HTTPS 域名，小程序真机预览需要特殊设置，只适合演示用，不能满足正式提交审核。

另外在后端部署时，要注意 MySQL 的字符集必须设置成 utf8mb4，否则存储用户昵称里的表情符号时会报错或者乱码。数据库连接串后面可以加参数：useUnicode=true&characterEncoding=utf8mb4，同时表结构也要设置正确的字符集。这个细节不显眼，但真遇到的时候会让人非常头疼。

整套系统做完后，我又仔细想过哪些地方还能扩展：比如引入 Redis 缓存热点菜品列表、用 RabbitMQ 做订单超时自动取消、增加管理端数据看板的图表丰富度，甚至把小程序端升级成微信云开发模式。不过对于以微信小程序和 SSM 为核心的高校订餐系统项目来说，当前的方案已经能把一条完整业务闭环跑得很顺畅。如果让我总结一个最值得坚持的习惯，那就是先把数据库设计和接口约定想透再动手写页面，别看它不起眼，它决定了你后面所有联调工作顺利与否。