拓冰网站定制 
简介微信小程序源码-巴爷商城带后端.zip 是一套包含前端小程序与后端服务的完整电商项目面向想入门小程序开发、想了解前后端协作流程的开发者。资源共184个文件压缩包大小约4.04MB文件类型较为多元70个rb为Ruby后端代码15个js负责页面交互逻辑wxml/wxss搭建界面结构json保存页面配置yml等文件用于环境与项目设置png/jpg则提供商品与示例图片。目前已有64人学习下载。通过这份源码可以梳理商城核心功能如商品列表、详情页、购物车和订单管理同时看到后端在用户注册登录、商品增删改查、支付接口对接中的具体实现。项目还涉及密码加密、敏感信息脱敏及避免SQL注入等安全处理对理解真实电商系统的工程结构很有帮助。适合希望结合真实案例提升微信小程序开发能力的学习者。1. 巴爷商城这套「带后端」的小程序源码值不值得花一周去跑通收到「微信小程序源码-巴爷商城带后端.zip」之后解压出来通常是两个工程一个原生微信小程序前端一个 Java 后端再附一份 SQL 脚本。这类包在毕设、课程设计和全栈入门圈子里流传很广特征是「能跑通但跑通只是开始」它能让你一周内摸清前后端分离商城的最小闭环——商品展示、购物车、下单、订单管理但如果你指望解压即上线大概率会翻车。这篇文章按后端启动、前端登录链路、前后端联调、高频踩坑的顺序拆开讲每一段都可以照着复现。适合两种人手里已经拿到这套源码但不知道怎么起项目的人以及正在评估「带后端的商城小程序源码」值不值得作为二次开发基座的人。2. 先把后端扶起来Spring Boot 商城后端启动前最常改的 3 个配置拿到这类带后端的商城源码我一般不会先碰小程序前端而是先把后端跑通。原因很简单前端所有页面渲染都依赖后端接口后端起不来前端只有一个空壳。而商城类后端最常见的形态是 Spring Boot MySQL Redis三个组件里任何一个版本不对都会让启动停在半路。2.1 读 pom 和 application.yml确认 JDK、端口、数据源这三个入口后端工程解压后先看根目录下的pom.xml。重点不是通读依赖而是确认三件事Spring Boot 版本、JDK 版本要求、是否强制依赖 Redis。Spring Boot 2.x 通常配 JDK 83.x 配 JDK 17很多源码包在两个版本之间切换过pom 里可能写着java.version1.8/java.version但实际代码用了新语法编译时才暴露矛盾。接着打开src/main/resources/application.yml老一点的工程叫application.properties我最关心四个字段配置项常见写法出错表现server.port8080端口被占用时启动失败spring.datasource.urljdbc:mysql://localhost:3306/mall?useSSLfalse连不上库驱动报错spring.datasource.username/passwordroot/123456登录被拒spring.redis.hostlocalhost连不上 Redis启动卡住如果密码字段长得像ENC(xxx)说明工程用了 jasypt 加密源码包里一般会有JasyptConfig或JasyptUtils工具类跑一次解密工具把原文取出来改到本地配置里。这里有个血泪经验不要改完application.yml就直接启动先确认本机装了对应版本的 MySQL 和 Redis否则报错日志会把你绕晕。2.2 初始化数据库SQL 导入与字符集选择后端工程里一般有sql或db目录文件名类似mall.sql或bayer.sql。导入前先建库字符集统一用utf8mb4因为商城商品描述、用户昵称都可能带表情符号utf8存不下。命令行导入是最稳的方式比可视化工具更能看到报错mysql -u root -p -e CREATE DATABASE IF NOT EXISTS baye_mall DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; mysql -u root -p baye_mall sql/baye_mall.sql第一句是建库IF NOT EXISTS防止重复执行报错第二句把 SQL 文件导入刚建的库。这里的COLLATE utf8mb4_general_ci值得注意如果 SQL 文件是从 MySQL 8.0 导出的里面可能出现utf8mb4_0900_ai_ci这个排序规则而 MySQL 5.7 根本不认识它导入会直接中断。后面避坑章会专门讲这个。导入完成后用mysql -u root -p -e USE baye_mall; SHOW TABLES;确认表数量。商城类工程的表少则二三十张多则六七十张如果你看到只有个位数说明导入过程被某个报错中断了不要继续往下走。另外很多源码包会在 SQL 里预置管理员账号和测试用户常见的是admin和123456但密码往往是 MD5 加盐存储直接查表看不出来带着这个疑问去验证登录接口即可。2.3 启动后端Redis 依赖、健康检查与端口占用排错数据库就绪后启动后端。商城工程几乎都会把购物车、验证码或会话状态丢进 Redis所以本机必须先有 Redis 服务。Linux 或 macOS 上检查命令是redis-cli ping返回PONG就说明活着Windows 下如果只装了 Redis 的压缩包先启动redis-server.exe。这一步不做日志会卡在Connecting to Redis然后超时。启动命令我习惯直接用 Mavencd mall-backend mvn spring-boot:run如果不想让日志刷屏可以先编译再后台运行mvn clean package -DskipTests java -jar target/mall.jar --spring.profiles.activedev /tmp/mall.log 21 -DskipTests是跳过单元测试能省不少时间--spring.profiles.activedev指定加载application-dev.yml。日志最后一行出现Started XxxApplication in xx seconds才算真的起来了。如果启动失败先看有没有UnsupportedClassVersionError有就是 JDK 版本不对再看有没有Port 8080 was already in use有就跑一句lsof -i:8080查占用进程。后端起来后我习惯先验证一个公开接口再碰前端。常见的健康检查路径是/actuator/health或/api/health如果工程集成了 Swaggerspringfox 或 knife4j直接访问/doc.html或/swagger-ui.html看接口列表。用curl http://localhost:8080/api/health能看到 JSON 返回后端这一关就算过了。这一步通过之后你会发现小程序前端那些「请求失败」的报错十有八九是接口地址或域名校验的问题而不是后端逻辑的问题。3. 小程序前端目录拆解登录、手机号授权与自定义导航适配后端能跑起来就可以打开小程序前端了。先用微信开发者工具「导入项目」选择前端目录填一个测试号 AppID。此时界面能渲染但数据大概率加载不出来——因为前端默认的后端地址还是源码作者本机的localhost。这一章先拆目录结构再把登录链路和导航适配讲透理解了这三块商城类小程序的核心套路就通了。3.1 pages / utils / api 三层先看请求封装和全局配置原生微信小程序的工程结构通常是这样app.js放全局逻辑和登录态app.json注册页面和窗口表现pages/下每个页面一个目录包含.wxml、.wxss、.js、.json四件套。商城类工程还会多出utils/和api/两个目录前者放公共函数后者按模块拆接口定义。打开utils/request.js或api/index.js这是全工程最值得读的文件。里面一般封装了wx.request的 baseURL、请求头、token 注入和错误处理。我看到过无数次翻车现场前端的 baseURL 写死了http://localhost:8080开发者工具里能跑一换真机就废。正确的做法是把 baseURL 抽到一个统一配置里改成后端所在电脑的局域网 IP后面联调章会细说。另外注意区分前端是不是原生小程序。如果工程根目录有src/pages且页面是.vue文件那就是 uni-app 工程必须在 HBuilderX 里重新编译成微信小程序后再导入不能直接拿源码目录当小程序打开。很多人在这一步浪费一下午其实就是没分清工程类型。3.2 微信登录获取手机号的链路从 wx.login 到后端换 token商城小程序的登录链路分两段第一段是静默登录用wx.login拿临时 code后端拿 code 向微信接口换 openid然后下发登录态第二段是手机号授权用button open-typegetPhoneNumber引导用户授权拿到加密数据后由后端解密。只有这两段都完成用户才能下单。写一个最小可跑的登录页逻辑// pages/login/login.js Page({ onLoad() { // 静默登录wx.login 拿一次性 code发给后端换 token wx.login({ success: ({ code }) { wx.request({ url: ${getApp().globalData.baseURL}/api/auth/login, method: POST, data: { code }, success: ({ data }) { if (data.code 0) { wx.setStorageSync(token, data.data.token); wx.setStorageSync(hasLoggedIn, true); } } }); } }); }, onGetPhone(e) { // 手机号快捷验证组件e.detail 里只有 code没有手机号明文 if (e.detail.errMsg ! getPhoneNumber:ok) { wx.showToast({ title: 需要授权手机号才能下单, icon: none }); return; } wx.request({ url: ${getApp().globalData.baseURL}/api/auth/phone, method: POST, header: { Authorization: Bearer ${wx.getStorageSync(token) || } }, data: { code: e.detail.code }, success: ({ data }) { wx.setStorageSync(phone, data.data.phone); } }); } });这里有几个参数要解释清楚。wx.login返回的code是临时凭证有效期只有五分钟且只能用一次后端拿它去调微信的code2Session接口必须用到小程序的 AppID 和 AppSecret这两个值在小程序后台可以查到但AppSecret绝不能写在小程序前端代码里否则任何人翻包都能拿到它。这也是我判断一套源码是否规范的重要指标如果看到appsecret出现在前端的config.js里这套源码上线前一定要改架构把换 token 的动作挪到后端完成。关于手机号授权2023 年后微信的规则收紧了不少getPhoneNumber组件拿到的e.detail.code需要用后端持有的密钥去解密而且个人主体小程序没有这个能力必须是非个人主体且完成认证的账号。所以在本地联调阶段拿不到真实手机号是非常正常的不要怀疑代码写错了。我一般会让后端为每个 openid 生成一个虚拟手机号联调阶段保证流程能走通等正式上线换成企业主体 AppID 再走真实解密。3.3 顶部导航栏高度与自定义导航的适配很多商城源码为了视觉效果会自定义顶部导航栏在app.json里设置navigationStyle: custom把原生导航栏关掉。这会在用户体验上更统一但代价是要自己计算状态栏高度和胶囊按钮位置适配不好就会出现「右上角胶囊和自定义标题重叠」的经典翻车现场。计算逻辑业内已经有固定套路// utils/nav.js function getNavBarHeight() { const { statusBarHeight } wx.getSystemInfoSync(); const menu wx.getMenuButtonBoundingClientRect(); const navBarHeight (menu.top - statusBarHeight) * 2 menu.height; return { statusBarHeight, navBarHeight, menu }; } module.exports { getNavBarHeight };原理是这样的wx.getMenuButtonBoundingClientRect()返回右上角胶囊按钮的上下坐标和高度胶囊在垂直方向上通常是居中的所以「状态栏高度到胶囊顶部」的距离乘以 2加上胶囊自身高度就是自定义导航栏应该占的总高。拿到statusBarHeight和navBarHeight后给自定义导航根节点设置padding-top: statusBarHeight px再给导航内容区设置height: navBarHeight px就能和胶囊按钮对齐。这里有个必须注意的差异开发者工具里getMenuButtonBoundingClientRect()返回的坐标和真机不完全一样尤其 iPhone 的灵动岛机型与老款机型的胶囊位置有差别。所以不要在开发者工具里把坐标调好就收工一定要用真机预览确认一次。另外页面主体高度要减去状态栏和导航栏占掉的空间否则内容会被顶到屏幕外常见做法是对最外层容器用height: calc(100vh - 状态栏高度 - 导航栏高度)。4. 前后端联调四件事接口地址、跨域、token 和错误码排查后端起来了前端也能渲染了接下来就是最耗耐心的联调阶段。这一章讲的四个问题几乎是所有商城类小程序通病地址写死、跨域不会配、token 传不进去、错误码当成黑匣子。把这四件事做完商品列表、加购、下单这条主链路才算真正打通。4.1 接口地址别把 localhost 写进小程序小程序开发者工具默认有个「不校验合法域名」的开关打开之后http://localhost:8080也能请求。这个开关帮你在电脑上跑通一切但也埋了雷一上真机预览所有请求直接失败因为手机端的localhost指向手机自己不是你的电脑。解决方式很直接把后端启动电脑的局域网 IP 填到前端统一配置里。macOS 用ipconfig getifaddr en0查 IPWindows 用ipconfig查IPv4 地址假设查到是192.168.1.100前端的 baseURL 就改成http://192.168.1.100:8080。同时保证手机和电脑连的是同一个 Wi-Fi否则这个 IP 不通。我一般会在前端工程里单独建一个config.js把baseURL作为唯一出口// config.js module.exports { // 电脑局域网 IP真机联调时改成自己电脑的地址 baseURL: http://192.168.1.100:8080 };所有请求模块都引用这个文件而不是在几十个页面里各自写 URL。换环境时只改一处这个习惯能省下大量排查时间。需要提醒的是真机预览时微信开发者工具会提示「不在以下合法域名列表中」这时候可以点开右上角菜单里的「开发版调试」开关临时解决但正式体验版和上线版本必须在 mp 后台配置 HTTPS 域名这个属于申请域名和备案的范畴跑通本地闭环暂时不用管。4.2 后端跨域CORS 配置与网关层处理小程序自身的wx.request不受浏览器同源策略限制所以「小程序前端调后端」其实不存在跨域问题。但商城源码通常还带一个管理后台网页端后端给网页端提供接口时就一定涉及跨域。另外如果小程序里嵌了 web-view 页面web-view 里发起的请求也会有跨域限制。Spring Boot 后端配置 CORS 最常见的方式是写一个配置类// config/CorsConfig.java Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/api/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowCredentials(true) .maxAge(3600); } }addMapping(/api/**)表示只对/api路径下的接口生效避免把非接口路径也暴露出去allowedOriginPatterns(*)表示允许任意来源联调阶段图省事可以这么写但allowCredentials(true)开启后*必须写成allowedOriginPatterns而不是allowedOrigins否则启动时会直接报错。maxAge(3600)是预检请求的缓存时间单位秒设大一点可以减少每次请求前的 OPTIONS 请求数量。网上能搜到很多老教程让你写HttpServletResponse手动加 Header我不推荐那种方式——Servlet 版本一变方法签名就跟着变而且每写一个接口都要重复处理很容易漏。用一个WebMvcConfigurer统一管起所有接口是最不容易出错的做法。4.3 token 体系从 session 到 JWT联调时先确认认证方式老一点的商城源码用的是 session 方式登录成功后后端把 sessionId 写进 Cookie。这里有个让很多人抓狂的坑小程序里wx.request默认不会像浏览器那样自动携带 Cookie必须手动把响应头里的Set-Cookie取出来存到 Storage下一次请求再塞进 Header。很多老代码并没有做这一步导致的现象是「登录接口成功了但加购接口永远提示未登录」。新一点的源码用 JWT 或自定义 token登录接口返回一个 token 字符串前端每次请求在 Header 里带Authorization。这种模式更贴合前后端分离也是我建议你优先确认的认证方式。判断方法是看登录接口响应返回的是名为token的字段还是名为sessionId的字段。如果是后者就得按上面的 Cookie 方案处理。一个通用的前端请求封装长这样// utils/request.js const request (url, method, data) { return new Promise((resolve, reject) { wx.request({ url: ${getApp().globalData.baseURL}${url}, method, data, header: { Content-Type: application/json, Authorization: Bearer ${wx.getStorageSync(token) || } }, success: resolve, fail: reject }); }); }; module.exports request;注意Authorization用的是Bearer前缀这是 JWT 的惯例写法如果后端解析的是自定义头比如X-Token就要改这里的 key。这一改不对后端会一直返回「token 无效」而你在前端看请求头里明明有 token就会陷入玄学排查。这种问题用抓包工具看一次往返就能定位比肉眼盯代码快得多。4.4 请求超时与业务错误码看到 10002 先翻后端日志商城系统的接口响应里通常会包一层业务码比如{ code: 0, msg: success, data: {...} }。HTTP 状态码是 200不代表业务成功很多报错藏在code字段里。你在网上搜「微信小程序 10002」这种数字大概率搜不到统一答案因为这类四位数字多数是源码作者自己定义的业务码不是微信官方错误码。处理这种「黑匣子」错误码我的习惯是先在请求回调里把完整响应体打出来不要只看res.statusCode。开发者工具里的console.log(res)打印的是对象引用点开才能看到字段我一般直接console.log(JSON.stringify(res))把整个 JSON 字符串打出来code、msg、data一目了然。如果是code: 10002或code: 10010这类就去后端日志里搜当日错误日志对照logback或log4j的输出。排到这一步大多数问题的答案已经在后端日志里等着你了。请求超时同样要看后端。wx.request默认超时时间 60 秒商城接口如果十几秒不返回通常不是网络问题而是后端某个查询阻塞或者连接池被占满了。这时候看后端线程栈比调前端 timeout 参数有意义。5. 避坑清单跑巴爷商城源码翻车最多的 5 个现场带后端的源码包最大的特点是「数据靠环境环境靠配置」。我经手过好几套商城类源码发现翻车点高度集中基本都能归到 JDK、MySQL、网络环境、微信权限这四类。下面五条是最常见的按「现象 → 原因 → 解决」写方便你对号入座。5.1 后端一启动就报 UnsupportedClassVersionErrorJDK 版本对不上现象是启动日志抛java.lang.UnsupportedClassVersionError后面跟着Major.Minor version一串数字。原因很简单pom 里声明的 Spring Boot 版本要求的 JDK和你本机默认 JDK 不是同一个。Spring Boot 3.x 强制要求 JDK 17Spring Boot 2.x 用 JDK 8 最稳。解决方法是先确认本机装了哪个 JDKjava -version看版本再确认 Maven 用的 JDKmvn -v会显示 Java version。如果你不想装新 JDK可以把 pom 里 Spring Boot 版本降到 2.7.x同时把java.version改成1.8然后mvn clean重新编译。注意只改java.version不降 Spring Boot 版本编译期可能报错因为新版本类库本身就有最低 JDK 要求。5.2 前端请求一直 pending先 curl 再抓包现象是小程序页面空白开发者工具 Network 面板里请求状态一直 pending。原因通常有三个后端没启动、baseURL 写的是别人电脑的 IP、或者抓包工具把请求拦住了。别急着改代码先本地 curl 一下后端接口curl -X GET http://192.168.1.100:8080/api/health如果能返回 JSON问题就在前端网络层或微信环境如果连接失败问题在 IP 或后端进程。确认后端可达后再用抓包工具看小程序的请求是否真的发出去了、发到哪个地址。用 Charles 这类抓包工具需要先在手机 Wi-Fi 设置里指到电脑端口再安装对应证书配置一次之后能看到每个接口的请求体和响应体比开发者工具的 Network 面板直观得多。这一步能直接把「前端玄学」变成「后端事实」。5.3 SQL 导入报 Unknown collation: utf8mb4_0900_ai_ciMySQL 5.7 和 8.0 的字符集差异现象是导入 SQL 文件时报错就卡在utf8mb4_0900_ai_ci这个排序规则上。原因很明确SQL 文件在 MySQL 8.0 环境导出本机装的是 MySQL 5.7两个版本的默认排序规则不同。解决有三条路最省事的是直接装 MySQL 8.0 重新导入其次是全局替换把.sql文件里的utf8mb4_0900_ai_ci全部替换成utf8mb4_general_ci用编辑器或sed -i s/utf8mb4_0900_ai_ci/utf8mb4_general_ci/g baye_mall.sql都行第三条是建库时指定COLLATE utf8mb4_general_ci但如果表定义里硬编码了排序规则还是会报错。替换完重新导入再数一遍表数量确认没有半途而废。5.4 真机预览请求不通电脑模拟器却正常不是代码问题是网络环境现象是开发者工具一切正常手机真机预览时页面空白请求全部失败。原因基本是三个之一电脑和手机不在同一 Wi-Fi、后端只监听了127.0.0.1、真机详情里没打开调试开关。解决方法是先确认手机能 ping 通电脑 IP然后把后端启动地址改成0.0.0.0Spring Boot 默认监听所有网卡通常不用改最后在真机预览页面右上角点开菜单确认「开发版调试」是开启状态。另外提醒一句不要用电脑开热点给手机连某些电脑的热点模式和路由器模式会隔离设备互相 ping 不通最稳的是手机和电脑都连同一个家用路由器。5.5 手机号获取失败 getPhoneNumber:fail主体类型和基础库版本的限制现象是点击手机号授权按钮后回调errMsg是getPhoneNumber:fail。原因可能是当前 AppID 是个人主体而手机号快捷验证组件要求非个人主体也可能是小程序基础库版本低于组件要求的最低版本还可能只是用户点了拒绝。解决的第一步是看e.detail.errMsg的具体文案如果带deny字样是用户主动拒绝引导重新授权即可如果是fail且没有明确文案那基本是能力受限。本地联调阶段我通常让后端做一个 mock 接口用 openid 映射一个虚拟手机号保证下单流程能走完。等正式上线换成认证过的企业主体 AppID再走真实解密链路。如果你用测试号调试这类受限问题基本无解不要花时间钻牛角尖。6. 用一份自测清单确认商城下单闭环再谈改造方向把后端、前端、联调都跑通之后最后一步是系统性验证。商城类业务最怕「登录能进、列表能看但下单就断」所以我的习惯是准备一份自测清单按用户视角从头到尾走一遍环节操作预期结果登录打开小程序静默登录后端日志出现auth/login调用Storage 里写入 token手机号点击授权拿到 mock 手机号用户信息落库首页下拉刷新banner、分类、推荐商品正常渲染商品详情进入详情页选择规格库存和价格正确显示加购加入购物车购物车角标更新Redis 里出现数据下单确认订单并提交订单状态变成待支付生成订单号支付走模拟支付回调订单状态变成已支付管理端管理员登录订单列表能看到用户订单可发货这一套走完这个源码包才算「吃透」。如果中间任何一步断了按第五章的避坑思路回查不要直接怀疑源码坏了——绝大多数是环境变量问题。过了自测清单再谈改造才靠谱。我的建议按成本从低到高排第一前端迁移到 uni-app一套代码同时生成微信小程序和 H5适合后面要做多端的场景但注意原生的wx.login和getPhoneNumber都要改成 uni-app 的 API 风格涉及登录链路的编码量不小第二管理端如果太老旧可以参考 ruoyi 这类成熟的脚手架重做权限和菜单比在旧代码上打补丁省心第三支付要接真实微信支付必须准备企业主体的商户号、API 证书并保证后端有 HTTPS 域名接收回调这一步没有捷径属于资质门槛。说到底这类「源码带后端」的项目是很好的学习载体你可以边跑边拆搞懂 session 和 JWT 的差别搞懂小程序登录态从哪来、到哪里去搞懂 CORS 为什么会让网页端请求失败而小程序端没事。这些经验在换一个项目时依然成立这才是这套源码包真正值钱的地方。至于我个人的习惯拿到任何源码包都会先写一份「三关检查表」后端能不能起、数据库能不能导、登录能不能通——三关过了再谈业务从没翻过车。希望帮到你。本文还有配套的精品资源点击获取 带后端小程序源码怎么跑通？Spring Boot商城前后端联调全指南
简介微信小程序源码-巴爷商城带后端.zip 是一套包含前端小程序与后端服务的完整电商项目面向想入门小程序开发、想了解前后端协作流程的开发者。资源共184个文件压缩包大小约4.04MB文件类型较为多元70个rb为Ruby后端代码15个js负责页面交互逻辑wxml/wxss搭建界面结构json保存页面配置yml等文件用于环境与项目设置png/jpg则提供商品与示例图片。目前已有64人学习下载。通过这份源码可以梳理商城核心功能如商品列表、详情页、购物车和订单管理同时看到后端在用户注册登录、商品增删改查、支付接口对接中的具体实现。项目还涉及密码加密、敏感信息脱敏及避免SQL注入等安全处理对理解真实电商系统的工程结构很有帮助。适合希望结合真实案例提升微信小程序开发能力的学习者。1. 巴爷商城这套「带后端」的小程序源码值不值得花一周去跑通收到「微信小程序源码-巴爷商城带后端.zip」之后解压出来通常是两个工程一个原生微信小程序前端一个 Java 后端再附一份 SQL 脚本。这类包在毕设、课程设计和全栈入门圈子里流传很广特征是「能跑通但跑通只是开始」它能让你一周内摸清前后端分离商城的最小闭环——商品展示、购物车、下单、订单管理但如果你指望解压即上线大概率会翻车。这篇文章按后端启动、前端登录链路、前后端联调、高频踩坑的顺序拆开讲每一段都可以照着复现。适合两种人手里已经拿到这套源码但不知道怎么起项目的人以及正在评估「带后端的商城小程序源码」值不值得作为二次开发基座的人。2. 先把后端扶起来Spring Boot 商城后端启动前最常改的 3 个配置拿到这类带后端的商城源码我一般不会先碰小程序前端而是先把后端跑通。原因很简单前端所有页面渲染都依赖后端接口后端起不来前端只有一个空壳。而商城类后端最常见的形态是 Spring Boot MySQL Redis三个组件里任何一个版本不对都会让启动停在半路。2.1 读 pom 和 application.yml确认 JDK、端口、数据源这三个入口后端工程解压后先看根目录下的pom.xml。重点不是通读依赖而是确认三件事Spring Boot 版本、JDK 版本要求、是否强制依赖 Redis。Spring Boot 2.x 通常配 JDK 83.x 配 JDK 17很多源码包在两个版本之间切换过pom 里可能写着java.version1.8/java.version但实际代码用了新语法编译时才暴露矛盾。接着打开src/main/resources/application.yml老一点的工程叫application.properties我最关心四个字段配置项常见写法出错表现server.port8080端口被占用时启动失败spring.datasource.urljdbc:mysql://localhost:3306/mall?useSSLfalse连不上库驱动报错spring.datasource.username/passwordroot/123456登录被拒spring.redis.hostlocalhost连不上 Redis启动卡住如果密码字段长得像ENC(xxx)说明工程用了 jasypt 加密源码包里一般会有JasyptConfig或JasyptUtils工具类跑一次解密工具把原文取出来改到本地配置里。这里有个血泪经验不要改完application.yml就直接启动先确认本机装了对应版本的 MySQL 和 Redis否则报错日志会把你绕晕。2.2 初始化数据库SQL 导入与字符集选择后端工程里一般有sql或db目录文件名类似mall.sql或bayer.sql。导入前先建库字符集统一用utf8mb4因为商城商品描述、用户昵称都可能带表情符号utf8存不下。命令行导入是最稳的方式比可视化工具更能看到报错mysql -u root -p -e CREATE DATABASE IF NOT EXISTS baye_mall DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; mysql -u root -p baye_mall sql/baye_mall.sql第一句是建库IF NOT EXISTS防止重复执行报错第二句把 SQL 文件导入刚建的库。这里的COLLATE utf8mb4_general_ci值得注意如果 SQL 文件是从 MySQL 8.0 导出的里面可能出现utf8mb4_0900_ai_ci这个排序规则而 MySQL 5.7 根本不认识它导入会直接中断。后面避坑章会专门讲这个。导入完成后用mysql -u root -p -e USE baye_mall; SHOW TABLES;确认表数量。商城类工程的表少则二三十张多则六七十张如果你看到只有个位数说明导入过程被某个报错中断了不要继续往下走。另外很多源码包会在 SQL 里预置管理员账号和测试用户常见的是admin和123456但密码往往是 MD5 加盐存储直接查表看不出来带着这个疑问去验证登录接口即可。2.3 启动后端Redis 依赖、健康检查与端口占用排错数据库就绪后启动后端。商城工程几乎都会把购物车、验证码或会话状态丢进 Redis所以本机必须先有 Redis 服务。Linux 或 macOS 上检查命令是redis-cli ping返回PONG就说明活着Windows 下如果只装了 Redis 的压缩包先启动redis-server.exe。这一步不做日志会卡在Connecting to Redis然后超时。启动命令我习惯直接用 Mavencd mall-backend mvn spring-boot:run如果不想让日志刷屏可以先编译再后台运行mvn clean package -DskipTests java -jar target/mall.jar --spring.profiles.activedev /tmp/mall.log 21 -DskipTests是跳过单元测试能省不少时间--spring.profiles.activedev指定加载application-dev.yml。日志最后一行出现Started XxxApplication in xx seconds才算真的起来了。如果启动失败先看有没有UnsupportedClassVersionError有就是 JDK 版本不对再看有没有Port 8080 was already in use有就跑一句lsof -i:8080查占用进程。后端起来后我习惯先验证一个公开接口再碰前端。常见的健康检查路径是/actuator/health或/api/health如果工程集成了 Swaggerspringfox 或 knife4j直接访问/doc.html或/swagger-ui.html看接口列表。用curl http://localhost:8080/api/health能看到 JSON 返回后端这一关就算过了。这一步通过之后你会发现小程序前端那些「请求失败」的报错十有八九是接口地址或域名校验的问题而不是后端逻辑的问题。3. 小程序前端目录拆解登录、手机号授权与自定义导航适配后端能跑起来就可以打开小程序前端了。先用微信开发者工具「导入项目」选择前端目录填一个测试号 AppID。此时界面能渲染但数据大概率加载不出来——因为前端默认的后端地址还是源码作者本机的localhost。这一章先拆目录结构再把登录链路和导航适配讲透理解了这三块商城类小程序的核心套路就通了。3.1 pages / utils / api 三层先看请求封装和全局配置原生微信小程序的工程结构通常是这样app.js放全局逻辑和登录态app.json注册页面和窗口表现pages/下每个页面一个目录包含.wxml、.wxss、.js、.json四件套。商城类工程还会多出utils/和api/两个目录前者放公共函数后者按模块拆接口定义。打开utils/request.js或api/index.js这是全工程最值得读的文件。里面一般封装了wx.request的 baseURL、请求头、token 注入和错误处理。我看到过无数次翻车现场前端的 baseURL 写死了http://localhost:8080开发者工具里能跑一换真机就废。正确的做法是把 baseURL 抽到一个统一配置里改成后端所在电脑的局域网 IP后面联调章会细说。另外注意区分前端是不是原生小程序。如果工程根目录有src/pages且页面是.vue文件那就是 uni-app 工程必须在 HBuilderX 里重新编译成微信小程序后再导入不能直接拿源码目录当小程序打开。很多人在这一步浪费一下午其实就是没分清工程类型。3.2 微信登录获取手机号的链路从 wx.login 到后端换 token商城小程序的登录链路分两段第一段是静默登录用wx.login拿临时 code后端拿 code 向微信接口换 openid然后下发登录态第二段是手机号授权用button open-typegetPhoneNumber引导用户授权拿到加密数据后由后端解密。只有这两段都完成用户才能下单。写一个最小可跑的登录页逻辑// pages/login/login.js Page({ onLoad() { // 静默登录wx.login 拿一次性 code发给后端换 token wx.login({ success: ({ code }) { wx.request({ url: ${getApp().globalData.baseURL}/api/auth/login, method: POST, data: { code }, success: ({ data }) { if (data.code 0) { wx.setStorageSync(token, data.data.token); wx.setStorageSync(hasLoggedIn, true); } } }); } }); }, onGetPhone(e) { // 手机号快捷验证组件e.detail 里只有 code没有手机号明文 if (e.detail.errMsg ! getPhoneNumber:ok) { wx.showToast({ title: 需要授权手机号才能下单, icon: none }); return; } wx.request({ url: ${getApp().globalData.baseURL}/api/auth/phone, method: POST, header: { Authorization: Bearer ${wx.getStorageSync(token) || } }, data: { code: e.detail.code }, success: ({ data }) { wx.setStorageSync(phone, data.data.phone); } }); } });这里有几个参数要解释清楚。wx.login返回的code是临时凭证有效期只有五分钟且只能用一次后端拿它去调微信的code2Session接口必须用到小程序的 AppID 和 AppSecret这两个值在小程序后台可以查到但AppSecret绝不能写在小程序前端代码里否则任何人翻包都能拿到它。这也是我判断一套源码是否规范的重要指标如果看到appsecret出现在前端的config.js里这套源码上线前一定要改架构把换 token 的动作挪到后端完成。关于手机号授权2023 年后微信的规则收紧了不少getPhoneNumber组件拿到的e.detail.code需要用后端持有的密钥去解密而且个人主体小程序没有这个能力必须是非个人主体且完成认证的账号。所以在本地联调阶段拿不到真实手机号是非常正常的不要怀疑代码写错了。我一般会让后端为每个 openid 生成一个虚拟手机号联调阶段保证流程能走通等正式上线换成企业主体 AppID 再走真实解密。3.3 顶部导航栏高度与自定义导航的适配很多商城源码为了视觉效果会自定义顶部导航栏在app.json里设置navigationStyle: custom把原生导航栏关掉。这会在用户体验上更统一但代价是要自己计算状态栏高度和胶囊按钮位置适配不好就会出现「右上角胶囊和自定义标题重叠」的经典翻车现场。计算逻辑业内已经有固定套路// utils/nav.js function getNavBarHeight() { const { statusBarHeight } wx.getSystemInfoSync(); const menu wx.getMenuButtonBoundingClientRect(); const navBarHeight (menu.top - statusBarHeight) * 2 menu.height; return { statusBarHeight, navBarHeight, menu }; } module.exports { getNavBarHeight };原理是这样的wx.getMenuButtonBoundingClientRect()返回右上角胶囊按钮的上下坐标和高度胶囊在垂直方向上通常是居中的所以「状态栏高度到胶囊顶部」的距离乘以 2加上胶囊自身高度就是自定义导航栏应该占的总高。拿到statusBarHeight和navBarHeight后给自定义导航根节点设置padding-top: statusBarHeight px再给导航内容区设置height: navBarHeight px就能和胶囊按钮对齐。这里有个必须注意的差异开发者工具里getMenuButtonBoundingClientRect()返回的坐标和真机不完全一样尤其 iPhone 的灵动岛机型与老款机型的胶囊位置有差别。所以不要在开发者工具里把坐标调好就收工一定要用真机预览确认一次。另外页面主体高度要减去状态栏和导航栏占掉的空间否则内容会被顶到屏幕外常见做法是对最外层容器用height: calc(100vh - 状态栏高度 - 导航栏高度)。4. 前后端联调四件事接口地址、跨域、token 和错误码排查后端起来了前端也能渲染了接下来就是最耗耐心的联调阶段。这一章讲的四个问题几乎是所有商城类小程序通病地址写死、跨域不会配、token 传不进去、错误码当成黑匣子。把这四件事做完商品列表、加购、下单这条主链路才算真正打通。4.1 接口地址别把 localhost 写进小程序小程序开发者工具默认有个「不校验合法域名」的开关打开之后http://localhost:8080也能请求。这个开关帮你在电脑上跑通一切但也埋了雷一上真机预览所有请求直接失败因为手机端的localhost指向手机自己不是你的电脑。解决方式很直接把后端启动电脑的局域网 IP 填到前端统一配置里。macOS 用ipconfig getifaddr en0查 IPWindows 用ipconfig查IPv4 地址假设查到是192.168.1.100前端的 baseURL 就改成http://192.168.1.100:8080。同时保证手机和电脑连的是同一个 Wi-Fi否则这个 IP 不通。我一般会在前端工程里单独建一个config.js把baseURL作为唯一出口// config.js module.exports { // 电脑局域网 IP真机联调时改成自己电脑的地址 baseURL: http://192.168.1.100:8080 };所有请求模块都引用这个文件而不是在几十个页面里各自写 URL。换环境时只改一处这个习惯能省下大量排查时间。需要提醒的是真机预览时微信开发者工具会提示「不在以下合法域名列表中」这时候可以点开右上角菜单里的「开发版调试」开关临时解决但正式体验版和上线版本必须在 mp 后台配置 HTTPS 域名这个属于申请域名和备案的范畴跑通本地闭环暂时不用管。4.2 后端跨域CORS 配置与网关层处理小程序自身的wx.request不受浏览器同源策略限制所以「小程序前端调后端」其实不存在跨域问题。但商城源码通常还带一个管理后台网页端后端给网页端提供接口时就一定涉及跨域。另外如果小程序里嵌了 web-view 页面web-view 里发起的请求也会有跨域限制。Spring Boot 后端配置 CORS 最常见的方式是写一个配置类// config/CorsConfig.java Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/api/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowCredentials(true) .maxAge(3600); } }addMapping(/api/**)表示只对/api路径下的接口生效避免把非接口路径也暴露出去allowedOriginPatterns(*)表示允许任意来源联调阶段图省事可以这么写但allowCredentials(true)开启后*必须写成allowedOriginPatterns而不是allowedOrigins否则启动时会直接报错。maxAge(3600)是预检请求的缓存时间单位秒设大一点可以减少每次请求前的 OPTIONS 请求数量。网上能搜到很多老教程让你写HttpServletResponse手动加 Header我不推荐那种方式——Servlet 版本一变方法签名就跟着变而且每写一个接口都要重复处理很容易漏。用一个WebMvcConfigurer统一管起所有接口是最不容易出错的做法。4.3 token 体系从 session 到 JWT联调时先确认认证方式老一点的商城源码用的是 session 方式登录成功后后端把 sessionId 写进 Cookie。这里有个让很多人抓狂的坑小程序里wx.request默认不会像浏览器那样自动携带 Cookie必须手动把响应头里的Set-Cookie取出来存到 Storage下一次请求再塞进 Header。很多老代码并没有做这一步导致的现象是「登录接口成功了但加购接口永远提示未登录」。新一点的源码用 JWT 或自定义 token登录接口返回一个 token 字符串前端每次请求在 Header 里带Authorization。这种模式更贴合前后端分离也是我建议你优先确认的认证方式。判断方法是看登录接口响应返回的是名为token的字段还是名为sessionId的字段。如果是后者就得按上面的 Cookie 方案处理。一个通用的前端请求封装长这样// utils/request.js const request (url, method, data) { return new Promise((resolve, reject) { wx.request({ url: ${getApp().globalData.baseURL}${url}, method, data, header: { Content-Type: application/json, Authorization: Bearer ${wx.getStorageSync(token) || } }, success: resolve, fail: reject }); }); }; module.exports request;注意Authorization用的是Bearer前缀这是 JWT 的惯例写法如果后端解析的是自定义头比如X-Token就要改这里的 key。这一改不对后端会一直返回「token 无效」而你在前端看请求头里明明有 token就会陷入玄学排查。这种问题用抓包工具看一次往返就能定位比肉眼盯代码快得多。4.4 请求超时与业务错误码看到 10002 先翻后端日志商城系统的接口响应里通常会包一层业务码比如{ code: 0, msg: success, data: {...} }。HTTP 状态码是 200不代表业务成功很多报错藏在code字段里。你在网上搜「微信小程序 10002」这种数字大概率搜不到统一答案因为这类四位数字多数是源码作者自己定义的业务码不是微信官方错误码。处理这种「黑匣子」错误码我的习惯是先在请求回调里把完整响应体打出来不要只看res.statusCode。开发者工具里的console.log(res)打印的是对象引用点开才能看到字段我一般直接console.log(JSON.stringify(res))把整个 JSON 字符串打出来code、msg、data一目了然。如果是code: 10002或code: 10010这类就去后端日志里搜当日错误日志对照logback或log4j的输出。排到这一步大多数问题的答案已经在后端日志里等着你了。请求超时同样要看后端。wx.request默认超时时间 60 秒商城接口如果十几秒不返回通常不是网络问题而是后端某个查询阻塞或者连接池被占满了。这时候看后端线程栈比调前端 timeout 参数有意义。5. 避坑清单跑巴爷商城源码翻车最多的 5 个现场带后端的源码包最大的特点是「数据靠环境环境靠配置」。我经手过好几套商城类源码发现翻车点高度集中基本都能归到 JDK、MySQL、网络环境、微信权限这四类。下面五条是最常见的按「现象 → 原因 → 解决」写方便你对号入座。5.1 后端一启动就报 UnsupportedClassVersionErrorJDK 版本对不上现象是启动日志抛java.lang.UnsupportedClassVersionError后面跟着Major.Minor version一串数字。原因很简单pom 里声明的 Spring Boot 版本要求的 JDK和你本机默认 JDK 不是同一个。Spring Boot 3.x 强制要求 JDK 17Spring Boot 2.x 用 JDK 8 最稳。解决方法是先确认本机装了哪个 JDKjava -version看版本再确认 Maven 用的 JDKmvn -v会显示 Java version。如果你不想装新 JDK可以把 pom 里 Spring Boot 版本降到 2.7.x同时把java.version改成1.8然后mvn clean重新编译。注意只改java.version不降 Spring Boot 版本编译期可能报错因为新版本类库本身就有最低 JDK 要求。5.2 前端请求一直 pending先 curl 再抓包现象是小程序页面空白开发者工具 Network 面板里请求状态一直 pending。原因通常有三个后端没启动、baseURL 写的是别人电脑的 IP、或者抓包工具把请求拦住了。别急着改代码先本地 curl 一下后端接口curl -X GET http://192.168.1.100:8080/api/health如果能返回 JSON问题就在前端网络层或微信环境如果连接失败问题在 IP 或后端进程。确认后端可达后再用抓包工具看小程序的请求是否真的发出去了、发到哪个地址。用 Charles 这类抓包工具需要先在手机 Wi-Fi 设置里指到电脑端口再安装对应证书配置一次之后能看到每个接口的请求体和响应体比开发者工具的 Network 面板直观得多。这一步能直接把「前端玄学」变成「后端事实」。5.3 SQL 导入报 Unknown collation: utf8mb4_0900_ai_ciMySQL 5.7 和 8.0 的字符集差异现象是导入 SQL 文件时报错就卡在utf8mb4_0900_ai_ci这个排序规则上。原因很明确SQL 文件在 MySQL 8.0 环境导出本机装的是 MySQL 5.7两个版本的默认排序规则不同。解决有三条路最省事的是直接装 MySQL 8.0 重新导入其次是全局替换把.sql文件里的utf8mb4_0900_ai_ci全部替换成utf8mb4_general_ci用编辑器或sed -i s/utf8mb4_0900_ai_ci/utf8mb4_general_ci/g baye_mall.sql都行第三条是建库时指定COLLATE utf8mb4_general_ci但如果表定义里硬编码了排序规则还是会报错。替换完重新导入再数一遍表数量确认没有半途而废。5.4 真机预览请求不通电脑模拟器却正常不是代码问题是网络环境现象是开发者工具一切正常手机真机预览时页面空白请求全部失败。原因基本是三个之一电脑和手机不在同一 Wi-Fi、后端只监听了127.0.0.1、真机详情里没打开调试开关。解决方法是先确认手机能 ping 通电脑 IP然后把后端启动地址改成0.0.0.0Spring Boot 默认监听所有网卡通常不用改最后在真机预览页面右上角点开菜单确认「开发版调试」是开启状态。另外提醒一句不要用电脑开热点给手机连某些电脑的热点模式和路由器模式会隔离设备互相 ping 不通最稳的是手机和电脑都连同一个家用路由器。5.5 手机号获取失败 getPhoneNumber:fail主体类型和基础库版本的限制现象是点击手机号授权按钮后回调errMsg是getPhoneNumber:fail。原因可能是当前 AppID 是个人主体而手机号快捷验证组件要求非个人主体也可能是小程序基础库版本低于组件要求的最低版本还可能只是用户点了拒绝。解决的第一步是看e.detail.errMsg的具体文案如果带deny字样是用户主动拒绝引导重新授权即可如果是fail且没有明确文案那基本是能力受限。本地联调阶段我通常让后端做一个 mock 接口用 openid 映射一个虚拟手机号保证下单流程能走完。等正式上线换成认证过的企业主体 AppID再走真实解密链路。如果你用测试号调试这类受限问题基本无解不要花时间钻牛角尖。6. 用一份自测清单确认商城下单闭环再谈改造方向把后端、前端、联调都跑通之后最后一步是系统性验证。商城类业务最怕「登录能进、列表能看但下单就断」所以我的习惯是准备一份自测清单按用户视角从头到尾走一遍环节操作预期结果登录打开小程序静默登录后端日志出现auth/login调用Storage 里写入 token手机号点击授权拿到 mock 手机号用户信息落库首页下拉刷新banner、分类、推荐商品正常渲染商品详情进入详情页选择规格库存和价格正确显示加购加入购物车购物车角标更新Redis 里出现数据下单确认订单并提交订单状态变成待支付生成订单号支付走模拟支付回调订单状态变成已支付管理端管理员登录订单列表能看到用户订单可发货这一套走完这个源码包才算「吃透」。如果中间任何一步断了按第五章的避坑思路回查不要直接怀疑源码坏了——绝大多数是环境变量问题。过了自测清单再谈改造才靠谱。我的建议按成本从低到高排第一前端迁移到 uni-app一套代码同时生成微信小程序和 H5适合后面要做多端的场景但注意原生的wx.login和getPhoneNumber都要改成 uni-app 的 API 风格涉及登录链路的编码量不小第二管理端如果太老旧可以参考 ruoyi 这类成熟的脚手架重做权限和菜单比在旧代码上打补丁省心第三支付要接真实微信支付必须准备企业主体的商户号、API 证书并保证后端有 HTTPS 域名接收回调这一步没有捷径属于资质门槛。说到底这类「源码带后端」的项目是很好的学习载体你可以边跑边拆搞懂 session 和 JWT 的差别搞懂小程序登录态从哪来、到哪里去搞懂 CORS 为什么会让网页端请求失败而小程序端没事。这些经验在换一个项目时依然成立这才是这套源码包真正值钱的地方。至于我个人的习惯拿到任何源码包都会先写一份「三关检查表」后端能不能起、数据库能不能导、登录能不能通——三关过了再谈业务从没翻过车。希望帮到你。本文还有配套的精品资源点击获取