简介：基于SpringBoot与uniapp构建的商城项目资源包，面向有一定Java基础和Vue.js认知、希望系统学习前后端分离开发的开发者。项目参考linjiashop开源商城设计，后端以SpringBoot为骨架，涵盖业务逻辑处理、RESTful API接口定义、JPA/MyBatis数据库访问；前端用uniapp搭建商品列表、购物车、订单管理等跨端页面与交互。资源共67个文件，以60个java源文件为主，配合3个xml配置、2个yml配置、1个gitignore和1个md说明文档，压缩包约64KB，目录结构清晰，便于按模块阅读与二次开发。已有1938人学习下载，可用于毕设选题、课程设计或企业级Web/移动端项目的实战参考。通过阅读源码与配置，可掌握SpringBoot自动配置、注解驱动控制器、uniapp生命周期与组件化开发等关键技术，还能借鉴数据库设计、权限控制、安全防护与性能优化等落地思路，无论用于入门进阶还是项目落地都有实用价值。 如果你正在计划一个 shop 商城项目，技术选型锁定 SpringBoot + uniapp，这事我太熟了。我最近刚把一套完整商城从零搭到上线，商品、购物车、订单、支付、多端打包全走了一遍，这篇文章就把我实际验证过的方案和踩过的坑整理出来，重点是那些文档里不会告诉你的细节。
这个项目能做什么，一句话说清楚：后端用 SpringBoot 提供接口，前端用 uniapp 一套代码同时跑微信小程序、H5 和 Android/iOS App，覆盖商城最常见的完整闭环。适合谁参考？准备做毕业设计、接外包、或者公司要从零起一个中小型电商项目的开发者，都可以直接照着搭。
1. 项目整体架构设计思路
1.1 为什么选 SpringBoot + uniapp 这套组合
先说选型。商城项目后端可选的东西不少，我当时直接定了 SpringBoot，原因很朴素：生态太成熟了。从数据库连接、缓存、权限、文件上传到支付对接，基本都有现成的 starter，自动装配机制帮我把大量 bean 的注册和配置都处理好了，我只需要关心业务代码。SpringBoot 的社区也大，开发中遇到的任何一个报错，几乎都能搜到案例，这对个人开发者非常友好。以后如果量大了要拆服务，Spring Cloud 那一套也能平滑接过来，不用推翻重写。
前端选 uniapp，核心诉求就一个：多端复用。商城项目的典型投放渠道是微信小程序、公众号 H5、App，要是每个端各写一套，光维护成本就能拖垮项目。我用下来的体感是，大概 80% 的页面三端完全通用，剩下 20% 用条件编译处理差异就够。比如支付调用方式、分享逻辑、更新提示这些，本来就该按端区分，uniapp 提供了#ifdef MP-WEIXIN这类预处理写法，一套代码里做分支，不用维护多套工程。
这里必须给个实话：如果你只做微信生态，原生小程序也是一个选项，但对后端出身、主要熟悉 Vue 的开发者来说，uniapp 的学习路径明显更平缓，还有丰富的插件市场可以抄作业。技术选型要结合自己的基础，不要盲目追新。
1.2 商城模块划分与数据库设计
商城项目看着大，拆开其实就是两块：用户侧与管理侧。用户侧负责首页、分类、商品详情、购物车、订单、支付、个人中心、收货地址；管理侧负责商品管理、订单管理、用户管理、轮播图管理、分类管理。个人项目不用一来就把权限系统做得很重，能用岗位区分管理员和普通用户就够了，先把业务闭环跑通。
数据库设计我直接列一份核心表结构，给还没动手的人参考：
| 表名 | 用途 | 核心字段 |
|---|---|---|
| user | 用户表 | id、nickname、avatar、phone、password、openid |
| category | 分类表 | id、name、sort、icon |
| product | 商品表 | id、title、main_image、price、stock、status |
| product_sku | 商品规格表 | id、product_id、spec_name、price、stock |
| cart | 购物车表 | id、user_id、product_id、sku_id、count、checked |
| orders | 订单表 | id、order_no、user_id、total_amount、status、address_id |
| order_item | 订单明细表 | id、order_id、product_id、sku_id、price、count |
| payment | 支付流水表 | id、order_id、transaction_id、amount、status |
| address | 收货地址表 | id、user_id、name、phone、province、city、detail |
| banner | 轮播图表 | id、image、link、sort |
设计时有两个点最容易被新手忽略。第一个，只要商品有规格概念（比如颜色、尺码），价格和库存就必须放在 sku 表而不是商品主表上，否则后面下单、秒杀、库存统计全都别扭。第二个，金额字段一律用 decimal，别用 double，浮点运算的精度问题在前端展示和后端对账时会让你抓狂。这两条做到，能少踩无数坑。
1.3 版本选型：SpringBoot 选 2.7 还是 3.x
这节单独拎出来说，因为很多人第一个坑就栽在版本上。热词里那个“springboot版本太高”基本就是这么来的：网上教程用 3.x，但你本地是 JDK 8，项目根本起不来。SpringBoot 3.x 强制要求 JDK 17，如果你没有升级 JDK 的打算，老老实实用 2.7.x 配 JDK 8，非常稳。
我自己用的组合是 SpringBoot 2.7.18 + JDK 8 + MyBatis-Plus 3.5.x + Redis + JWT。不是 3.x 不好，而是 2.7.x 对第三方 starter 的兼容性经过了大量验证，特别是对接老的支付 SDK、短信 SDK 时，踩坑成本低得多。uniapp 那边我选了 Vue3 版本，语法更现代，但市面上很多教程和插件还是 Vue2 写法，看资料的时候注意区分，别被绕晕。
2. 后端核心细节解析
2.1 项目初始化与目录分层
SpringBoot 项目用 IDEA 初始化很简单，选 Spring Initializr 就行。目录结构我建议按经典分层来建，简单直接，个人项目完全够用：
com.example.shop ├── controller # 接口层 ├── service # 业务层 ├── mapper # 数据访问层 ├── entity # 数据库实体 ├── dto # 传输对象 ├── vo # 视图对象 ├── config # 配置类 ├── common # 统一返回、异常处理 └── utils # 工具类我不建议一上来就上 DDD 或复杂的分层框架，那会把简单问题复杂化。这不是说分层思想不重要，而是商城项目初期最重要的是把接口快速跑通，等到业务确实膨胀了再调整架构，完全来得及。我见过太多人把时间耗在架构设计上，结果两个月还没跑通一个完整下单流程。
还有一件事真的很重要：写任何接口前，先定义统一返回结构。我习惯用Result<T>包一层，包含 code、message、data 三个字段，再加一个全局异常处理器。商城项目接口数量非常多，前后端联调时统一返回结构能省掉大量无意义沟通。前端只需判断 code 就能决定是否弹提示，不用每个接口单独处理错误逻辑。
2.2 登录鉴权与 Token 机制
商城登录常见有两种方式：手机号验证码登录、微信小程序授权登录。我的建议是两个都做，后端通过前端传的 loginType 字段来区分。手机号登录走短信验证码，小程序登录用 wx.login 拿到的 code 向后端换 openid，然后再走同一套 token 签发逻辑。
登录成功之后，我会签发一个 JWT 返回给前端。要注意一个关键点：token 本身有过期时间，但用户逛商城可能会很久，如果过期时间太短，体验极差。我的做法是额外把 token 存一份到 Redis，设置更长的过期时间，然后用拦截器在每次请求时刷新这个过期时间。用户只要一直在操作，就不会掉线；真正长时间离开后再回来，Redis 里的 key 也过期了，重新登录即可。
拦截器这边我要特别提醒：鉴权逻辑要简单，只做“解析 token、校验有效性、放行或拦截”。用户信息解析出来之后放进 ThreadLocal，供后续业务代码读取，用完在 afterCompletion 里一定要清理。不清理的话，Tomcat 线程池复用时会出现用户数据串号的问题，这种 bug 极其隐蔽，排查起来非常头疼。
2.3 商品与订单的库存扣减
订单流程是商城最核心的链路。完整流程是：用户提交订单 → 校验商品状态和价格 → 扣减库存 → 生成订单和明细 → 支付 → 支付回调更新状态。这里最容易出问题的就是库存超卖。多线程同时下单时，如果先查库存再减库存，两个请求都查到库存还有 1 件，就会同时下单成功，库存变成 -1。
我之前踩过这个坑，后来换成在 SQL 语句里做原子扣减：
UPDATE product_sku SET stock = stock - #{count} WHERE id = #{skuId} AND stock >= #{count}这条 SQL 自带条件检查，stock >= #{count}不满足时受影响行数为 0，业务层捕获后直接提示库存不足。不需要分布式锁，也不需要 Redis 预减，对于商城初期流量完全够用。等哪天并发量真的大了，再考虑 Redis 预减库存 + 消息队列异步扣减的方案，不要提前把系统搞复杂。
订单状态我用枚举来管理，而不是散落一地的魔法字符串。商城订单状态基本是：待支付 → 已支付 → 已发货 → 已完成，中途可以有取消和退款分支。每个状态对应什么操作、哪些状态可以流转到哪些状态，集中写在枚举或状态机里，代码可读性和维护性会好很多。
2.4 支付对接与回调幂等
我接的是微信支付，uniapp 的 H5、小程序、App 端拉起支付的方式不同，但后端逻辑是一致的：统一下单拿到支付参数 → 前端拉起支付 → 用户支付 → 微信服务器异步回调通知后端 → 后端更新订单状态。
支付这块最大的坑在回调处理。微信官方文档说得很清楚，回调通知可能会重复发送，所以后端必须做幂等处理。我的实现是：回调进来之后，先查订单当前状态，如果已经是已支付，直接返回成功响应，不再重复处理业务逻辑。同时，回调处理里的逻辑要尽量精简，先把状态更新掉，再去做后续的发货提醒、积分赠送之类的附加操作，避免回调接口超时被微信重试轰炸。
还有一个小细节：微信支付要求的回调响应格式是特定 XML 结构，错了会被判定为通知失败，然后一直重试。我见不少人卡在这，其实就是返回体没写对。支付对接完一定要用微信官方提供的沙箱环境多测几遍，覆盖正常支付、取消支付、支付金额不对、重复回调几个场景。
3. 前端 uniapp 端实现要点
3.1 页面结构与路由设计
uniapp 的项目结构很清晰，pages 目录下放页面文件，pages.json 里注册路由和 tabBar。商城标配的四个 tab 是首页、分类、购物车、我的，tabBar 图标要用 png 格式，建议尺寸 81px 以上的 2 倍图，否则真机上会糊。
页面生命周期这块我必须强调一下，因为几乎每个新手都会踩：uniapp 的页面生命周期和 Vue 组件生命周期不是一回事。onLoad只在页面首次加载时执行一次，适合拉取初始数据；onShow每次进入页面都会触发，适合做数据刷新。我之前做“从详情页返回列表，列表数据不更新”的功能时，就是把刷新逻辑写在了onLoad里，改成onShow之后问题立刻解决。
3.2 请求封装与登录态管理
我习惯在 utils 里封装一个 request.js，基于uni.request做一层包装。统一设置 baseURL、请求头、超时时间，响应回来统一处理 code，错误统一弹 toast。这样做的好处是，业务页面里永远只需要写业务代码，不用重复关心 loading、错误提示、token 过期这些琐事。
token 存储在uni.setStorageSync，请求拦截器里从本地读取并塞到 header 的 Authorization 字段。如果接口返回 401，清除本地登录信息，跳转登录页。这里有个细节：token 过期跳转登录页之后，用户登录成功应该回到原来想访问的页面，而不是固定跳回首页。所以跳转前先把当前页面路径存下来，登录成功后用uni.redirectTo回去，体验会好很多。
3.3 购物车与下单交互
购物车数据放服务端还是本地，是一个需要想清楚的决策。我的方案是：登录后购物车数据全部走服务端接口，保证多端同步；不登录时允许加购物车但只存本地，登录成功后做一次合并。这个逻辑稍微复杂，但电商产品基本都这么做，因为用户可能会在手机 App 加购、在微信小程序里下单，购物车必须跟账号走。
下单交互环节比较关键的是：前端点击立即购买时，不要把商品原价、总价算完传给后端就完事。可靠的方案是前端只传商品 skuId、数量、收货地址 id，价格一律由后端实时计算。这样既防止用户篡改价格，也保证优惠活动逻辑统一在后端维护。调试这个环节要特别细心，前后端的价格对不上是联调时最高频的问题。
3.4 多端打包与上架经验
uniapp 的多端打包流程，我按端说：H5 最简单，HBuilderX 里发行到 H5 就能产出静态文件；微信小程序在 HBuilderX 里运行到小程序模拟器，然后在微信开发者工具里上传；App 则分云打包和本地打包，云打包方便快速，但需要自己准备证书。
Android 上架应用市场这块，热词里好多人问，我多说几句。上架到华为、小米、OPPO、VIVO 等应用商店，需要准备的东西基本一致：软著、隐私政策、应用签名、截图。隐私政策特别容易出问题，应用里只要收集了用户任何信息，都必须有对应说明，很多 App 被驳回就是因为隐私政策写得含糊或没有弹窗告知。建议在项目开发阶段就把隐私弹窗加上，别等到审核被拒再改。
iOS 打包需要开发者账号，个人账号 $99/年，打包流程比 Android 麻烦，但 uniapp 已经帮我们处理了大部分工作量。如果只是测试，可以用 HBuilderX 的真机运行，不需要证书也能装到自己的手机上。
4. 常见问题与排查技巧实录
4.1 SpringBoot 版本太高项目跑不起来
遇到这个问题的朋友，十有八九是下到了一个 3.x 的项目模板，但本机 JDK 还是 8。排查方法很简单：先看自己的 JDK 版本，java -version，再在 pom.xml 里看 spring-boot-starter-parent 的版本号。如果不对齐，要么换 JDK 17，要么把 SpringBoot 版本改成 2.7.x。我自己的选择是改版本，因为第三方 SDK 的兼容性要考虑，JDK 8 在中小企业里还是绝对主流。
还要注意数据库驱动问题。SpringBoot 2.7.x 配合 MySQL 5.7 或 8.0 都没问题，但连接 MySQL 8 时必须使用com.mysql.cj.jdbc.Driver，并在 URL 里加上时区参数serverTimezone=Asia/Shanghai，否则会报时区相关错误。
4.2 uniapp 下拉刷新与页面滚动冲突
热词里这个问题问得很多：下拉刷新时，页面上的滚动内容也跟着动，体验很差。其实这是滚动穿透问题。我的处理思路是：只在必要的页面开启enablePullDownRefresh（比如首页和订单列表），其他页面统一用 scroll-view 内部滚动。如果某个页面既需要下拉刷新，内部又有可滚动区域，那就在 scroll-view 上设置refresher-enabled而不是用页面级下拉刷新，这样滚动容器和刷新手势就不会打架。
4.3 webview 白屏与 renderjs 视频播放问题
webview 打开白屏，最常见的两个原因：一是加载的 URL 是 http 而 App 强制 https，导致被系统拦截；二是 webview 页面配置了web-view组件但网络域名没有在后台配置合法域名。排查建议先看 console 输出和客户端日志，确认是被拦截还是路径错误。
renderjs 录制的 mp4 在手机上无法播放，这个问题我也遇到过。renderjs 虽然能和 dom 通信，但用它获取录屏数据生成的文件，在部分 Android 机型上存在编码兼容性问题。建议优先用原生拍摄或系统录屏能力，如果必须用 renderjs，视频文件生成后检查编码格式，必要时用工具转成 h264 编码的 mp4，兼容性会好很多。
4.4 页面找不到与其他编译报错
error: not found: page这个报错很直白：pages.json 里没有注册这个页面路径，或者路径写错了。uniapp 的路由是页面化的，新增页面必须到 pages.json 里注册，这个是新手最容易犯的错。另一个常见问题是有些页面没改 pages.json 直接删掉了，启动时也会报找不到页面。
组件生命周期和页面生命周期混用是另一个高频问题。onLoad、onShow、onReady是页面级，mounted、created是组件级。在组件内部想监听页面显示事件，用onShow是拿不到的，需要配合uni.$on或自定义事件。理解了这一点，类似的诡异问题基本都能自己排查。
5. 实际操作后的一些体会
项目全部跑通之后，我最大的体会是：商城项目最大的成本不在写代码，而在前后端联调和多端适配。如果你是自己一个人做全栈，建议先把后端接口用 Postman 全部测一遍，再动前端，否则两边同时出问题，排查难度会翻倍。
另外，我强烈建议在开发初期就把日志规范做好。后端统一 logback 配置，输出到文件；前端在 request.js 里加上请求日志。别小看这件事，上线后用户反馈问题，你回查日志能少走很多弯路。我后来排查支付回调漏单，就是靠日志对比才把问题定位到数据库连接池配置上。
如果你想在这个项目上继续延展，可以考虑的方向很多：增加秒杀功能、接入优惠券系统、做用户积分体系、把管理端改为独立后台管理系统。底子打好了，这些模块本质上都是往现有框架上挂新业务表和新接口。商城项目最迷人的地方就在这里：看起来庞杂，但每块都能拆开做深，做完一个收获是全栈的。
本文还有配套的精品资源，点击获取
