简介这份资源是面向微信小程序初学者与电商开发入门者的在线点餐系统源码基于微信小程序开发框架并结合Java后端服务帮助读者理解从菜品展示、购物车到订单确认与微信支付的完整餐饮业务链路。压缩包共60个文件约1.18MB以js逻辑文件、json配置、wxss样式与wxml页面结构为主另有jpg、png图片素材及一份md说明文档覆盖前端页面、业务逻辑与配置等核心模块。目前已有1148人学习下载热度较为可观。读者可通过分析页面组件、JS交互逻辑、后端接口设计与数据库结构掌握小程序开发环境搭建、WXML与WXSS语法、常用API调用、RESTful接口设计及微信支付集成等关键知识点并借助Git进行版本管理与项目部署实践。源码结构清晰适合对照修改与二次开发是学习微信商城与在线点餐系统运作机制的实用参考。1. 微信小程序点餐系统源码从「能跑」到「能用」差了什么打开 GitHub 或者 Gitee 搜「微信小程序点餐系统源码」能翻出几百个仓库Java 后端的、Node 的、PHP 的都有。但真正拿下来部署到自己服务器上能撑住一个午高峰的十个里面未必有一个。问题不在代码写得多烂而在于大部分源码只解决了「功能有没有」的问题没解决「并发扛不扛得住」「订单状态会不会乱」「支付回调丢了怎么办」这些真正要命的事。这篇笔记面向的是手里已经有一份微信小程序商城源码、或者正准备选一套在线点餐源码的开发者。我会按 Java 后端 微信小程序前端的典型架构把从环境搭建、核心接口设计、订单状态机、支付回调处理到部署上线的完整路径拆开讲。每一步都给出可复现的代码和参数同时标出我踩过的坑。读完你应该能判断手里那份源码值不值得改以及怎么改才能上线接客。2. 拿到源码先别急着跑Java 后端 小程序前端的架构拆解2.1 一套点餐系统到底有哪几个进程常见的微信小程序点餐系统源码不管仓库描述写得多花哨拆开来看基本是这几个部分模块典型技术栈职责小程序前端原生小程序 / uni-app菜单展示、购物车、下单、支付、订单查询后端 APISpring Boot MyBatis-Plus菜品管理、订单、支付、用户、桌台管理后台Vue Element UI菜品上下架、订单管理、营业统计数据库MySQL 5.7 / 8.0业务数据持久化缓存Redis购物车、库存扣减、分布式锁支付微信支付 V3下单、回调、退款如果你拿到的源码只有小程序端和一个简单的 Java 单体没有 Redis 也没有管理后台那它大概率是个课程设计级别的项目。用来学习可以上线接单需要补的东西不少。先确认几件事后端是不是 Spring BootJDK 版本是多少数据库脚本在哪小程序端的appid和request域名配置在哪。这些信息决定了你后面要改多少东西。2.2 本地跑通后端的最小命令集假设你拿到的是一套标准的 Spring Boot MySQL 项目目录结构大概是order-server/ src/main/java/com/xxx/ controller/ service/ mapper/ entity/ src/main/resources/ application.yml mapper/ sql/init.sql第一步不是打开 IDE而是先把数据库建起来。很多源码的init.sql里没有建库语句直接跑会报Unknown database。# 登录 MySQL创建数据库字符集必须是 utf8mb4 mysql -u root -pCREATE DATABASE order_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE order_db; SOURCE /path/to/sql/init.sql;字符集这里别用utf8微信昵称里的 emoji 会直接导致插入失败报Incorrect string value。这是血泪经验上线后才发现的话改表结构很麻烦。然后是application.yml里必须改的几个参数spring: datasource: url: jdbc:mysql://127.0.0.1:3306/order_db?useUnicodetruecharacterEncodingutf8mb4serverTimezoneAsia/Shanghai username: root password: 你的密码 redis: host: 127.0.0.1 port: 6379 database: 0 wx: appid: 你的小程序appid secret: 你的小程序secret mch-id: 微信支付商户号 api-v3-key: 支付V3密钥serverTimezone必须显式指定否则 MySQL 8.0 驱动会报时区错误。characterEncoding写utf8mb4而不是utf8和建库时保持一致。启动命令# 确保 JDK 版本和 pom.xml 里一致常见是 JDK 8 或 JDK 17 java -version mvn clean package -DskipTests java -jar target/order-server-1.0.0.jar --spring.profiles.activedev如果启动报Table order_db.xxx doesnt exist说明init.sql没跑完或者跑到了别的库里。如果报Redis connection refused先把 Redis 起起来点餐系统的购物车和库存扣减基本都依赖 Redis没有它跑不起来。2.3 小程序端联调前必须改的三个配置小程序端拿到手直接编译大概率是白屏或者请求全部失败。打开app.js或者config.js找到这几个地方// config.js const config { baseUrl: http://localhost:8080/api, // 改成你后端实际地址 appId: wx1234567890abcdef, // 改成你自己的小程序 appid // ... }第一个坑微信开发者工具里请求localhost需要在「详情 → 本地设置」里勾选「不校验合法域名」。但真机预览时这个选项无效必须用内网穿透或者部署到有 HTTPS 的服务器上。第二个坑小程序请求域名必须是 HTTPS且不能带端口号除非是 443。开发阶段可以用内网穿透工具临时解决上线前必须配好备案域名和 SSL 证书。第三个坑appid和secret不匹配会导致code2session接口返回invalid appid。很多人从别人那里拿的源码appid没换登录一直失败查半天查不出来。3. 点餐核心链路从扫码到下单的 Java 接口怎么写3.1 购物车用 Redis Hash 还是 MySQL 临时表这是拿到源码后第一个要做的技术判断。很多课程设计级别的点餐系统购物车直接存 MySQL每次加减菜都写库。单桌测试没问题十桌同时点餐就开始锁表。常见做法是用 Redis Hashkey 是cart:{userId}或者cart:{tableId}field 是dishIdvalue 是数量。读写都在内存性能差一个数量级。Service public class CartService { Autowired private StringRedisTemplate redisTemplate; private static final String CART_KEY_PREFIX cart:; // 添加菜品到购物车 public void addDish(Long userId, Long dishId, Integer count) { String key CART_KEY_PREFIX userId; // hashIncrement 保证并发下数量不会丢 redisTemplate.opsForHash().increment(key, dishId.toString(), count); // 设置过期时间避免僵尸购物车占内存 redisTemplate.expire(key, 2, TimeUnit.HOURS); } // 获取购物车全部内容 public MapObject, Object getCart(Long userId) { String key CART_KEY_PREFIX userId; return redisTemplate.opsForHash().entries(key); } // 清空购物车下单成功后调用 public void clearCart(Long userId) { redisTemplate.delete(CART_KEY_PREFIX userId); } }increment是原子操作多个请求同时加同一道菜不会出现覆盖。过期时间设 2 小时覆盖一顿饭的时间就够了。如果用户中途换桌或者重新扫码购物车数据不会串。参数说明userId来自小程序登录后后端返回的 token 解析不要直接用微信openid当 keyopenid太长且可能变。count允许为负数实现减菜功能。3.2 下单接口的幂等和库存扣减下单是点餐系统最容易出问题的地方。用户手抖连点两次、网络超时重试、微信支付回调重复通知都会导致重复订单。必须做幂等。常见做法是前端生成一个clientOrderNo比如时间戳 随机数后端用它做唯一索引。插入时如果冲突就直接返回已有订单。RestController RequestMapping(/api/order) public class OrderController { Autowired private OrderService orderService; PostMapping(/create) public ResultOrderVO createOrder(RequestBody Valid OrderCreateDTO dto) { // dto 里必须带 clientOrderNo return orderService.createOrder(dto); } }Service public class OrderServiceImpl implements OrderService { Autowired private OrderMapper orderMapper; Autowired private StringRedisTemplate redisTemplate; Override Transactional(rollbackFor Exception.class) public ResultOrderVO createOrder(OrderCreateDTO dto) { // 1. 幂等检查clientOrderNo 唯一索引重复插入会抛异常 Order exist orderMapper.selectByClientOrderNo(dto.getClientOrderNo()); if (exist ! null) { return Result.success(convert(exist)); } // 2. 分布式锁锁住桌台防止同一桌并发下单 String lockKey lock:table: dto.getTableId(); Boolean locked redisTemplate.opsForValue() .setIfAbsent(lockKey, 1, 10, TimeUnit.SECONDS); if (Boolean.FALSE.equals(locked)) { return Result.fail(操作太快请稍后重试); } try { // 3. 从 Redis 购物车读取菜品校验库存 // 4. 扣减库存Redis decr 数据库乐观锁 // 5. 写入订单主表和明细表 // 6. 清空购物车 // 7. 返回订单信息前端拿 orderNo 去调支付 } finally { redisTemplate.delete(lockKey); } return Result.success(/* ... */); } }关键点clientOrderNo在数据库建唯一索引这是最后一道防线。分布式锁的过期时间设 10 秒足够完成一次下单但不能太长否则桌台被锁死。库存扣减用 Redisdecr做预扣数据库层面用update stock stock - 1 where stock 0做最终一致性。3.3 微信支付 V3 回调的验签和状态机支付回调是另一个翻车重灾区。微信支付 V3 的回调是加密的必须用 API V3 密钥解密然后验签。很多源码用的是 V2 的写法直接拿不到回调数据。RestController RequestMapping(/api/pay) public class PayCallbackController { Autowired private PayService payService; PostMapping(/notify) public String notify(RequestBody String body, RequestHeader(Wechatpay-Signature) String signature, RequestHeader(Wechatpay-Timestamp) String timestamp, RequestHeader(Wechatpay-Nonce) String nonce, RequestHeader(Wechatpay-Serial) String serial) { // 1. 验签用微信平台证书公钥 // 2. 解密 body 里的 resource.ciphertext // 3. 拿到 out_trade_no 和 trade_state // 4. 更新订单状态待支付 - 已支付 // 5. 返回 200否则微信会重复通知 return payService.handleNotify(body, signature, timestamp, nonce, serial); } }订单状态机必须严格待支付 → 已支付 → 制作中 → 已完成退款走已支付 → 退款中 → 已退款。每次状态变更都要记录操作日志否则出了问题查不到是谁改的。回调处理里最容易犯的错是解密后直接更新订单状态没有判断当前状态。如果微信重复通知订单已经「已完成」了又被改成「已支付」厨房就乱了。正确做法是加状态判断// 只有当前状态是「待支付」才更新 int rows orderMapper.updateStatus(orderNo, OrderStatus.PAID, OrderStatus.PENDING_PAY); if (rows 0) { // 说明已经被处理过了直接返回成功避免微信继续重试 return SUCCESS; }4. 部署上线前必须处理的五个坑4.1 坑一小程序请求域名没备案真机全部超时现象开发者工具里一切正常真机预览所有接口 404 或超时。原因微信小程序要求所有请求域名必须 ICP 备案且配置在「开发管理 → 服务器域名」里。localhost和 IP 地址在真机上无效。解决上线前准备好备案域名和 SSL 证书在微信公众平台配置request合法域名。开发阶段可以用内网穿透工具临时映射一个 HTTPS 地址但不要用于生产。4.2 坑二订单号重复导致插入失败现象高峰期偶尔报Duplicate entry xxx for key idx_order_no。原因订单号生成用了时间戳 随机数并发高时随机数碰撞。或者用了数据库自增但分库分表后不唯一。解决订单号用「日期 桌台号 序列号」或者雪花算法。如果源码里用的是System.currentTimeMillis()直接当订单号必须改。我一般用Redis INCR生成每日序列号拼上日期和桌台 ID既唯一又可读。4.3 坑三支付回调没收到订单一直待支付现象用户明明付了钱订单状态还是「待支付」厨房不出单。原因回调地址配错了或者服务器防火墙拦了微信的 POST 请求或者回调处理抛异常返回了非 200。解决先看微信支付商户平台的回调日志确认微信有没有发通知。如果发了但你没收到检查notify_url是不是公网可访问的 HTTPS 地址。如果收到了但处理失败看后端日志有没有解密或验签报错。最后加一个定时任务每 5 分钟查一次「待支付超过 10 分钟」的订单主动调微信查单接口补偿。4.4 坑四Redis 没设过期时间内存爆了现象运行几天后 Redis 内存告急新请求写入失败。原因购物车 key 没设 TTL或者设了但每次操作都重置 TTL导致僵尸购物车永远不过期。解决购物车 key 统一设 2 小时过期每次addDish时刷新过期时间。另外配置 Redis 的maxmemory-policy为allkeys-lru内存满时自动淘汰最久未使用的 key。4.5 坑五MySQL 连接池太小午高峰请求排队现象中午 12 点前后接口响应从 50ms 飙到 3s日志里出现Connection is not available。原因HikariCP 默认最大连接数是 10点餐系统并发稍高就不够用。解决在application.yml里调大连接池spring: datasource: hikari: maximum-pool-size: 50 minimum-idle: 10 connection-timeout: 3000 idle-timeout: 600000 max-lifetime: 1800000maximum-pool-size不是越大越好一般设CPU 核数 * 2 磁盘数。50 对于单机 MySQL 已经偏大再大需要上读写分离。connection-timeout设 3 秒拿不到连接快速失败避免请求堆积。5. 用压测数据判断这套源码值不值得改5.1 用 JMeter 跑一轮下单压测部署完之后别急着上线。先用 JMeter 或者 wrk 压一轮下单接口看看瓶颈在哪。# 用 wrk 压测下单接口模拟 50 个并发持续 60 秒 wrk -t4 -c50 -d60s --latency \ -s post_order.lua \ http://your-domain.com/api/order/createpost_order.lua里构造带clientOrderNo和tableId的 POST 请求。重点看三个指标QPS、P99 延迟、错误率。如果 QPS 低于 200 或者 P99 超过 500ms说明有优化空间。我一般会先压「查菜单」这种读接口再压「下单」这种写接口。读接口慢通常是没加缓存或者 SQL 没走索引。写接口慢通常是锁竞争或者事务太大。5.2 看慢查询日志定位 SQL 问题MySQL 慢查询日志是排查性能问题的黑匣子。在my.cnf里开启[mysqld] slow_query_log 1 slow_query_log_file /var/log/mysql/slow.log long_query_time 1跑一轮压测后用mysqldumpslow分析mysqldumpslow -s t -t 10 /var/log/mysql/slow.log点餐系统最常见的慢查询是「查某个订单的明细」没走order_no索引或者「查今日营业额」全表扫描。前者加索引后者用定时任务预计算存 Redis。5.3 一个判断源码质量的土办法如果你还没决定用哪套源码有个快速判断方法看它的订单表有没有client_order_no字段、有没有status状态机、有没有pay_time和create_time分开。三个都有说明作者至少考虑过生产环境。只有一个自增主键和几个菜名那就是个玩具。另外看pom.xml里的依赖版本。Spring Boot 2.x 和 3.x 差别很大JDK 8 和 17 也不一样。如果源码用的是 Spring Boot 2.1 这种老版本升级成本不低但安全补丁必须打。5.4 上线前最后一张检查表检查项标准不通过的后果数据库字符集utf8mb4emoji 昵称插入失败订单号唯一索引有重复订单支付回调验签V3 证书验签伪造回调订单被篡改Redis 过期策略allkeys-lru内存溢出连接池大小≥ 20高峰期请求排队HTTPS 证书有效且备案真机无法请求日志级别info不打印敏感信息泄露用户手机号这张表我每次上线前都会过一遍少一项都不敢开张。点餐系统直接面对顾客午高峰出问题就是灾难。希望帮到你。本文还有配套的精品资源点击获取 微信小程序点餐系统源码上线实战：Java后端+小程序架构与避坑指南
简介这份资源是面向微信小程序初学者与电商开发入门者的在线点餐系统源码基于微信小程序开发框架并结合Java后端服务帮助读者理解从菜品展示、购物车到订单确认与微信支付的完整餐饮业务链路。压缩包共60个文件约1.18MB以js逻辑文件、json配置、wxss样式与wxml页面结构为主另有jpg、png图片素材及一份md说明文档覆盖前端页面、业务逻辑与配置等核心模块。目前已有1148人学习下载热度较为可观。读者可通过分析页面组件、JS交互逻辑、后端接口设计与数据库结构掌握小程序开发环境搭建、WXML与WXSS语法、常用API调用、RESTful接口设计及微信支付集成等关键知识点并借助Git进行版本管理与项目部署实践。源码结构清晰适合对照修改与二次开发是学习微信商城与在线点餐系统运作机制的实用参考。1. 微信小程序点餐系统源码从「能跑」到「能用」差了什么打开 GitHub 或者 Gitee 搜「微信小程序点餐系统源码」能翻出几百个仓库Java 后端的、Node 的、PHP 的都有。但真正拿下来部署到自己服务器上能撑住一个午高峰的十个里面未必有一个。问题不在代码写得多烂而在于大部分源码只解决了「功能有没有」的问题没解决「并发扛不扛得住」「订单状态会不会乱」「支付回调丢了怎么办」这些真正要命的事。这篇笔记面向的是手里已经有一份微信小程序商城源码、或者正准备选一套在线点餐源码的开发者。我会按 Java 后端 微信小程序前端的典型架构把从环境搭建、核心接口设计、订单状态机、支付回调处理到部署上线的完整路径拆开讲。每一步都给出可复现的代码和参数同时标出我踩过的坑。读完你应该能判断手里那份源码值不值得改以及怎么改才能上线接客。2. 拿到源码先别急着跑Java 后端 小程序前端的架构拆解2.1 一套点餐系统到底有哪几个进程常见的微信小程序点餐系统源码不管仓库描述写得多花哨拆开来看基本是这几个部分模块典型技术栈职责小程序前端原生小程序 / uni-app菜单展示、购物车、下单、支付、订单查询后端 APISpring Boot MyBatis-Plus菜品管理、订单、支付、用户、桌台管理后台Vue Element UI菜品上下架、订单管理、营业统计数据库MySQL 5.7 / 8.0业务数据持久化缓存Redis购物车、库存扣减、分布式锁支付微信支付 V3下单、回调、退款如果你拿到的源码只有小程序端和一个简单的 Java 单体没有 Redis 也没有管理后台那它大概率是个课程设计级别的项目。用来学习可以上线接单需要补的东西不少。先确认几件事后端是不是 Spring BootJDK 版本是多少数据库脚本在哪小程序端的appid和request域名配置在哪。这些信息决定了你后面要改多少东西。2.2 本地跑通后端的最小命令集假设你拿到的是一套标准的 Spring Boot MySQL 项目目录结构大概是order-server/ src/main/java/com/xxx/ controller/ service/ mapper/ entity/ src/main/resources/ application.yml mapper/ sql/init.sql第一步不是打开 IDE而是先把数据库建起来。很多源码的init.sql里没有建库语句直接跑会报Unknown database。# 登录 MySQL创建数据库字符集必须是 utf8mb4 mysql -u root -pCREATE DATABASE order_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE order_db; SOURCE /path/to/sql/init.sql;字符集这里别用utf8微信昵称里的 emoji 会直接导致插入失败报Incorrect string value。这是血泪经验上线后才发现的话改表结构很麻烦。然后是application.yml里必须改的几个参数spring: datasource: url: jdbc:mysql://127.0.0.1:3306/order_db?useUnicodetruecharacterEncodingutf8mb4serverTimezoneAsia/Shanghai username: root password: 你的密码 redis: host: 127.0.0.1 port: 6379 database: 0 wx: appid: 你的小程序appid secret: 你的小程序secret mch-id: 微信支付商户号 api-v3-key: 支付V3密钥serverTimezone必须显式指定否则 MySQL 8.0 驱动会报时区错误。characterEncoding写utf8mb4而不是utf8和建库时保持一致。启动命令# 确保 JDK 版本和 pom.xml 里一致常见是 JDK 8 或 JDK 17 java -version mvn clean package -DskipTests java -jar target/order-server-1.0.0.jar --spring.profiles.activedev如果启动报Table order_db.xxx doesnt exist说明init.sql没跑完或者跑到了别的库里。如果报Redis connection refused先把 Redis 起起来点餐系统的购物车和库存扣减基本都依赖 Redis没有它跑不起来。2.3 小程序端联调前必须改的三个配置小程序端拿到手直接编译大概率是白屏或者请求全部失败。打开app.js或者config.js找到这几个地方// config.js const config { baseUrl: http://localhost:8080/api, // 改成你后端实际地址 appId: wx1234567890abcdef, // 改成你自己的小程序 appid // ... }第一个坑微信开发者工具里请求localhost需要在「详情 → 本地设置」里勾选「不校验合法域名」。但真机预览时这个选项无效必须用内网穿透或者部署到有 HTTPS 的服务器上。第二个坑小程序请求域名必须是 HTTPS且不能带端口号除非是 443。开发阶段可以用内网穿透工具临时解决上线前必须配好备案域名和 SSL 证书。第三个坑appid和secret不匹配会导致code2session接口返回invalid appid。很多人从别人那里拿的源码appid没换登录一直失败查半天查不出来。3. 点餐核心链路从扫码到下单的 Java 接口怎么写3.1 购物车用 Redis Hash 还是 MySQL 临时表这是拿到源码后第一个要做的技术判断。很多课程设计级别的点餐系统购物车直接存 MySQL每次加减菜都写库。单桌测试没问题十桌同时点餐就开始锁表。常见做法是用 Redis Hashkey 是cart:{userId}或者cart:{tableId}field 是dishIdvalue 是数量。读写都在内存性能差一个数量级。Service public class CartService { Autowired private StringRedisTemplate redisTemplate; private static final String CART_KEY_PREFIX cart:; // 添加菜品到购物车 public void addDish(Long userId, Long dishId, Integer count) { String key CART_KEY_PREFIX userId; // hashIncrement 保证并发下数量不会丢 redisTemplate.opsForHash().increment(key, dishId.toString(), count); // 设置过期时间避免僵尸购物车占内存 redisTemplate.expire(key, 2, TimeUnit.HOURS); } // 获取购物车全部内容 public MapObject, Object getCart(Long userId) { String key CART_KEY_PREFIX userId; return redisTemplate.opsForHash().entries(key); } // 清空购物车下单成功后调用 public void clearCart(Long userId) { redisTemplate.delete(CART_KEY_PREFIX userId); } }increment是原子操作多个请求同时加同一道菜不会出现覆盖。过期时间设 2 小时覆盖一顿饭的时间就够了。如果用户中途换桌或者重新扫码购物车数据不会串。参数说明userId来自小程序登录后后端返回的 token 解析不要直接用微信openid当 keyopenid太长且可能变。count允许为负数实现减菜功能。3.2 下单接口的幂等和库存扣减下单是点餐系统最容易出问题的地方。用户手抖连点两次、网络超时重试、微信支付回调重复通知都会导致重复订单。必须做幂等。常见做法是前端生成一个clientOrderNo比如时间戳 随机数后端用它做唯一索引。插入时如果冲突就直接返回已有订单。RestController RequestMapping(/api/order) public class OrderController { Autowired private OrderService orderService; PostMapping(/create) public ResultOrderVO createOrder(RequestBody Valid OrderCreateDTO dto) { // dto 里必须带 clientOrderNo return orderService.createOrder(dto); } }Service public class OrderServiceImpl implements OrderService { Autowired private OrderMapper orderMapper; Autowired private StringRedisTemplate redisTemplate; Override Transactional(rollbackFor Exception.class) public ResultOrderVO createOrder(OrderCreateDTO dto) { // 1. 幂等检查clientOrderNo 唯一索引重复插入会抛异常 Order exist orderMapper.selectByClientOrderNo(dto.getClientOrderNo()); if (exist ! null) { return Result.success(convert(exist)); } // 2. 分布式锁锁住桌台防止同一桌并发下单 String lockKey lock:table: dto.getTableId(); Boolean locked redisTemplate.opsForValue() .setIfAbsent(lockKey, 1, 10, TimeUnit.SECONDS); if (Boolean.FALSE.equals(locked)) { return Result.fail(操作太快请稍后重试); } try { // 3. 从 Redis 购物车读取菜品校验库存 // 4. 扣减库存Redis decr 数据库乐观锁 // 5. 写入订单主表和明细表 // 6. 清空购物车 // 7. 返回订单信息前端拿 orderNo 去调支付 } finally { redisTemplate.delete(lockKey); } return Result.success(/* ... */); } }关键点clientOrderNo在数据库建唯一索引这是最后一道防线。分布式锁的过期时间设 10 秒足够完成一次下单但不能太长否则桌台被锁死。库存扣减用 Redisdecr做预扣数据库层面用update stock stock - 1 where stock 0做最终一致性。3.3 微信支付 V3 回调的验签和状态机支付回调是另一个翻车重灾区。微信支付 V3 的回调是加密的必须用 API V3 密钥解密然后验签。很多源码用的是 V2 的写法直接拿不到回调数据。RestController RequestMapping(/api/pay) public class PayCallbackController { Autowired private PayService payService; PostMapping(/notify) public String notify(RequestBody String body, RequestHeader(Wechatpay-Signature) String signature, RequestHeader(Wechatpay-Timestamp) String timestamp, RequestHeader(Wechatpay-Nonce) String nonce, RequestHeader(Wechatpay-Serial) String serial) { // 1. 验签用微信平台证书公钥 // 2. 解密 body 里的 resource.ciphertext // 3. 拿到 out_trade_no 和 trade_state // 4. 更新订单状态待支付 - 已支付 // 5. 返回 200否则微信会重复通知 return payService.handleNotify(body, signature, timestamp, nonce, serial); } }订单状态机必须严格待支付 → 已支付 → 制作中 → 已完成退款走已支付 → 退款中 → 已退款。每次状态变更都要记录操作日志否则出了问题查不到是谁改的。回调处理里最容易犯的错是解密后直接更新订单状态没有判断当前状态。如果微信重复通知订单已经「已完成」了又被改成「已支付」厨房就乱了。正确做法是加状态判断// 只有当前状态是「待支付」才更新 int rows orderMapper.updateStatus(orderNo, OrderStatus.PAID, OrderStatus.PENDING_PAY); if (rows 0) { // 说明已经被处理过了直接返回成功避免微信继续重试 return SUCCESS; }4. 部署上线前必须处理的五个坑4.1 坑一小程序请求域名没备案真机全部超时现象开发者工具里一切正常真机预览所有接口 404 或超时。原因微信小程序要求所有请求域名必须 ICP 备案且配置在「开发管理 → 服务器域名」里。localhost和 IP 地址在真机上无效。解决上线前准备好备案域名和 SSL 证书在微信公众平台配置request合法域名。开发阶段可以用内网穿透工具临时映射一个 HTTPS 地址但不要用于生产。4.2 坑二订单号重复导致插入失败现象高峰期偶尔报Duplicate entry xxx for key idx_order_no。原因订单号生成用了时间戳 随机数并发高时随机数碰撞。或者用了数据库自增但分库分表后不唯一。解决订单号用「日期 桌台号 序列号」或者雪花算法。如果源码里用的是System.currentTimeMillis()直接当订单号必须改。我一般用Redis INCR生成每日序列号拼上日期和桌台 ID既唯一又可读。4.3 坑三支付回调没收到订单一直待支付现象用户明明付了钱订单状态还是「待支付」厨房不出单。原因回调地址配错了或者服务器防火墙拦了微信的 POST 请求或者回调处理抛异常返回了非 200。解决先看微信支付商户平台的回调日志确认微信有没有发通知。如果发了但你没收到检查notify_url是不是公网可访问的 HTTPS 地址。如果收到了但处理失败看后端日志有没有解密或验签报错。最后加一个定时任务每 5 分钟查一次「待支付超过 10 分钟」的订单主动调微信查单接口补偿。4.4 坑四Redis 没设过期时间内存爆了现象运行几天后 Redis 内存告急新请求写入失败。原因购物车 key 没设 TTL或者设了但每次操作都重置 TTL导致僵尸购物车永远不过期。解决购物车 key 统一设 2 小时过期每次addDish时刷新过期时间。另外配置 Redis 的maxmemory-policy为allkeys-lru内存满时自动淘汰最久未使用的 key。4.5 坑五MySQL 连接池太小午高峰请求排队现象中午 12 点前后接口响应从 50ms 飙到 3s日志里出现Connection is not available。原因HikariCP 默认最大连接数是 10点餐系统并发稍高就不够用。解决在application.yml里调大连接池spring: datasource: hikari: maximum-pool-size: 50 minimum-idle: 10 connection-timeout: 3000 idle-timeout: 600000 max-lifetime: 1800000maximum-pool-size不是越大越好一般设CPU 核数 * 2 磁盘数。50 对于单机 MySQL 已经偏大再大需要上读写分离。connection-timeout设 3 秒拿不到连接快速失败避免请求堆积。5. 用压测数据判断这套源码值不值得改5.1 用 JMeter 跑一轮下单压测部署完之后别急着上线。先用 JMeter 或者 wrk 压一轮下单接口看看瓶颈在哪。# 用 wrk 压测下单接口模拟 50 个并发持续 60 秒 wrk -t4 -c50 -d60s --latency \ -s post_order.lua \ http://your-domain.com/api/order/createpost_order.lua里构造带clientOrderNo和tableId的 POST 请求。重点看三个指标QPS、P99 延迟、错误率。如果 QPS 低于 200 或者 P99 超过 500ms说明有优化空间。我一般会先压「查菜单」这种读接口再压「下单」这种写接口。读接口慢通常是没加缓存或者 SQL 没走索引。写接口慢通常是锁竞争或者事务太大。5.2 看慢查询日志定位 SQL 问题MySQL 慢查询日志是排查性能问题的黑匣子。在my.cnf里开启[mysqld] slow_query_log 1 slow_query_log_file /var/log/mysql/slow.log long_query_time 1跑一轮压测后用mysqldumpslow分析mysqldumpslow -s t -t 10 /var/log/mysql/slow.log点餐系统最常见的慢查询是「查某个订单的明细」没走order_no索引或者「查今日营业额」全表扫描。前者加索引后者用定时任务预计算存 Redis。5.3 一个判断源码质量的土办法如果你还没决定用哪套源码有个快速判断方法看它的订单表有没有client_order_no字段、有没有status状态机、有没有pay_time和create_time分开。三个都有说明作者至少考虑过生产环境。只有一个自增主键和几个菜名那就是个玩具。另外看pom.xml里的依赖版本。Spring Boot 2.x 和 3.x 差别很大JDK 8 和 17 也不一样。如果源码用的是 Spring Boot 2.1 这种老版本升级成本不低但安全补丁必须打。5.4 上线前最后一张检查表检查项标准不通过的后果数据库字符集utf8mb4emoji 昵称插入失败订单号唯一索引有重复订单支付回调验签V3 证书验签伪造回调订单被篡改Redis 过期策略allkeys-lru内存溢出连接池大小≥ 20高峰期请求排队HTTPS 证书有效且备案真机无法请求日志级别info不打印敏感信息泄露用户手机号这张表我每次上线前都会过一遍少一项都不敢开张。点餐系统直接面对顾客午高峰出问题就是灾难。希望帮到你。本文还有配套的精品资源点击获取