基于Spring Boot和微信小程序的智能校园点餐系统设计-代码聚汇网

每年到答辩季，我都能看到大量管理类毕设项目里写着同一句话："本系统旨在提升校园食堂服务效率"。这题目在毕设圈确实称得上常青树，但它也是踩坑重灾区——太多人把它做成了简单的增删改查，答辩时老师一问"智能在哪里"就卡壳。这篇想拆解的，是一套基于Spring Boot + 微信小程序的智能校园点餐管理系统，涉及完整前后端代码、说明文档和论文写作思路。我会从技术选型、数据库设计、后端接口、小程序端落地到联调避坑，把从拿到题目到答辩的全过程完整过一遍，尤其讲清楚"智能"两个字要怎样落到可演示的功能上。

1. 毕设定题复盘：一个点餐系统怎样撑起"智能"二字

1.1 为什么这类系统年年有人做，却年年有人翻车

校园点餐系统之所以成为毕设常青树，核心原因是业务链路特别完整。用户从浏览菜品、加入购物车、提交订单、模拟支付，到管理员处理订单、管理菜品、查看统计报表，这是一条能够覆盖前端交互、后端逻辑、数据库设计、权限控制所有环节的完整业务线。对毕设来说，这意味着工作量好凑、模块好划分、论文好写。

但翻车的人也多，原因就一个：只做了CRUD。菜品增删改查、用户登录注册、订单列表展示，这几个功能拼起来确实能跑，但没有任何区分度。老师在看过几十个类似系统之后，判断标准早就不停留在"能不能跑"，而是"你有没有认真想清楚业务"。这时候，题目里的"智能"如果没有落地，结果就是被追问到无话可说。

1.2 把"智能"拆成三个可演示的功能点

"智能"这个词在答辩时特别容易被追问，所以必须在系统里给出具体承载。我这套系统里做了三个模块来撑住"智能"的定位，全部是可以在演示环节现场操作的：

菜品推荐：基于用户的历史订单统计分类偏好，把用户吃过的菜按分类聚合，在首页"为你推荐"区域推送同分类下未下单的高销量菜品。这里不需要上协同过滤，一个简单的偏好统计SQL加两个查询就能实现，但效果很直观。
销量统计排行：实时统计所有菜品的销量Top10，分别展示在用户端首页的"热销榜"和管理员端的数据看板里，按周、按月切换。
订单趋势看板：管理员端展示近7天的订单数量和营收变化，用柱状图呈现，让系统看起来有"管理数据"的味道。

这三个功能都不难实现，难点在于把它们嵌进业务流程的恰当位置，而不是单独做一个孤零零的统计页面。推荐模块放在首页顶部，销量榜放在菜品列表侧栏，趋势看板放在管理员首页，这样老师打开系统第一眼看到的就是"智能"的体现，而不是一个普通的菜单列表。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 技术选型不是堆框架：springboot与小程序之间怎么配才不翻车

2.1 后端骨架：JDK版本、Spring Boot版本、ORM框架怎么组合

这套系统的后端我推荐用 JDK 8 + Spring Boot 2.7.x + MyBatis-Plus。很多人会纠结要不要用Spring Boot 3.x，我的建议是不要。Spring Boot 3要求JDK 17起，虽然新，但很多毕设用的服务器环境、旧教程资料、第三方依赖都还停留在JDK 8时代，一旦遇到兼容性问题，排查成本远超收益。Spring Boot 2.7是2.x系列的最终版本，该有的功能都有，生态最稳定。

ORM层面MyBatis-Plus比原生MyBatis省事太多，单表CRUD基本不用写SQL，代码生成器还能直接生成实体类、Mapper、Service、Controller。对毕设来说，这意味着你能把更多时间花在业务逻辑而不是重复的增删改查上。要注意的是版本匹配：Spring Boot 2.7.x对应MyBatis-Plus 3.5.x，直接引入mybatis-plus-boot-starter即可。

Java版本和数据库版本是默认的坑：本地开发JDK 18去编译Spring Boot 2.7项目，大概率遇到各种反射警告甚至启动报错；MySQL 8.0的驱动类名是com.mysql.cj.jdbc.Driver，MySQL 5.7则是com.mysql.jdbc.Driver，项目里别搞混。这些细节看起来小，但每年都有同学在环境配置上卡掉一整天。

2.2 小程序端：原生框架还是uni-app

小程序端我选择微信小程序原生框架，不引入uni-app或Taro。理由很直接：毕设项目不需要跨端，原生框架文档全、社区答案多、调试工具完善，学习成本最低。uni-app的优势是"一套代码多端运行"，但代价是复杂的编译链路和样式兼容问题，对毕设来说完全是负担。

原生小程序的项目结构很简单：pages目录放页面、utils放工具函数、api放接口封装、components放自定义组件。用微信开发者工具新建项目时直接选JavaScript模板，不勾选云开发。头像昵称相关功能要注意，微信2022年10月之后调整了wx.getUserProfile接口策略，新版本小程序无法直接弹窗获取头像昵称，建议在"我的"页面提供"点击获取头像昵称"按钮，用button组件的open-type="chooseAvatar"来获取头像，昵称用input让用户手动输入。这个改动很多教程没更新，照抄旧代码会直接报错。

2.3 前后端数据交互：一份统一返回体和分页格式

前后端分离的项目，接口规范必须一开始就定好。我统一封装了一个返回体Result<T>，包含三个字段：code（200成功、400业务错误、401未登录、500系统错误）、msg（提示信息）、data（实际数据）。前端request.js里对code做统一拦截，如果不是200，直接弹出msg提示。这样后端每个接口不需要重复写异常处理逻辑，前端也不用每个请求单独判断。

分页格式统一为PageResult<T>，包含records（当前页数据）、total（总条数）、current（当前页码）、size（每页大小）。小程序端用wx.request请求时，把pageNum和pageSize作为参数传过去，后端用MyBatis-Plus的Page对象接收，整个链路很顺。接口路径统一以/api开头，比如/api/dish/list、/api/order/submit，这样遇到跨域问题时只需要对/api路径做一次放行配置。

3. 数据库设计是系统的一半：核心业务表结构与设计理由

3.1 用户表：openid不是随便存的，它是登录钥匙

微信小程序登录绕不开openid，它是微信区分用户的唯一标识，相当于用户在这个小程序里的身份证号。用户表的设计直接决定登录逻辑怎么写。

字段	类型	说明
id	bigint 主键自增	用户ID
openid	varchar(64) 唯一索引	微信openid，登录凭证
nickname	varchar(64)	昵称
avatar_url	varchar(255)	头像地址
role	tinyint	1-普通用户 2-管理员
phone	varchar(20)	联系电话
status	tinyint	1-正常 0-禁用
create_time	datetime	注册时间

openid必须加唯一索引，因为登录逻辑就是"按openid查用户，查不到就自动注册"。这里有个容易踩坑的点：如果项目接入了Spring Security或Sa-Token，用户表的role字段会被用来做权限判断，但要记得前端也要根据role显示不同的菜单入口，否则只控制后端接口不控制前端页面，用户还是能通过修改路由看到管理员页面。

3.2 菜品与分类表：一个点餐系统的商品模型

菜品表和分类表是点餐系统的商品模型基础。分类表简单，就id、name、sort、status几个字段。菜品表则是业务核心，字段设计直接影响后面所有流程：

sql复制CREATE TABLE dish (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    name VARCHAR(64) NOT NULL COMMENT '菜品名称',
    category_id BIGINT NOT NULL COMMENT '分类ID',
    price DECIMAL(10,2) NOT NULL COMMENT '价格',
    image VARCHAR(255) COMMENT '菜品图片',
    description VARCHAR(255) COMMENT '描述',
    stock INT DEFAULT 0 COMMENT '库存',
    sales INT DEFAULT 0 COMMENT '销量',
    status TINYINT DEFAULT 1 COMMENT '1-上架 0-下架',
    create_time DATETIME,
    update_time DATETIME
);

stock和sales是两个关键字段。stock用于下单时扣减库存，保证系统不是只做展示；sales则是"智能推荐"和销量榜的数据源，每次订单完成时累加。很多同学把销量做成实时SUM查询，也没错，但那样榜单接口每次都要遍历订单明细表，数据量大一点就变慢。用冗余字段sales，每次下单事务里同步更新，查询时直接排序，性能更好，逻辑也更清晰。注意DECIMAL(10,2)是价格字段的正确类型，不要用FLOAT，否则金额会出现精度误差。

3.3 购物车表：写入频繁的业务表，设计要克制

购物车表是增删改查最频繁的表，设计原则是"能省则省"，不要加冗余字段。我的表结构只有：

sql复制CREATE TABLE cart (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    user_id BIGINT NOT NULL,
    dish_id BIGINT NOT NULL,
    quantity INT NOT NULL DEFAULT 1,
    checked TINYINT DEFAULT 1,
    create_time DATETIME,
    UNIQUE KEY uk_user_dish (user_id, dish_id)
);

user_id + dish_id加唯一索引，这样同一道菜加入购物车时走ON DUPLICATE KEY UPDATE或先查再更新，天然避免重复记录。checked字段用来支持购物车勾选结算的功能，也就是用户只结算勾选的菜品。

购物车建议放服务端而不是纯本地存储。虽然小程序本地storage也能存购物车，但服务端购物车有三个好处：换设备数据不丢、后端能直接读购物车生成订单、管理端能看到活跃用户数据。写入频繁的接口要注意性能，但毕设规模下不需要Redis缓存，MySQL完全扛得住，别把系统复杂度人为拉高。

3.4 订单主表与订单明细表：为什么必须拆开

订单设计是点餐系统里最有"业务含金量"的部分。很多人图省事把订单和菜品塞在一张表里，用逗号分隔菜品ID，这是典型的反模式。我的设计是拆成两张表：orders（订单主表）和order_item（订单明细表）。

订单主表存一次下单的整体信息：

sql复制CREATE TABLE orders (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    order_no VARCHAR(32) NOT NULL UNIQUE COMMENT '订单编号',
    user_id BIGINT NOT NULL,
    total_amount DECIMAL(10,2) NOT NULL,
    status TINYINT DEFAULT 0 COMMENT '0-待支付 1-待制作 2-待取餐 3-已完成 4-已取消',
    remark VARCHAR(255),
    address VARCHAR(255),
    create_time DATETIME,
    pay_time DATETIME,
    finish_time DATETIME
);

订单明细表存订单里的每一道菜：

sql复制CREATE TABLE order_item (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    order_id BIGINT NOT NULL,
    dish_id BIGINT NOT NULL,
    dish_name VARCHAR(64) NOT NULL,
    dish_image VARCHAR(255),
    price DECIMAL(10,2) NOT NULL,
    quantity INT NOT NULL,
    subtotal DECIMAL(10,2) NOT NULL
);

拆表的理由有三个：第一，订单提交后菜品价格可能调整，明细表里dish_name和price是下单时的快照，不能再去关联菜品表实时查，否则历史订单价格会变；第二，一个订单多个菜品时，主表一条、明细表多条，是标准的一对多模型，方便统计某个菜品的销量；第三，订单列表和订单详情查询解耦，列表只查主表，详情再查明细，性能更好。

3.5 支撑"智能"的数据沉淀：这些表别看轻了

前面说的推荐和统计功能，依赖的不只是菜品表的sales字段，还有两块数据沉淀：用户浏览记录和用户收藏。浏览记录表记录用户每次查看菜品详情的行为，收藏表记录用户主动表达的兴趣。

sql复制CREATE TABLE dish_favorite (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    user_id BIGINT NOT NULL,
    dish_id BIGINT NOT NULL,
    create_time DATETIME,
    UNIQUE KEY uk_user_dish (user_id, dish_id)
);

推荐逻辑很朴素：先从order_item表统计当前用户历史订单里各分类的点餐次数，得到偏好分类；再从dish表里找出该分类下销量高且用户没点过的菜品，按sales降序取前10条。这个SQL用两次查询拼接，不需要复杂的关联子查询，但效果在演示时已经很能说明问题。要注意dish_favorite表记得加唯一索引，否则用户反复点击收藏会插入重复数据。

4. 后端接口逻辑：从微信登录到订单状态流转的实现要点

这是整套系统最容易出Bug的环节，也是答辩时必问的考点。完整流程是：前端调用wx.login()拿到临时凭证code，把code传给后端；后端拿着code去请求微信接口https://api.weixin.qq.com/sns/jscode2session，带上小程序的appid和appsecret；微信返回openid和session_key；后端查数据库用户表，openid存在则登录成功，不存在则自动注册并返回用户信息；后端生成自己的登录凭证，返回给前端保存。

用伪代码表达：

java复制@PostMapping("/login")
public Result<String> login(@RequestBody LoginRequest req) {
    // 1. 用code向微信服务器换openid
    String url = "https://api.weixin.qq.com/sns/jscode2session?appid=" + appid
        + "&secret=" + appsecret + "&js_code=" + req.getCode() + "&grant_type=authorization_code";
    // 2. 发HTTP请求解析返回的openid
    String openid = getOpenidFromWx(url);
    // 3. 查用户表，不存在则注册
    User user = userMapper.selectByOpenid(openid);
    if (user == null) {
        user = new User();
        user.setOpenid(openid);
        user.setRole(1);
        userMapper.insert(user);
    }
    // 4. 生成JWT返回
    String token = JwtUtil.createToken(user.getId(), user.getRole());
    return Result.success(token);
}

这里有几个必须注意的点。第一，appsecret绝不能暴露给前端，只能放在后端配置里，否则一旦泄露别人可以冒充登录。第二，code只能用一次，用过后立即失效，所以前端千万不能重复调用wx.login()，否则第二次请求会拿到失效的code。第三，微信接口返回的openid需要从JSON里解析，用JSONObject或Hutool的JSONUtil都可以，别自己写字符串截取。

4.2 Token方案选型：JWT还是Sa-Token

登录凭证有两条路线：JWT和Sa-Token。JWT是无状态token，服务端不保存session，用户信息加密在token里；Sa-Token默认是服务端session模式，登录后把用户信息存在服务端缓存里，给前端一个token字符串。对毕设来说，我推荐JWT，原因有三个：代码量少、不需要引入Redis缓存、面试和答辩时更容易把原理讲清楚。

JWT的核心是Header.Payload.Signature三段式结构，用HS256算法做签名。我项目里用一个简单的JwtUtil工具类，包含三个方法：createToken（生成token）、parseToken（解析token里的userId）、isExpired（判断过期）。为了演示方便，token有效期设7天。需要注意：JWT是无状态的，一旦签发无法主动让其失效，所以如果系统里有"管理员禁用用户"的需求，必须在接口里额外校验用户状态，而不能只依赖token有效。

4.3 点餐核心流程：加购、下单、订单状态流转

下单是整个系统最重要的接口，也是事务处理最密集的地方。完整流程是：

用户从购物车勾选菜品，前端提交选中项到后端；
后端根据userId查出购物车勾选数据；
创建订单主表记录，计算总金额；
创建订单明细表记录，逐条写入菜品快照；
扣减菜品库存；
清空购物车已下单项；
返回订单号，前端跳转订单详情页进行模拟支付。

这个接口必须加@Transactional事务注解，因为步骤3到6之间任何一步失败，都要保证数据库回到操作前状态。最隐蔽的坑是库存扣减的并发问题：两个用户同时买同一道菜，可能会出现超卖。标准做法是使用UPDATE dish SET stock = stock - #{quantity} WHERE id = #{dishId} AND stock >= #{quantity}，通过数据库行锁保证扣减安全，而不是先SELECT再UPDATE。

订单状态机我设计成五态：

状态码	含义	触发操作
0	待支付	下单成功、尚未模拟支付
1	待制作	用户完成模拟支付
2	待取餐	商家接单并完成制作
3	已完成	用户确认取餐
4	已取消	待支付状态下用户主动取消

状态流转全部在后端接口控制，前端只管展示。每次状态变更都要记一次update_time，这样管理端可以看到订单处理时效。答辩时老师几乎必问"订单状态怎么设计"，能画出这个状态图再讲清楚触发条件，基本就稳了。

4.4 "智能"接口的实现思路：销量排行与偏好推荐

销量排行接口最简单：

java复制@GetMapping("/hot")
public Result<List<Dish>> hotDishList() {
    LambdaQueryWrapper<Dish> wrapper = new LambdaQueryWrapper<>();
    wrapper.eq(Dish::getStatus, 1)  // 只查上架菜品
           .orderByDesc(Dish::getSales)
           .last("LIMIT 10");
    return Result.success(dishMapper.selectList(wrapper));
}

偏好推荐接口稍复杂，核心SQL两条。第一条查用户历史订单的品类偏好：

sql复制SELECT d.category_id, COUNT(*) AS cnt
FROM order_item oi
JOIN dish d ON oi.dish_id = d.id
JOIN orders o ON oi.order_id = o.id
WHERE o.user_id = #{userId}
GROUP BY d.category_id
ORDER BY cnt DESC
LIMIT 1

第二条查出该分类下用户未点过的菜品，按销量排序。两步操作在Service层串起来，返回结果给前端。这个推荐算法很粗糙，但胜在逻辑清晰、容易讲解。答辩时老师如果问"为什么不用协同过滤"，可以回答：当前数据量下基于分类的偏好推荐已经能满足需求，协同过滤更适合海量用户数据的场景，属于后续拓展方向。这个回答既严谨又有分寸。

5. 小程序端落地方案：页面结构、状态管理与支付模拟

5.1 小程序端目录规划：按模块分包，别把页面全堆在pages

小程序端目录结构直接影响开发效率和后期维护。我的目录规划是：

text复制pages/
├── index/          首页（轮播图、推荐菜品、热销榜）
├── category/       分类点餐
├── dishDetail/     菜品详情
├── cart/           购物车
├── order/          订单确认
├── orderList/      订单列表
├── orderDetail/    订单详情
├── mine/           个人中心
├── admin/          管理端首页（管理员可见）
├── adminDish/      菜品管理
├── adminOrder/     订单管理
└── adminStatistics/数据统计

登录拦截不要在每个页面做，而是封装在请求层：request.js里发现没有登录态，直接跳转mine页面弹登录框。这样新增页面时不用重复写登录判断逻辑。管理端页面建议单独建admin目录，用role字段控制入口，普通用户看不到管理入口，管理员登录后首页的"我的"页面会显示"进入管理后台"按钮。

5.2 登录态与请求封装：request拦截器的正确姿势

小程序没有axios，但可以封装一个类似的request方法。核心逻辑：

javascript复制const request = (url, method, data) => {
  return new Promise((resolve, reject) => {
    wx.request({
      url: BASE_URL + url,
      method: method || 'GET',
      data: data || {},
      header: {
        'Content-Type': 'application/json',
        'token': wx.getStorageSync('token') || ''
      },
      success: (res) => {
        if (res.data.code === 401) {
          // 未登录或token过期，跳转登录
          wx.navigateTo({ url: '/pages/mine/mine' });
          reject(res.data);
        } else if (res.data.code === 200) {
          resolve(res.data.data);
        } else {
          wx.showToast({ title: res.data.msg, icon: 'none' });
          reject(res.data);
        }
      },
      fail: (err) => {
        wx.showToast({ title: '网络异常', icon: 'none' });
        reject(err);
      }
    });
  });
};

登录态判断放在app.js的onLaunch里：先检查本地有没有token，有就尝试调用/api/user/info验证有效性，无效则清除并进入未登录状态。这里有一个容易被忽视的细节：wx.login()拿到的code每次登录都不一样，不需要前端保存，但session_key也不要存在前端，存在后端或完全丢弃。前端只保持后端的JWT token。

5.3 购物车与下单页的数据流：从本地载入到服务端

购物车页面的数据流要设计清楚。我采用的方案是：进购物车页时先展示本地storage里的缓存数据（保证秒开），同时异步请求服务端购物车接口，拿到数据后用服务端数据覆盖本地。

下单流程是：用户勾选购物车项→点击"去结算"→跳转订单确认页→确认页展示所选菜品清单、总金额、备注→点击"提交订单"→后端创建订单→拿到订单号→跳转订单详情页。这里要注意，订单确认页展示的数据是前端从本地购物车临时算出来的，但真正生成订单时后端会重新验证一遍金额和库存，不能信任前端传过来的总金额。实际开发中，后端应该重新从数据库购物车表查询并计算，而不是前端传多少就收多少。

javascript复制// 提交订单
const submitOrder = () => {
  const selectedItems = cartList.filter(item => item.checked);
  request('/api/order/submit', 'POST', { items: selectedItems }).then(orderNo => {
    wx.redirectTo({ url: '/pages/orderDetail/orderDetail?orderNo=' + orderNo });
  });
};

5.4 支付模块的落地形态：毕设里的模拟支付

真实接入微信支付需要企业主体、商户号、证书、回调域名等一系列条件，个人开发者根本无法在毕设里完整实现。所以这里用模拟支付：用户在订单详情页点击"立即支付"，弹出一个模拟支付确认框，输入任意密码或直接确认，前端调后端/api/order/pay接口，后端把订单状态从"待支付"改为"待制作"，同时扣减库存、累加销量。

如果想做得更有仪式感，可以加一个模拟支付页面，展示订单金额，按钮写"确认支付（模拟）"，点击后延迟1秒跳转。答辩时如实说明"这是模拟支付，真实微信支付需要商户号，流程上是替换支付接口为微信统一下单接口"，这个回答是加分的，因为体现了你对业务落地的理解。

6. 联调调试中跑出来的那些坑和绕坑办法

6.1 真机预览连不上后端：localAddress，不是你的锅

小程序开发最经典的坑：开发者工具里一切正常，一用手机预览就请求失败。原因很简单，手机访问不了电脑的localhost，必须改成电脑的局域网IP，例如http://192.168.1.10:8080。同时，后端启动时要绑定0.0.0.0，否则只监听本地回环地址：

yaml复制server:
  address: 0.0.0.0
  port: 8080

开发者工具里还要在"详情→本地设置"勾选"不校验合法域名、web-view（业务域名）、TLS版本以及HTTPS证书"，真机预览时也要在手机端开启调试模式。这里注意：真机调试模式下请求HTTP接口是可以的，但如果用"预览"模式且没开调试，微信会强制要求HTTPS。所以演示时优先用开发者工具的模拟器，或者真机调试模式，不要在纯预览模式下指望HTTP能通。

6.2 跨域问题：明明后端接口用Postman能通，小程序却报错

Spring Boot后端默认不允许跨域请求，小程序虽然在客户端层面没有浏览器同源策略的限制，但后端必须返回正确的CORS头，否则请求会失败。最省事的方案是定义一个全局CORS配置类：

java复制@Configuration
public class CorsConfig {
    @Bean
    public CorsFilter corsFilter() {
        CorsConfiguration config = new CorsConfiguration();
        config.addAllowedOriginPattern("*");
        config.addAllowedHeader("*");
        config.addAllowedMethod("*");
        config.setAllowCredentials(true);
        UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
        source.registerCorsConfiguration("/**", config);
        return new CorsFilter(source);
    }
}

注意：前端自定义了token请求头，所以addAllowedHeader("*")必须打开，否则带token的请求会被拦截。setAllowCredentials(true)和addAllowedOriginPattern("*")在Spring Boot高版本里不能同时使用addAllowedOrigin，必须用addAllowedOriginPattern，否则启动直接报错。这些细节我在调试中踩过之后才明白。

6.3 图片上传403与404：本地存储方案要提前想清楚

小程序端上传菜品图片，后端接收MultipartFile并保存到本地磁盘，这是最常见的做法。但有两个坑：

第一，保存路径不要用相对路径。File.separator拼接的路径可能落在临时目录，重启进程后数据丢失。建议在application.yml里配置upload.path，指定一个固定的绝对路径或服务器下的/data/upload。

第二，前端访问图片的URL和后端静态资源映射要匹配。Spring Boot默认的静态资源目录是classpath:/static/，但你上传的图片在磁盘上，不在classpath里。所以需要添加资源映射：

java复制@Configuration
public class WebConfig implements WebMvcConfigurer {
    @Override
    public void addResourceHandlers(ResourceHandlerRegistry registry) {
        String uploadPath = "file:" + uploadDir + File.separator;
        registry.addResourceHandler("/upload/**").addResourceLocations(uploadPath);
    }
}

这样前端图片路径写http://ip:8080/upload/xxx.png才能正常显示。如果图片上传后立刻显示403，十有八九是资源映射没配。另外，小程序上传图片的域名同样有合法域名校验问题，开发者工具勾选不校验后一切正常，真机调试时需要注意。

6.4 微信登录失败的高频原因：code、appid、appsecret三件套

"微信登录失败"是调试阶段最常见的错误，原因一般出在三个地方：appid和小程序后台不匹配、AppSecret填错、code重复使用。

appid在app.js的wx.login之前可能还需要wx.getAccountInfoSync来获取，但后端jscode2session请求里的appid必须和前端小程序的appid一致，否则微信会返回40013错误码。
AppSecret在小程序后台的"开发→开发设置→开发管理"里查看，注意有时候后填的值要过几分钟才生效，改了不生效别急着怀疑代码。
code只能用一次，前端必须在wx.login()的success回调里立即把code发给后端。如果中间有异步操作延迟，可能再发就已经失效了。

遇到微信接口返回错误时，优先看返回的errcode和errmsg，微信官方文档有完整错误码表。最常见的40029是code无效，40163是code被使用过，40013是appid不匹配。定位思路按这个顺序排查，基本几分钟就能解决。

7. 说明文档与论文（LW）的写作红线：避免代码写完了却说不清

7.1 需求分析部分：别把"用户登录"写成流水账

很多同学的论文需求分析写得像功能列表，一条一条罗列"用户登录、用户注册、菜品浏览、加入购物车"，这其实是把用例当需求，层次太低。正确的写法是从角色出发，写业务流程。

比如用户角色下，不要写"用户可以浏览菜品"，而要写"用户进入首页后可以看到推荐菜品和热销榜，点击菜品进入详情页可查看价格、描述和库存信息，选择数量后加入购物车。购物车中用户可以勾选菜品、修改数量、删除菜品，点击结算进入订单确认页，确认后提交订单并完成模拟支付"。这样写的核心变化是：用动词描述用户与系统的交互过程，而不是罗列名词。

需求分析里还要包含业务流程图和数据流图。业务流程图建议用简单的箭头加文字画出来，从用户打开小程序到订单完成的完整流程；数据流图画出外部实体（用户、管理员）、数据存储（订单、菜品）、数据流箭头之间的逻辑关系。这两张图画好，评审老师会觉得你系统思维过关。

7.2 系统设计部分：ER图、用例图、功能结构图怎么画才像样

系统设计部分是论文的专业性担当。至少要包含三张图：

ER图：画出用户、菜品、分类、购物车、订单、订单明细之间的关系。注意关系的基数：用户和购物车是1对多，订单和明细是1对多，菜品和分类是多对1。ER图画好之后，数据库设计的文字说明要逐表解释每个字段的含义，特别是openid为什么加唯一索引、order_item为什么存dish_name快照这些设计理由，而不是只抄字段类型。
用例图：画出用户和管理员两个角色，各自能做什么。用例图不追求全，但要能体现系统边界，比如用户有浏览菜品、管理购物车、下单、查看订单等用例，管理员有菜品管理、订单管理、数据查看等用例。
功能结构图：用树形结构展示整个系统的功能模块划分，前端页面和后端接口要能对应上。

流程图方面，至少画两张：登录流程图和下单流程图。登录流程图要画出wx.login、code2session、用户是否存在、注册或登录、返回token的完整分支；下单流程图要画出购物车、创建订单、扣库存、模拟支付、状态流转的完整链路。

7.3 核心功能实现部分：讲什么才能体现工作量

核心功能实现章节切忌照抄代码。要挑三到四个最能体现系统特点的功能，讲清楚"思路→关键代码→运行效果"。

我建议重点写这几个模块：微信登录（体现对第三方接口的理解）、购物车与下单事务（体现业务逻辑和事务处理能力）、订单状态流转（体现对业务状态的理解）、智能推荐接口（体现设计思考）。每个功能写3到4页，讲清楚核心代码片段的作用，不需要把完整源码贴进论文，但截取关键方法并逐行解释，能极大提升论文的技术深度。

配图方面，至少要放系统截图：首页、菜品列表、菜品详情、购物车、订单确认、订单列表、管理员菜品管理、管理员订单管理、管理员数据看板，每个功能节点都要有对应截图。截图要清晰，业务数据要真实，不要用test、123这类明显假数据，否则老师看一眼就觉得是糊弄。

7.4 答辩高频问题与应对思路

最后把答辩环节老师最爱问的问题列一下，提前准备：

"为什么用Spring Boot？" 答：Spring Boot简化了Spring的配置，内置Tomcat，快速构建独立运行的微服务应用；生态成熟，和MyBatis-Plus、JWT等组件集成方便。重点是说出"自动配置"和"约定优于配置"这两个关键词。
"前端为什么不用Vue？" 答：业务场景是微信生态内的校园点餐，小程序触达用户更方便，无需下载App，扫码即用；小程序原生框架轻量、调试方便，符合校内场景的轻量化需求。
"订单状态是怎么管理的？" 答：设计五态状态机，每个状态变更由后端接口触发，通过枚举或常量统一管理，避免状态码散落在业务代码里。能画出状态图就画。
"'智能'体现在哪里？" 答：推荐模块基于用户历史订单的分类偏好，综合菜品销量做个性化推荐；管理端有销量榜和订单趋势看板，帮助商家做运营决策。要强调这不是挂个AI名字，而是有数据支撑的可解释逻辑。
"购物车为什么不用Redis？" 答：当前业务规模下MySQL足够；Redis作为分布式缓存适合高并发场景，属于系统后期可扩展方向。这个回答既承认现状又展示思考深度。

准备这些问题的核心是真实理解代码，而不是背答案。任何项目，只要你把每个接口从Controller到Service到Mapper完整走过一遍，答辩时就不会慌乱。

最后再分享一个建议

我真的建议大家拿到任何一套完整源码之后，第一件事不是双击运行，而是先花两天把代码结构完整看一遍：从pom.xml里有哪些依赖，到application.yml里配置了什么，再到Controller层暴露了哪些接口，Service层处理了什么业务逻辑，Mapper层操作了哪些表。这个过程相当于把系统的骨架在脑子里重建一遍。

然后选一个最简单的接口，试着改一个字段，比如改一下菜品列表的排序规则，跑通了再改复杂一点的功能，比如给订单加一个备注字段，从前端页面到后端接口再到数据库全链路改一遍。做完这几步，整个项目在你手里才是"活"的。答辩时老师问什么你都能从容应对，因为这已经不是别人写的项目，而是你亲手调过、改过、理解过的东西。

基于Spring Boot和微信小程序的智能校园点餐系统设计