企业官网建设流程全解析

1. 项目概述与目标定位

1.1 这个项目到底解决什么问题

先说结论：这是一个面向高校毕业设计场景的完整全栈项目，技术栈是 Spring Boot 3.x + 微信小程序原生前端，业务场景是超市购物的线上化闭环。你拿到的这套“超市购物系统54392”，本质上是一套开箱即用的毕设源码，包含小程序端（用户购物）+ 管理后台（运营管理）两个核心主体。

为什么这个选题在毕设里这么常见？因为它踩中了几个关键点：业务链路完整（商品浏览 → 购物车 → 下单 → 支付 → 订单管理 → 后台数据统计）、技术覆盖面广（后端框架 + 前端小程序 + 数据库设计 + 接口联调）、需求文档好写（超市购物是所有人都熟悉的场景，不需要答辩时花大量篇幅解释业务背景）。用大白话说，这套东西既能展示你的后端功底，又能展示前端交互能力，工作量适中，难度可控，非常适合本科毕设的时间节奏。

从源码结构来看，项目采用前后端分离架构。后端是典型的 Spring Boot 分层结构（controller / service / mapper / entity），数据库用的是 MySQL + MyBatis-Plus，权限控制依赖 Spring Security 或拦截器方案（具体看版本，54392这个编号对应的版本通常带完整的登录鉴权），前端小程序端使用的是原生微信小程序框架（WXML + WXSS + JS），没有引入 uni-app 之类的跨端框架，好处是运行更轻量、排查问题更直接，坏处是你得同时熟悉小程序生命周期和后端接口设计。

1.2 这套系统的适用人群与前置要求

如果你是准备拿它直接交毕设或作为课程设计，我把话挑明：这套源码不是给你“背代码”的，而是给你“讲代码”的。答辩时老师最常问的三句话是：“为什么用 Spring Boot？”、“购物车怎么设计的？”、“订单状态怎么流转的？”。你光能跑起来没用，得能解释清楚每个模块的设计意图。

所以我的建议是，拿到源码后按以下顺序做三件事：第一，把项目跑起来，前后端联调一遍，确认所有接口都通；第二，把数据库表结构画出来，搞清楚每张表的关联关系，这是你答辩时画系统架构图的基础；第三，把核心业务代码（购物车逻辑、订单生成逻辑、微信登录逻辑）逐行读一遍，标出关键代码片段，准备成“亮点展示”。

前置要求方面，你需要具备以下基础，缺一补一：

• Java 基础：至少能看懂注解、泛型、Lambda 表达式，能定位编译错误
• Spring Boot 基础：了解 IoC、AOP、自动配置的核心思想，这不是背概念，是要能说清楚“一个请求进来之后经过哪些组件处理”
• MySQL 基础：能写连表查询，知道事务的 ACID 特性，遇到过死锁更好（没遇到过也没关系，项目里有现成的例子可以学）
• 微信小程序基础：知道 page 和 component 的区别，会配置 app.json，能处理好 setData 的异步问题
• HTTP 与 JSON：理解 RESTful 接口设计，会看 Network 面板的请求报文

如果你现在是“Java 语法会但 Spring Boot 没跑过完整项目”的状态，我建议你先花三天时间补一遍 Spring Boot 的自动配置和 starter 机制，不然你会陷入“能跑但不敢改”的尴尬境地。项目要改，你得先懂它的骨架。

2. 微信小程序端设计与核心逻辑

2.1 小程序的项目结构与页面划分

打开小程序端的目录结构，你会看到典型的原生小程序骨架。pages 目录下按业务模块划分，通常包含首页、分类、购物车、个人中心、订单列表、商品详情、结算页等主要页面。每个页面都由 .js、.wxml、.wxss、.json 四个文件组成，这是原生小程序的固定套路。

先看首页。首页的核心功能是商品展示和搜索入口，一般包含顶部搜索框、轮播图、金刚区分类导航、推荐商品列表这几个模块。我在读源码时特别注意了一个细节：轮播图的图片路径是存在数据库里的，也就是说后台可以动态替换轮播内容，而不是写死在小程序代码里。这个设计很聪明，既减少了发版频次，又能让运营同学自配置活动内容。这里涉及的核心逻辑是首页在 onLoad 生命周期中调用后端 /api/home/banners 接口，拿到图片 URL 列表后 setData 到 data 对象，wxml 里用 swiper 组件渲染。

分类页面用的是左右联动的经典布局：左侧是一级分类导航栏，右侧是对应分类下的商品列表。实现方式是 scroll-view 组件配合滚动事件监听，左侧选中状态通过 data 中的 activeIndex 控制，右侧滚动到不同区域时反向更新左侧选中状态。如果你在答辩时能把这个双向联动的实现细节讲清楚，会是一个亮点。

购物车页面是整个小程序端业务逻辑最重的页面，因为它涉及到本地存储和状态同步两个问题。好的实现方案是：购物车数据在小程序本地用 Storage 缓存一份，同时每次变更时同步到后端；启动页面时先从后端拉取最新购物车数据合并到本地。这样做的好处是弱网环境下用户依然可以打开购物车查看选中的商品，不至于因为网络波动清空用户的真实操作。我在项目里见过不少同学把购物车数据只放在后端，导致小程序一断网整个购物车页面白屏，这种体验在答辩演示时如果恰好网络出问题，会非常尴尬。

2.2 微信登录与 token 管理的实现要点

微信小程序的登录流程是每个毕设答辩必问的点。整个流程说起来不复杂，但很多人实现得有问题。标准流程是：小程序端 wx.login 获取临时 code → 将 code 传给后端 → 后端调用微信接口的 jscode2session 换取 openid 和 session_key → 后端用 openid 作为用户唯一标识在数据库里建用户记录 → 生成自定义登录态 token 返回给小程序端 → 小程序端把 token 存入 Storage，后续所有请求都在 header 里带上 token。

这里有几个容易踩的坑。第一，code 是一次性的，有效期只有五分钟，而且只能用一次，所以你必须在用户点击“微信登录”按钮的这个动作里同步完成“获取 code → 传给后端 → 后端换取 openid → 返回 token”整条链路，不能把 code 存起来分步用。第二，微信接口的请求需要用到小程序的 appid 和 secret，这两个配置项必须放在后端的配置文件里，绝对不能写在小程序代码中，否则反编译小程序就能拿到你的密钥，这在毕设查重和安全审查中是大忌。第三，token 不要用明文，建议用 JWT 或者 UUID+Redis 缓存的方式，设置合理的过期时间，通常七天内有效即可。

拿到源码后你要做的第一件事是检查后端有没有一个 wechat 相关的 controller，比如 /api/wx/login，然后看它内部如何拼接请求 URL 调用微信的 jscode2session 接口。理解了这个接口的调用链路，你就能应对答辩现场关于“第三方登录原理”的所有提问。

2.3 setData 渲染性能与页面交互优化

看小程序代码的时候，我重点检查了 setData 的使用方式。很多新手写小程序会犯一个通病：不管数据大小，一骨脑全部 setData。比如商品列表接口返回了 50 个商品，每个商品有 20 个字段，但页面上只用到 5 个字段，如果数据模型不精简、不裁剪，照样全量塞进 setData，渲染性能就会有可见的拖慢。

灵活的做法是，在拿到后端数据后做一个字段映射，只把页面需要用到的字段提取出来再 setData。以下是小程序端的典型写法：

const rawList = res.data.list || []; const displayList = rawList.map(item => ({ id: item.id, name: item.name, price: (item.price / 100).toFixed(2), // 后端如果是分单位，前端转元 imageUrl: item.imageUrl, stock: item.stock, sales: item.sales })); this.setData({ displayList });

这样处理之后，页面数据体积通常能压缩到原来的三分之一左右，滚动渲染的卡顿感会明显减轻。另一个优化点是分页加载。首页和分类页的商品列表绝对不能一次性拉全量数据，标准做法是后端接口接收 pageNum 和 pageSize 参数，小程序端通过 onReachBottom 触底加载下一页，用 isLoading 标志位防止重复请求。我在读这套源码时确认了它是按这个套路实现的，这点值得肯定。

还有一个小技巧：费用相关金额字段在小程序端的展示，尽量不要直接渲染后端返回的原始数字，而是在 JS 层统一做一次格式化。这样后续如果后端字段从“分”改成“元”，你只需要改动格式化函数一处，而不是在小程序的每一个页面里去翻代码。

3. Spring Boot 后端架构与核心服务实现

3.1 分层结构与核心依赖梳理

后端工程的包结构一般长这样：controller 放接口入口，service 放业务逻辑，mapper 放数据库操作，entity 放实体类，config 放配置类，common 放统一返回和异常处理。这套分层方案是 Spring Boot 项目的教科书式模板，优点是职责清晰、扩展性好，缺点是如果业务简单，会有“为了分层而分层”的冗余感。但对于毕设来说，这种冗余恰恰是加分项，因为评委看到清晰的包结构，第一印象就是“这个学生有工程化意识”。

核心依赖方面，我看到这套源码用了 MyBatis-Plus。这玩意儿对于写毕设的人非常友好，因为内置了强大的 CRUD 接口，你不需要手写大量的基础 SQL。比如你定义一个 UserMapper 继承 BaseMapper<User>，就能直接用 selectById、selectList、insert 这些内置方法。但对答辩来说，我建议你重点准备一两个手写 SQL 的 Mapper 方法，比如订单详情连表查询、商品销量统计、用户消费排行，这些是你“有数据库功底”的直接证据，比单纯说“我用了 MyBatis-Plus 所以省事多了”更让老师信服。

数据库连接池用的应该是 Druid 或 HikariCP，配置里有连接超时、最大连接数这些参数。这四个参数值得你关注：最大活跃连接数、最小空闲连接数、连接最大存活时间、获取连接超时时间。一旦项目在并发测试中报连接池超时或者连接泄漏，你能快速定位到是哪个参数配得有问题。

3.2 购物车模块的数据库设计与事务控制

购物车模块在数据库层面通常有两种设计方式：一种是不建表，直接在小程序端 Storage 里维护购物车数据，简单但没法跨设备同步；另一种是建购物车表，把用户和商品关联关系完整记录下来。毕业设计建议用第二种，因为评级时能体现你对数据模型的规划能力。

购物车表通常包含这些字段：id、user_id（外键关联用户表）、product_id（外键关联商品表）、quantity（数量）、checked（是否选中）、create_time、update_time。你可能觉得 checked 字段多余——购物车商品是否选中不就是前端状态吗？为什么要存数据库？这个问题值得你多想想。答案是，当用户在多端操作（手机 + 平板 + 模拟器）时，前端状态无法同步，存后端可以在任何一端恢复“上次勾选”的精确状态。涉及购物车表数据变更的三个操作——加入购物车、修改数量、删除商品，都必须放在事务里执行，否则会出现数据不一致。

我在源码里注意到，购物车加入接口的 service 层逻辑大概是：先查询当前用户购物车中是否已存在该商品，如果存在则做数量累加，如果不存在则新建一条记录。这逻辑简单，但有一点容易被忽略：如果用户连续快速点击“加入购物车”按钮，前端发起了多个并发请求，就可能在“查询是否已存在”这一步同时通过，然后在“插入”时插入两条相同记录。高并发场景下必须用数据库唯一索引兜底，或者利用 Redis 分布式锁保证幂等。毕设答辩能主动说出这个并发问题以及你的解决方案，是一个非常加分的环节。

3.3 订单状态机设计与事务边界

订单是超市购物系统里最核心的业务模块，它的状态流转设计决定了整个系统的健壮程度。一套完整的订单状态机至少要包含以下状态：待支付、已支付、待发货（如果是实体商品）、已发货、已完成、已取消。每个状态之间的流转触发条件要清晰：待支付 → 已支付是由支付回调触发的；已支付 → 待发货在实体商品场景中是由用户点击“确认订单”或系统自动触发的；如果设定超时未支付自动取消，那还需要一个定时任务扫描超时订单。

阅读源码时你会发现订单表 design 上一定有几个关键索引：订单号索引（业务上全局唯一，通常用时间戳 + 用户ID + 随机数生成，也可以直接用雪花算法）、用户ID索引（查询“我的订单”时避免全表扫描）、状态索引（后台运营按状态过滤订单）。

订单生成是整个系统里事务性最强的逻辑，通常会包在一个 @Transactional 注解中，涉及的操作包括：创建订单主记录、创建订单商品子记录、扣减商品库存、清空购物车对应商品。这里有一个典型的“并发扣库存”问题，如果多个用户同时下单购买同一件商品，数据库的行锁能保证扣减操作的原子性，但你要注意扣减 SQL 的写法。正确的写法是带条件的 UPDATE：

UPDATE product SET stock = stock - #{quantity} WHERE id = #{productId} AND stock >= #{quantity}

这条 SQL 的含义是“只有当库存充足时才扣减，并且一次扣减操作是原子性的”。执行后返回受影响行数为 0，说明库存不足，就直接抛异常提示“库存不足”。如果你先 SELECT 查库存，再 UPDATE 扣减，中间这块时间窗口就会产生超卖问题。这个知识点是订单模块答辩时的核心考点，建议你对着源码把这里读透。

3.4 微信支付集成与回调处理

微信支付是小程序购物系统中比较吸睛的功能模块，但不是所有毕设都会完整实现。如果你的选题定了这个项目，我强烈建议你至少要“打通”这一环，因为这是答辩时最能展示真实项目经验的点。实现微信支付需要的核心参数是：小程序 appid、商户号 mchid、商户 API 密钥。后端统一下单接口返回支付参数后，小程序端调用 wx.requestPayment 唤起收银台，用户完成支付后微信服务器会异步通知你的回调接口，你必须正确处理这个回调并返回成功应答。

微信支付的回调里有一个最常见的坑：微信服务器会重试多次通知，如果你的回调处理逻辑不是“幂等”的，同一个订单就可能被重复修改状态。正确做法是在回调处理函数的开头先判断订单当前状态，如果已经是“已支付”就直接返回成功，不再重复执行业务逻辑。另一个坑是回调验签，你必须在拿到微信返回的通知报文后，先做签名验证，确认这是微信服务器发的，再处理业务逻辑，否则任何人都能伪造回调通知刷订单状态。

我在源码中注意到，它的支付模块未必包含完整的微信支付接入，因为沙箱环境和真实支付需要商户号，很多毕设版本会做成“模拟支付”——一键点击即认为支付成功并把订单状态改为已支付。这个降级方案可以理解，但你要在论文中明确说明，不要试图用模拟支付直接冒充微信支付，答辩被追问“支付回调在哪”的时候会很难圆场。

4. 数据库设计与接口文档整理

4.1 核心表结构与关联关系梳理

不管做没做过毕设，数据库设计这件事永远值得花时间精雕细琢。这套超市购物系统的核心表，我大致数了数，至少包含这些：用户表、商品分类表、商品表、购物车表、订单表、订单商品明细表、收货地址表、轮播图表等。简单画一下关系：用户表 1 对 N 购物车表，用户表 1 对 N 订单表，订单表 1 对 N 订单商品明细表，商品分类表 1 对 N 商品表。

我特别提醒一下商品表的设计。商品表里除了常规的 name、price、image_url、description 这些字段，建议再加上 sales（销量）、stock（库存）、status（上下架状态）、sort_order（权重排序）这几个字段。sales 字段虽然在下单时会有实时统计，但单独冗余一个字段存销量快照，可以在商品列表接口直接排序，而不需要每次都实时去订单表做聚合统计，性能会明显更好。这是一个典型的空间换时间的取舍，答辩时讲出来就是加分项。

订单表和订单商品明细表为什么要分开？很多初学数据库的同学会把订单里每一个商品直接作为一行存到订单表里，导致同一个订单的多个商品被拆成多行记录，又难以表达订单整体的收货地址、总金额、状态信息。正确的做法是把订单的公共信息抽到订单主表，把每个商品的购买信息放到明细表，主表和明细表通过 order_id 关联。这个设计的本质是数据库范式化的体现，也是零售系统里非常成熟的数据模型，直接沿用就好。

以下是核心表的一个概览示例，你可以对照源码中的建表 SQL 核查：

4.2 RESTful 接口设计与统一返回结构

前后端分离项目里，接口协议是否规范，直接影响联调效率和代码可维护性。这套系统的接口风格整体上是 RESTful 的，资源用名词复数表示，动作通过 HTTP 方法区分。例如：GET /api/products 查询商品列表、GET /api/products/{id} 查询商品详情、POST /api/orders 创建订单、PUT /api/orders/{id}/cancel 取消订单。有一点需要在答辩前想清楚，就是 GET /api/orders 和 PUT /api/orders/{id}/cancel 里的 cancel 动作并不严格符合纯 REST 规范（因为 cancel 不是一个资源），更规范的做法是 POST /api/orders/{id}/cancel。但实际项目里这种“RESTful 风格 + 动作路径”的混合写法非常常见，答辩时如果老师提出这个问题，你只要能解释清楚“动作型资源也是一种工程化取舍”，就不会有问题。

统一的异步返回结构也是评审老师比较关注的一个细节。规范的响应体应该包含 code、message、data 三个字段，例如：

{ "code": 200, "message": "请求成功", "data": { ... } }

这样设计的好处是：前端可以统一拦截 code 非 200 的情况做错误弹窗，后端可以统一处理业务异常并返回友好的错误信息。很多新手项目会直接返回 JSONObject 或者裸数据，导致前端每个接口都要单独写错误处理逻辑，代码冗余且容易遗漏。阅读源码时，你可以看看 common 包下是否有一个 Result 或者 ApiResponse 的统一包装类，如果有，这个设计可以直接写进你的论文“系统设计”章节。

4.3 后端启动配置与多环境切换

后端要跑起来，重点要看 application.yml 或 application.properties 里的配置。我建议你在本地开发时把环境切换到 dev，配置本地数据库连接、本地 Redis，日志级别调到 DEBUG，方便排查问题；正式部署（比如答辩演示）用 prod 配置，关闭不必要的日志输出。Spring Boot 多环境配置的惯例是拆成 application-dev.yml 和 application-prod.yml，主配置文件里用 spring.profiles.active 指定当前激活的环境。你拿到源码后，如果只有一份 application.yml，我建议你顺手拆一下。这个小动作在答辩时能额外展示你对工程化部署的理解。

另一个必须注意的配置是微信小程序相关的 appid、secret、商户号。源码里通常留了占位符，你需要替换成自己在微信公众平台申请的测试号或正式号信息。这里有个细节：secret 属于敏感配置，本地开发时写在 yml 里问题不大，但不要把这个文件提交到公开的 GitHub 仓库。答辩前全局搜索一下源码里有没有硬编码的密钥字符串，有就赶紧改成占位符，安全审查和重复率检查都过不了这一关。

5. 项目启动、联调与部署经验总结

5.1 数据库初始化与后端启动完整流程

项目拿到手，先把数据库跑起来。第一步，在 MySQL 中创建数据库，字符集选 utf8mb4，别图省事选 utf8，因为你无法预知商品描述和用户昵称里会不会出现 emoji 字符，utf8mb4 是唯一稳妥的选择。第二步，用数据库客户端或者命令行执行项目提供的 sql 脚本。重点关注两个点：脚本里有没有初始化管理员账号的数据，以及有没有自动注册表的初始化数据。如果脚本执行报错，常见原因是 SQL 版本兼容问题，比如用了 MySQL 8 的窗口函数，而你的本地 MySQL 是 5.7，那就要升级到 8.x 再执行。

后端启动前要确认 Java 版本。Spring Boot 3.x 要求 JDK 17 以上，如果你的源码是 Spring Boot 3.3 或更高，本地必须装 JDK 17 或 21。这里有个非常现实的坑：很多同学的机器上装的是 JDK 8，直接跑 Spring Boot 3 项目会报 UnsupportedClassVersionError，一搜才发现是 JDK 版本问题。如果你打算做毕设，现在就开始用 JDK 17，实在不行就在 IDE 里给这个项目单独配一个 JDK 17 的 SDK。

确认完 JDK 和数据库，直接在 IDE 里启动 Spring Boot 的启动类。看到日志里出现 “Started Application in xx seconds”，说明后端已经跑起来了。此时用浏览器或 Postman 访问一下健康检查接口或某个 GET 接口，能拿到 JSON 响应就说明接口层正常。

5.2 微信开发者工具导入小程序端

小程序端要跑起来，需要微信开发者工具。安装后打开，选择“导入项目”，填上小程序项目的根目录，AppID 使用测试号（如果你没有正式注册小程序）或你自己的 AppID。这里提醒一下：如果后端配置里的 appid 和开发者工具里的 AppID 不一致，登录接口会报错，所以要么两边都用测试号，要么都用同一个正式号，不要混着来。

编译完成后点开模拟器首页，如果接口正常联通，商品列表应该能加载出来。如果页面一直转圈加载不出来，打开开发者工具的 Network 面板，看看请求的域名和端口是不是正确配置了。本地联调时有个经典问题：微信开发者工具要求后端接口域名必须在“合法域名”列表中，但开发模式下可以在“详情 → 本地设置”里勾选“不校验合法域名、web-view（业务域名）、TLS 版本以及 HTTPS 证书”。这一步不勾选，本地 http://localhost:8080 是访问不通的。

这个“不校验合法域名”的选项通常已经默认开启，但如果你把项目分享给同学，对方那台电脑上可能没开，所以遇到接口连不通，第一个排查方向就是这个配置，而不是急着改代码。

5.3 联调阶段常见问题排查

联调阶段是毕设开发过程中最耗时、最容易让人崩溃的阶段。先讲一个最高频的问题：跨域。小程序端不是浏览器环境，没有浏览器同源策略的限制，所以一般不会出现跨域报错。但如果你之后想做一个 Web 管理后台（很多同学会在毕设里加一个管理后台给运营用），那跨域就是必答题。后端用 Spring Boot 解决跨域最简单的方式是加一个 WebMvcConfigurer 配置类：

@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowedHeaders("*") .allowCredentials(true) .maxAge(3600); } }

第二个高频问题是时间格式。前后端传输时间字段时，最标准的格式是字符串类型的 ISO 8601，例如“2024-06-01 12:00:00”。如果后端返回的是时间戳数字，前端渲染时要自己转换，非常容易出错。Spring Boot 里可以通过在 application.yml 中配置 spring.jackson.date-format 和 time-zone 来统一时间格式。

第三个问题是金额精度。千万要记住：涉及钱的数据不要用 double 或 float，数据库字段用 decimal，后端实体用 BigDecimal，前端渲染时再转成字符串。如果数据库字段用了 float，计算总价、退款等场景就会出现 0.1 + 0.2 不等于 0.3 的诡异问题。这是做电商类项目的铁律，答辩时你能主动说出这条经验，老师会觉得你有真实项目历练。

5.4 部署上线方案与答辩演示技巧

毕设最后要演示，你有两种方案：本地演示和服务器部署演示。我的建议是，尽量提前在云服务器上部署一套，演示时打开浏览器和微信开发者工具直接操作，不要临时抱佛脚在答辩现场现启动项目。本地演示的问题在于，一旦网络会议或投影环境出现兼容问题，你会在台上手忙脚乱。

服务器部署的核心步骤是：把后端打包成 jar 包，使用mvn clean package -DskipTests命令构建；把 jar 包上传到服务器，运行nohup java -jar app.jar > app.log 2>&1 &启动；MySQL 和 Redis 也装到服务器上，注意防火墙要放行对应端口。小程序端发布的话需要把接口域名换成线上域名，并在微信公众平台的“服务器域名”配置里加入这个域名，HTTPS 证书是必须的，可以用免费的证书解决。

答辩演示时有个小技巧：把“红包雨”“秒杀”这类需要高并发的场景放在最后演示，因为一旦触发了性能瓶颈，前面流畅的印象会被打破。先演示核心链路——搜索商品、加购、下单、支付成功，再演示订单管理、后台数据统计，时间卡得刚刚好。如果现场网络状况不佳，提前准备好截图或者录屏作为兜底方案，这是我从多次答辩评审经历里总结出来的血泪经验。

6. 常见问题与排查技巧实录

• JDK 版本不匹配：Spring Boot 3.x 必须 JDK 17+。如果启动报 UnsupportedClassVersionError，先查java -version，然后到 IDE 项目结构里把 SDK 切到 17 或 21。
• 数据库连接失败：报 Communications link failure 通常是连接串写错或 MySQL 没启动。先把 localhost、端口、库名、用户名、密码逐项核对，再 telnet 一下 3306 端口通不通。
• 中文乱码：接口返回中文乱码，八成是数据库连接串没加characterEncoding=utf8和useSSL=false，或者是响应头没指定 UTF-8。加好后重启就好。
• 小程序登录后 token 失效：token 放在 Storage 里，但每次小程序冷启动时你没有先去校验 token 有效性，而是直接请求业务接口，后端发现 token 过期就返回 401。应在 app.js onLaunch 中先调用校验接口，过期就重新走登录流程。
• 商品列表接口 500：先看控制台异常堆栈。大量情况是 SQL 语句里的表名或者字段名跟数据库不一致，或者 MyBatis-Plus 的实体类映射错了。
• npm install 失败或依赖冲突：检查 Maven 仓库配置，国内建议用阿里云镜像，pom 里不要混用多个版本的同一依赖，统一用父工程管理的版本。
• 管理后台端口冲突：如果本地 8080 被占用，直接改 server.port，或者用lsof -i:8080先看哪个进程占着端口，顺手杀掉。
• 真机预览连不上本地后端：手机和电脑必须在同一局域网内，且后端的 server.port 要监听 0.0.0.0 而不是 127.0.0.1。如果还不行，查一下电脑防火墙有没有拦端口。项目里配置的 localhost 也要改成电脑的局域网 IP，别在代码里写死 127.0.0.1。
• 微信支付回调验签失败：多半是密钥填错或签名算法不一致。先把微信支付官方 SDK 的版本对齐，再贴出原始报文调试，不要自己去造加解密逻辑。

7. 个人实操体会与后续扩展建议

这套超市购物系统源码，如果只是拿来跑通演示，三天就够了；但如果你想用它拿一个不错的答辩成绩，我建议至少预留一周时间把核心模块读透、改透、讲透。动手之前先通读数据库 SQL 脚本，把每一张表的字段含义列个清单；再按“登录 → 浏览 → 加购 → 下单 → 支付 → 订单管理 → 后台统计”这条主链路把代码走一遍，每到一个关键点就在代码里加注释，写清楚“这个接口做了什么、为什么这么做”。这些注释既是你的阅读笔记，也可以直接变成论文里的核心代码展示。

我个人在实际操作中的体会是，这套项目最大的价值不在于代码本身多高级，而在于它把一套完整电商业务的链条串起来了。你只要顺着业务主线理解一遍，Spring Boot、小程序、MySQL、接口设计、状态机、事务、缓存这些知识点都能在真实场景中找到对应落点，而不是停留在背八股文的层面。

后续如果你想扩展这个项目，我有四个方向供你参考：第一，接入 Redis 做缓存，把首页轮播、商品分类、热门商品这些热点数据缓存起来，降低数据库压力，这是性价比最高、也最容易写出亮点的一个改造；第二，加一个后台数据看板，展示销售额趋势、分类销售占比、用户增长曲线，用 ECharts 画图表，这些数据可视化对答辩呈现特别加分；第三，把商品搜索升级成 Elasticsearch 或利用 MySQL 全文索引，做成带推荐排序的搜索，能显著提升系统的“高级感”；第四，给订单模块加一个超时自动取消的定时任务，用 Spring Schedule 或者 xxl-job，把“待支付订单 30 分钟未支付自动关闭”这个真实业务规则落进去。

最后分享一个小技巧：在答辩演示之前，一定要自己在模拟器和真机上完整走三遍购物流程，别多别少，就三遍。第一遍验证主流程通畅，第二遍确认边界场景（比如库存为 0 的商品、未选购物车商品去结算、重复提交订单），第三遍用来查漏补缺。小程序端在模拟器上的运行环境和真机是有差异的，我在真机上遇到过模拟器完全没有问题、一上真机就白屏的情况，原因是一个接口的证书链在真机上校验失败。提前排查好，别给答辩留任何“意外惊喜”。