基于Spring Boot与uniapp的全开源微信小程序商城实战指南

简介这是一套面向Java后端与uniapp前端开发者、专为快速构建微信小程序商城而设计的全栈开源解决方案适用于新零售、线上网店及轻量级电商建站场景尤其适合具备基础Web开发能力的中初级工程师学习与二次开发。资源包共2000个文件涵盖497个Java后端源码含Spring BootMyBatis核心业务逻辑、659个JS脚本含uniapp框架逻辑与API交互、55个Vue组件用于小程序页面模块化开发以及CSS、HTML、JSON、XML等配套资源整体压缩包仅16.06MB结构清晰、依赖明确。已有1170人下载学习可直接获取完整前后端代码、标准化目录结构、主流UI样式库如element、iview、bootstrap等CSS集成及数据库SQL脚本无需从零搭建基础架构大幅降低小程序商城落地门槛。 前后端全部开源微信小程序商城听起来像是烂大街的仓库但真去下载过的人会知道同时满足“后端是Java”“前端是uniapp”“前后端都能跑起来”“带管理后台”这四个条件的项目比想象中少得多。我最近拿了一套这样的源码做二次开发从本地启动到小程序真机联调再到部署上线把整条链路完整走了一遍。这篇文章就把这套微信小程序商城的技术选型逻辑、核心模块实现、支付登录对接、上线部署的细节以及我踩过的坑一次性讲清楚适合想快速搭商城系统的Java后端开发、uniapp前端新手还有准备拿开源项目做毕业设计或商业项目底座的程序员。1. 开源商城项目的地基整体架构与代码结构1.1 前后端分离的模块划分方式这套商城严格遵循前后端分离架构。后端是标准的Spring Boot工程按功能拆成若干个包用户模块、商品模块、订单模块、购物车模块、支付模块、优惠券模块和管理后台接口模块。前端分成两个独立工程一个是用户端小程序uniapp另一个是管理后台。很多开源项目的通病是只开源用户端、后端不完整这套项目难得的地方在于管理后台的代码也是完整的不用自己返工去写商品上下架、订单处理、数据统计这些页面。拿到源码之后先别急着跑把目录结构捋一遍很重要。后端工程里最关键的是resources目录下的application.yml和SQL初始化脚本。我第一次跑类似项目时就吃过亏只盯着代码看忘了导入数据库结果启动报错还以为是环境问题。MySQL和Redis是必须提前装好的MySQL存业务数据Redis承担缓存和登录态管理这两个服务没起来后端是起不来的。1.2 一次完整请求的链路是怎样的理解这个项目的架构最快的方式是跟着一次用户请求走一遍。小程序端用户点击“加入购物车”或者“提交订单”uniapp通过封装好的request.js发起请求请求头带上登录后拿到的token后端先用拦截器校验token是否有效再进入具体的ControllerService层处理业务逻辑Mapper层操作数据库需要频繁读取的数据先查Redis缓存处理完之后返回统一格式的JSON数据前端根据返回结果更新页面。这个链路里需要重点注意的是统一返回格式和全局异常处理。开源项目的代码质量参差不齐有些项目每个接口返回格式都不一样前端联调时非常痛苦。这套项目用了一个Result类做统一包装code0表示成功非0表示业务异常前端请求封装里只需处理这一种格式就行。如果你打算拿这个项目做二次开发建议保持这个约定加新接口时不要自创返回结构。1.3 源码里值得优先读的四个文件对于想通过这个项目学习的人来说不需要从头到尾读每一行代码先读四个关键部分就能快速上手application.yml了解端口、数据库连接、Redis配置、微信小程序appid和secret在哪里填。pom.xml确认依赖版本特别是Spring Boot版本和MyBatis-Plus版本是否兼容。pages.jsonuniapp端查看小程序页面路由、tabBar配置、分包结构。database.sql看表结构的完整程度表建得规范的商城项目二次开发会省很多事。把这四个文件看完基本就能判断这个项目值不值得继续投入时间。源码架构很清晰没有出现一个Controller里塞几千行业务代码的情况表结构也能覆盖商城常见的完整流程这一点对于后续改造非常关键。2. 技术选型背后的思考为什么是Java uniapp2.1 Java在商城项目里的天然优势很多刚入门的朋友会问做一个商城小程序后端为什么不用Node.js或者Python偏偏用Java在电商这个领域Java的生态沉淀是最深的。支付、物流、短信、OSS对象存储、消息队列所有第三方服务商提供的SDK基本都是Java优先适配版本稳定文档丰富。商城业务绕不开微信支付、支付宝支付、物流查询这些外部接口选一个生态成熟的生态能少踩很多隐形的坑。另外商城类项目是后端开发面试和毕业设计里出现频率最高的类型之一Spring Boot MyBatis-Plus MySQL这套组合本身就是Java后端岗位的日常。你能从这套源码里学到的分页查询、事务处理、接口鉴权、定时任务都是实打实能写到简历上的技能而不是花里胡哨的玩具代码。2.2 uniapp让一套代码多端运行前端选择uniapp而不是原生微信小程序最大收益是可以用一套代码编译到微信小程序、H5、App等多个平台。对于个人开发者或者小团队来说这是一个非常现实的需求小程序先上线之后想做个App或者H5商城同在uniapp工程里打包就行不用重新写一套。uniapp的语法基于Vue如果你会Vue上手几乎没有成本。它还提供了uni.request、uni.login、uni.requestPayment这些跨端API同一套逻辑在微信小程序里调用的是wx.login的底层能力但代码层面对开发者是统一的。商城项目里最常用的uni.requestPayment封装好了拉起微信支付的逻辑比自己直接调wx.requestPayment要省心一些。这套项目的前端工程是按Vue3 Vite来组织的状态管理用的是Pinia比老的Vue2 Vuex结构更现代。如果你之前只写过Vue2读这套代码前最好先补一下Vue3的setup语法不然会有阅读障碍。2.3 关键技术组件选型的取舍把后端依赖列表看一遍会发现很多组件选型都挺讲究的MyBatis-Plus而不是原生MyBatis单表查询不用写SQLBaseMapper直接提供增删改查对加快开发速度很有帮助。Redis的定位不是摆设登录token存Redis、商品详情缓存、购物车缓存都能找到实际用处而不是为了凑技术栈硬塞进去。JWT 拦截器做登录鉴权无状态、跨端方便小程序端拿到token后存到storage里每次请求放进Header携带。Lombok简化实体类代码实体类里不再堆大量getter/setter代码可读性明显提高。选型不是越新越好而是要看业务是否需要。这套项目没有堆砌微服务、消息队列、分库分表这些重技术因为一个小程序商城单体架构完全够用这恰恰是合理的架构判断。3. 核心业务模块拆解从商品到订单的状态流转3.1 数据库表设计的整体规划电商项目的核心在于表结构是否能支撑完整的业务闭环。这套项目的数据库脚本里我梳理了主要的业务表大致可以分成五个域域核心表作用用户域user、user_address微信用户信息、收货地址商品域category、goods、goods_sku、goods_spec分类、商品、SKU库存、规格参数订单域order、order_item订单主表、订单明细营销域coupon、user_coupon优惠券模板、用户领取记录支付域payment_log支付流水记录这套表的划分很规矩尤其是把goods和goods_sku分开而不是把库存简单塞在商品表里这是商城项目能不能支持多规格商品的关键。很多新手自己设计表时会忽略SKU这个概念导致商品一旦有多种规格比如颜色、尺码库存和价格就不知道存在哪。拆成SKU表之后每个规格组合都有自己的价格、库存、编码下单时锁定的也是SKU级别的库存。3.2 订单状态机商城系统最核心的逻辑订单表里的status字段是整个商城最核心的字段之一我对它的评价是订单状态设计好了订单流程就顺了一半。这套项目里的订单状态流转是这么设计的待付款0用户提交订单后生成此时库存被预占。已付款1微信支付回调成功后更新此时库存真正扣减。待发货2与已付款类似兼容货到付款场景时使用。已发货3商家在管理后台发货后更新需要回填物流单号。已完成4用户确认收货后进入流程结束。已取消5用户主动取消或超时未支付自动关闭。需要特别注意的是“预占库存”和“实扣库存”的区别。用户下单但还没支付时商品库存已经减少了这叫预占如果用户超时未支付订单取消预占的库存要释放回商品。如果预占和实扣只用一个库存字段就会出现“显示有货但实际支付后超卖”的问题。这套代码里通过Redis或数据库字段把这两类库存分开管理是值得学习的设计。-- 订单主表关键字段示例 CREATE TABLE order ( id bigint(20) NOT NULL AUTO_INCREMENT, order_no varchar(64) NOT NULL COMMENT 订单编号, user_id bigint(20) NOT NULL COMMENT 用户ID, total_amount decimal(10,2) NOT NULL COMMENT 订单总金额, pay_amount decimal(10,2) NOT NULL COMMENT 实付金额, status tinyint(4) NOT NULL COMMENT 订单状态, address_snapshot varchar(500) DEFAULT NULL COMMENT 收货地址快照, pay_time datetime DEFAULT NULL COMMENT 支付时间, cancel_time datetime DEFAULT NULL COMMENT 取消时间, PRIMARY KEY (id), KEY idx_user_id (user_id), KEY idx_order_no (order_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;address_snapshot这个字段也值得说一下下单时把收货地址完整拷贝一份存进订单而不是通过address_id关联查询。因为用户后续可能修改收货地址如果订单里不存快照商家发货时看到的可能就是用户新改的地址容易出纠纷。3.3 购物车与优惠券的真实实现逻辑购物车的实现采用Redis加数据库双写。用户加购时先写到Redis数据结构使用Hashkey是用户IDfield是SKU IDvalue是数量读取购物车列表时直接查Redis响应速度快。用户进入结算页时再把这些数据同步到后端生成订单。这种做法在小程序商城场景下很务实Redis写购物车能扛住高并发成本也低。优惠券模块相对独立核心是coupon和user_coupon两张表。coupon存券模板信息比如满减门槛、优惠金额、有效期user_coupon记录用户领取和是否已使用。结算时计算最优优惠券的逻辑是遍历用户拥有的可用券判断订单金额是否达到门槛能用的券里选择优惠金额最大的那张。这一步看似简单实际要处理“哪些商品参与优惠”“运费是否计入门槛”等细节源码里的实现逻辑完整可以直接复用。4. 前端uniapp实战在小程序端的适配与优化4.1 pages.json与tabBar的配置细节uniapp工程里pages.json相当于小程序原生开发的app.json页面路由、窗口样式、tabBar都在这一个文件里配置。商城项目常见的底部导航是首页、分类、购物车、我的四个入口对应四个页面{ pages: [ { path: pages/index/index, style: { navigationBarTitleText: 首页 } }, { path: pages/category/category, style: { navigationBarTitleText: 分类 } }, { path: pages/cart/cart, style: { navigationBarTitleText: 购物车 } }, { path: pages/user/user, style: { navigationBarTitleText: 我的 } } ], tabBar: { list: [ { pagePath: pages/index/index, text: 首页 }, { pagePath: pages/category/category, text: 分类 }, { pagePath: pages/cart/cart, text: 购物车 }, { pagePath: pages/user/user, text: 我的 } ] } }小程序主包体积有2MB限制通过分包可以扩展到20MB如果页面、图片、JS文件都堆在主包里很容易超限。这套项目的处理方式是把商品列表、商品详情、订单结算、支付结果这些非首页场景的页面放到独立分包里用户访问到对应页面时才下载分包资源首屏加载速度会明显提升。4.2 请求封装与登录态的自动处理前端所有接口请求都统一走封装好的request.js这一点对小程序项目尤其重要。小程序提供的wx.request是比较底层的API直接使用的话每个页面都要重复写请求成功失败的处理代码会非常冗余。封装一层之后至少可以统一解决三件事请求头自动携带token避免每个接口手动处理。统一处理HTTP 401状态码token过期时自动跳转登录页。统一处理业务错误码弹出提示信息并对特定错误码做特殊处理。// request.js 简化示例 const BASE_URL https://api.example.com export function request(options) { return new Promise((resolve, reject) { uni.request({ url: BASE_URL options.url, method: options.method || GET, data: options.data || {}, header: { Authorization: uni.getStorageSync(token), Content-Type: application/json }, success: (res) { if (res.statusCode 401) { uni.removeStorageSync(token) uni.navigateTo({ url: /pages/login/login }) return } if (res.data.code 0) { resolve(res.data.data) } else { uni.showToast({ title: res.data.msg, icon: none }) reject(res.data) } }, fail: (err) { uni.showToast({ title: 网络异常请稍后重试, icon: none }) reject(err) } }) }) }这个封装同时兼容了Promise风格页面里可以用async/await写异步逻辑不用再嵌套回调。我在二次开发时新增接口只需要在api目录下建一个模块把接口地址和参数类型统一管理起来代码结构非常清晰。4.3 商品详情页与SKU选择的交互实现商城小程序里交互复杂度最高的页面是商品详情页尤其是SKU选择器。用户点击“选择规格”弹层后需要展示不同规格组合的库存情况比如“红色 - L码有货”“蓝色 - M码无货”这种状态。这套项目里使用的方案是把SKU数据一次性返回前端前端根据用户选中的规格维度动态计算可选项是否可用。这里最容易出bug的是库存联动逻辑。简单的做法是拿到所有SKU列表后用选中的规格值做过滤但遇到多规格维度时计算量会膨胀。源码里做了一个折中提前把规格维度对应的SKU组合做映射用户每选中一个维度时根据映射表快速判断哪些选项可点哪些置灰。这个交互在真机上实测过响应速度很快用户连续点击规格时也不会出现卡顿。4.4 小程序端的条件编译与兼容性处理uniapp的一个强大特性是条件编译同一份代码里可以针对不同平台写差异化逻辑。商城项目里最典型的场景是支付调用微信小程序端调用uni.requestPaymentH5端可能要用uni.requestPayment配合对应的支付参数App端可能走的是App支付SDK。这套前端的做法是把这些平台差异收敛到单独的工具文件里业务页面只调用统一的方法页面代码不用到处穿插#ifdef判断。在联调阶段我发现一个小程序特有的坑真机调试时请求本机IP会失败因为微信开发者工具默认不校验合法域名但真机上小程序会校验request合法域名。解决办法是开发阶段在微信开发者工具里勾选“不校验合法域名”但真机上联调后端时必须把后端接口域名配成HTTPS的正式域名。这一点放到部署章节细说但在前端适配阶段就需要注意。5. 微信登录与支付对接最绕不开的两个环节5.1 微信登录流程的完整推导小程序商城的用户体系基本都建立在微信授权之上。前端调用uni.login拿到临时凭证code传给后端后端拿着code去微信接口换取openid和session_key然后根据openid查数据库用户存在就直接登录不存在就自动注册一个账号。这一步里有一个容易出错的设计不要把session_key存到数据库当成敏感凭证也不要把openid直接暴露给前端因为openid是用户在小程序里的唯一标识泄露了虽然风险不算特别大但也没有必要暴露。// 登录接口的简化逻辑 PostMapping(/login) public Result login(RequestBody LoginRequest request) { // 1. 调用微信 code2Session 接口获取 openid WxSession session wxService.code2Session(request.getCode()); // 2. 根据 openid 查询用户 User user userService.getByOpenid(session.getOpenid()); if (user null) { // 3. 新用户自动注册 user userService.register(session.getOpenid()); } // 4. 签发 token并缓存到 Redis String token tokenService.createToken(user.getId()); return Result.success(new LoginVO(token, user)); }开发阶段与微信登录相关的问题排查重点看日志里code2Session接口的返回。如果返回errcode非0常见原因是appid和secret不匹配或code被二次使用。code的有效期只有五分钟而且只能使用一次前端频繁刷新页面导致重复提交时就会出现二次使用报错代码里要加防重复提交处理。5.2 微信支付的完整链路与回调幂等小程序商城接入微信支付流程上可以拆成六个步骤用户在小程序端点击“立即支付”前端把订单号传给后端。后端根据订单号生成微信支付预付单调用微信支付的统一下单接口。微信返回prepay_id后端用该参数生成签名并返回给前端。前端拿到签名后的支付参数调用uni.requestPayment拉起微信支付。用户在微信里完成支付微信服务器异步通知后端回调地址。后端收到回调后验签、更新订单状态、发货准备。这里最需要小心的是第6步很多新手第一次做支付时都会在这里栽跟头。微信的回调可能会重复推送多次如果后端在回调里不做幂等处理同一个订单被回调两次订单状态被覆盖还是小事严重的情况是重复发货、重复发优惠券。所以回调代码里第一步就是查订单状态——如果已经是已支付状态直接返回success不再执行后续更新逻辑。// 支付回调处理简化 PostMapping(/wx/pay/notify) public String payNotify(RequestBody String xmlData) { // 1. 验签确认是微信官方回调 boolean signOk wxPayService.verifySign(xmlData); if (!signOk) { return failure; } // 2. 解析出订单号和实付金额 PayNotifyData data wxPayService.parseNotify(xmlData); Order order orderService.getByOrderNo(data.getOrderNo()); // 3. 幂等判断订单已支付过直接返回成功 if (order.getStatus() OrderStatus.PAID) { return success; } // 4. 校验金额是否一致防止恶意回调 if (order.getPayAmount().compareTo(data.getAmount()) ! 0) { return failure; } // 5. 更新订单状态执行扣减库存、发送通知等 orderService.paySuccess(order); return success; }回调接口返回给微信的内容也有讲究。处理成功要返回字符串success处理失败返回failure微信会在一定时间内重新回调失败的通知。如果业务处理逻辑耗时较长可以先把回调数据确认收到再异步执行订单更新避免回调接口超时被微信反复重试。5.3 支付配置中容易出现的三类问题支付对接过程中我整理了一下最容易踩的坑大致是这三类金额单位问题微信支付以“分”为单位数据库里如果存的是“元”下单前必须乘以100转换成整数分。前后端之间传递时也要统一约定否则会出现用户支付0.01元实际金额变成0.0001元的怪事。证书与密钥配置微信支付APIv3需要配置商户私钥、商户证书序列号、APIv3密钥这三个配置错一个下单接口就会报错。而且证书文件不要直接放到代码仓库里要用环境变量或配置中心管理。回调地址问题回调地址必须是公网可访问的HTTPS地址不能被防火墙拦截。本地联调测试支付时可以通过内网穿透工具暴露本地端口但上生产环境一定要换成正式域名。小程序里还有一个与支付相关的平台规则要特别注意个人主体的小程序很多类目不具备开通微信支付的条件企业主体或个体工商户才能申请微信支付商户号。做项目之前先确认主体资质否则开发完成后发现支付开通不了返工成本极高。另外小程序平台对虚拟商品的支付有限制实物电商是没问题的但如果你的商城卖的是充值、课程这类虚拟商品涉及虚拟支付规则要提前看清楚类目要求。6. 部署上线从本地跑通到小程序过审6.1 服务器选型与环境准备商城项目部署到生产环境我推荐最低配置是2核4G的云服务器带宽按需购买地域选择离用户近的节点。有人觉得1核2G也能跑但如果后面要接图片存储、日志收集配置太低会频繁出问题。操作系统用LinuxCentOS或Ubuntu都行部署方案以Docker为主。需要准备的环境包括Docker和Docker Compose、MySQL 8.x、Redis、Nginx以及一个已经备案的域名和HTTPS证书。HTTPS证书可以用云服务商提供的免费证书有效期一般是一年。这里要专门提醒微信小程序要求所有请求域名必须是HTTPS而且需要在微信公众平台配置到“request合法域名”列表里没有HTTPS证书的小程序接口会被直接拦截。6.2 Docker方式部署后端服务用Docker部署Java后端相对简单。编写Dockerfile把项目打成JAR包放进镜像再配合docker-compose.yml把MySQL、Redis、后端服务编排起来一条命令就能完成启动。数据库脚本在第一次启动时手动导入即可不建议让容器启动时自动执行初始化因为容易重复执行。# docker-compose.yml 简化示例 version: 3.8 services: mysql: image: mysql:8.0 container_name: mall-mysql environment: MYSQL_ROOT_PASSWORD: your_password MYSQL_DATABASE: mall ports: - 3306:3306 volumes: - ./mysql-data:/var/lib/mysql redis: image: redis:7 container_name: mall-redis ports: - 6379:6379 backend: build: . container_name: mall-backend ports: - 8080:8080 environment: - SPRING_PROFILES_ACTIVEprod depends_on: - mysql - redisapplication-prod.yml里需要修改数据库地址、Redis地址、微信支付密钥等生产配置。不要把生产环境的密码硬编码在代码里用环境变量注入更安全。JAR包打包时建议用Maven的package命令配合skipTests跳过测试打完包后检查target目录下生成的JAR大小是否正常有些依赖冲突会导致JAR包启动时直接抛异常。后端启动成功后用curl请求一个健康检查接口确认接口能通再进入Nginx配置反向代理。Nginx需要把/api路径转发到后端8080端口同时配置HTTPS证书实现HTTP自动跳转HTTPS。生产环境的请求链路是小程序 - HTTPS域名 - Nginx - 后端服务。6.3 小程序端的上传与审核注意事项小程序前端开发完成在HBuilderX里点击“发行 - 小程序-微信”会生成一个微信开发者工具可识别的目录。用微信开发者工具打开后把request合法域名、uploadFile合法域名都配置到微信公众平台然后提交代码上传。小程序审核是很多新手容易卡壳的地方。根据我提交的经验有几点要提前处理确保小程序里没有明显的测试数据商品图片、商城名称、客服电话都要换成真实内容不要在小程序里出现“测试”“demo”字样审核人员会认为项目不完整如果涉及电商交易要确保商品信息、售后说明等页面能正常展示。首次提交审核一般需要1到7天不等产品类目不对会被直接打回提交前仔细核对服务类目是否和自己的营业执照经营范围匹配。关于Web-Viiew内嵌H5页面如果小程序里用了web-view组件也要保证加载的网页是HTTPS且域名备案。有些开发者为图方便把小程序的商品详情页用H5页面代替这在审核阶段容易因为“页面显示不完整”被打回建议核心页面还是用原生页面实现。6.4 上线后的监控与订单对账上线不等于结束商城系统跑起来之后最重要的是监控和订单对账。至少要做到三件事每天检查支付回调日志确认所有已支付订单的状态都正确更新定时任务补偿未处理的回调。配置简单的日志监控Java服务异常日志通过日志文件或日志平台收集出现ERROR级别日志及时处理。对账库存定期把订单表里的商品销售数量与商品SKU表的库存扣减做对比发现不一致时排查并发和超卖问题。微信支付商户平台本身有交易账单下载功能我建议每周下载一次账单与本地订单表做一次比对保证线上订单数据和支付平台数据一致。商城项目的资金链路是核心宁可多花时间对账也不要等问题恶化。7. 从开源到自用二次开发的改造思路与避坑清单7.1 快速改造的第一步改名与换肤拿开源项目做二次开发第一个要改的是身份信息。后端搜索所有跟项目名相关的包名、类名、数据库库名并替换掉小程序端的appid改成你自己的管理后台登录页、Logo、商城名称全部换成自己的品牌。这一步看起来简单实际操作时容易漏掉配置文件和数据库脚本里的硬编码。不建议大面积重构代码先跑通现有流程再逐模块改造。最合理的顺序是先本地把用户登录、商品浏览、购物车、下单、支付这条核心链路完整跑通确认没有潜在问题再开始改商品管理后台、增加新的营销功能。很多二次开发失败不是因为代码质量差而是因为一上来就想改架构改到一半发现跑不通了。7.2 功能扩展从基础商城到营销体系业务跑起来之后常见的扩展方向有几个拼团、秒杀功能需要重新设计活动表和库存扣减逻辑秒杀场景要引入Redis预扣库存和限流比普通下单复杂不少。分销裂变体系增加分销商表和佣金结算逻辑涉及资金分账需要谨慎设计。消息推送接入微信订阅消息订单状态变更时主动推送给用户能显著提升用户体验。商品多图与视频把图片服务器换成对象存储OSS并接入CDN加速商品大图和小图分开管理。这些扩展里分销和秒杀最考验对原有订单流程的理解。如果基础订单状态机设计得合理扩展活动订单时只需要新增活动类型字段不用改动太多底层逻辑。7.3 我实际遇到的坑与解决办法最后把我个人动手过程中踩过的一些坑列出来供你参考商品图片不显示检查图片域名有没有加到小程序的downloadFile合法域名同时图片链接必须是HTTPS。这个排查顺序很快但很多人会忽略配置项。订单提交后库存没变化确认事务是否生效。Transactional放在Service方法上注意异常要被Spring事务管理器感知如果业务代码里把异常try-catch吞掉了事务不会回滚。Redis连接超时导致接口变慢Redis的连接池参数需要调整生产环境不要用默认配置设置合理的最大连接数和超时时间。token过期后前端没有跳登录页检查请求封装里是否对HTTP 401做了统一处理跳转后要清理本地的用户信息避免下次进入商城时还显示“已登录”的假状态。上传商品图片到管理后台后小程序看不见管理员后台上传的图片路径可能与小程序访问的域名不一致统一存到对象存储并配置好自定义域名即可。这套项目跑下来我最深的体会是好的开源商城项目不是代码写得多炫酷而是把电商这条核心链路用最朴素的方式落地清楚了。无论你是想学Java后端、想学uniapp前端还是需要一个可以二次开发的商城底座拿这套源码从头到尾跑一遍都能收获很多线上文档里学不到的实战经验。最后补充一个小技巧二次开发时尽量保持后端接口的兼容性不要随意删除或修改已有接口的请求参数和返回结构前端uniapp工程里用到的接口很多动不动就容易改一处崩全局稳扎稳打才能把项目真正变成自己的东西。本文还有配套的精品资源点击获取