做手机商城系统这种项目圈内人都明白真正的难点从来不在增删改查而在订单、库存、支付这几个核心环节怎么设计得稳、可扩展、好维护。“欢迪迈手机商城”这个项目属于典型的 SpringBoot Vue MyBatis MySQL 全栈电商系统从源码结构来看它几乎把所有商城该有的模块都覆盖了用户、商品、分类、购物车、订单、后台管理、权限控制。对于正在学 Java 全栈的人、准备做毕业设计的同学、或者刚进公司需要接手电商系统的新人来说这套源码的参考价值非常高。下面我以实际开发者的视角把这个项目的设计思路、关键实现、运行部署、避坑经验完整拆解一遍尽量做到不只讲“怎么跑起来”更讲清楚“为什么这么设计”。1. 整体设计思路先搞清楚这个商城到底解决了什么问题1.1 技术选型背后的考量先看技术栈SpringBoot Vue MyBatis MySQL。这套组合在中小型电商项目里极其常见属于那种“稳得不能再稳”的方案。SpringBoot 负责后端接口服务和业务逻辑它的核心价值是“约定大于配置”能让我们少写大量 XML 配置专注业务代码。Vue 负责前端页面渲染和交互前端采用组件化开发像轮播图、商品卡片、购物车列表这些都能拆成独立组件。MyBatis 负责数据库访问层相比 JPA 那种全自动 ORMMyBatis 的半自动特性非常适合电商这种 SQL 复杂度高、需要人工调优的场景。MySQL 负责数据持久化配合 InnoDB 引擎支持事务、行级锁这是订单和库存业务的基础保障。为什么会选 MyBatis 而不是 Spring Data JPA我做过的几个商城项目里MyBatis 的优势体现在很实际的场景一是“多表联查可控”比如订单列表要 join 用户表、订单明细表、商品表SQL 写出来是什么性能、怎么走索引一眼就能看懂二是“复杂 SQL 灵活扩展”比如商品搜索要拼接动态条件MyBatis 的if、where标签处理起来非常顺手三是团队协作时SQL 和 Java 代码分离后期调优直接改 XML不需要重新编译。JPA 在简单 CRUD 上确实省事但一旦涉及复杂报表、多条件查询调试的挫败感会非常强。1.2 前后端分离与分层设计这个项目是严格的前后端分离架构。后端提供 RESTful API前端通过 HTTP 请求获取 JSON 数据渲染页面。前后端分离最大的好处是“互不拖累”前端可以用 Mock 数据先开发页面后端可以先用接口测试工具调试逻辑最后联调时只需要保证字段一致。后端本身按照经典的三层架构设计Controller 层负责接收请求、参数校验、返回统一格式的响应体。这里要注意Controller 里不要写业务逻辑只做“翻译”工作。Service 层负责业务逻辑比如下单时的库存校验、购物车价格计算、订单状态流转。Service 层是事务的边界也是单元测试的重点。Mapper 层对应 MyBatis 的 Mapper 接口所有 SQL 都写在 XML 文件里通过接口与 Java 代码绑定。参数传递、结果映射都在这一层处理。这种分层说白了就是把“在哪里做什么”分清楚不然项目到后期就是一团乱麻。我见过很多单体项目Controller 里直接写 JDBCService 里又放了一堆查询语句最后改一个需求所有层都要动一遍。分层设计的一个直观好处是“替换成本低”比如未来想换从 MySQL 到其他数据库大概率只需要重写 Mapper 层的 SQL 映射文件其他的动得很少。1.3 完整目录结构与模块定位从源码的包结构来看项目按业务模块分包这种分包方式比按“Controller/Service/Entity”三大层分包要清晰很多。com.huan.dimai.mall ├── common // 通用模块工具类、统一返回、异常处理 ├── config // 配置类拦截器、跨域、静态资源配置 ├── controller // 控制层各模块的 REST 接口 ├── service // 业务层接口和实现类分开 ├── mapper // 持久层Mapper 接口 ├── entity // 数据库实体 ├── dto // 数据传输对象接收前端参数 └── vo // 视图对象返回前端数据我给一个建议查看源码时不要从 Controller 开始看而是先看数据库表设计文档再看 Mapper 层 SQL最后看 Service 层。因为数据是怎么流转的、表之间怎么关联的都在 SQL 里体现得最清楚。Controller 反而只是表面的东西看多了你会发现大部分接口都长得差不多。2. 数据库设计就是商城的命根子2.1 核心表结构从商城业务反推表设计手机商城这个业务核心流程就是用户登录 → 浏览商品 → 加入购物车 → 确认订单 → 支付 → 查看订单。围绕这个流程数据库表至少要有这些表名核心字段作用说明用户表id、username、password、phone、avatar前台登录用户的基础信息商品分类表id、category_name、parent_id手机品牌/类型分类支持多级商品表id、product_name、price、stock、description、image商品基础信息与库存商品图片表id、product_id、image_url、sort一个商品多图用于轮播展示购物车表id、user_id、product_id、quantity记录用户未下单前的选择订单表id、order_no、user_id、total_amount、status、pay_time订单主表状态流转核心订单明细表id、order_id、product_id、product_name、price、quantity下单时的商品快照管理员表id、username、password、role后台管理系统登录这里面有一个特别容易忽略的点订单明细表里的 product_name 和 price 字段必须保存“下单那一刻的数据快照”而不是通过 product_id 去实时关联商品表。道理很简单手机的价格会波动如果商家把价格调高了用户已下的订单却应该保持原价商品如果下架了用户的订单历史里也应该能显示出当时买了什么。很多初学者设计表的时候为了“省事”明细表里只放 product_id等到做订单详情页时再去查商品表结果价格对不上、商品没了记录非常尴尬。2.2 状态字段与订单状态机设计订单状态、支付状态这类字段项目里通常用 tinyint 类型存数字对应关系集中在代码的枚举类里管理。比如订单状态可以定义0待支付1已支付/待发货2已发货3已收货4已取消5已退款这里建议直接用数字而不是字符串原因有两个一是存储空间小查询效率高二是防止中文描述在前后端交互时产生编码或歧义问题。数字的含义由后端接口文档说明前端只需要展示时做一个映射即可。订单状态机是整个项目里最容易出 bug 的地方。最典型的坑是——“从待支付直接变成已完成”的非法流转。如果代码里没有做状态校验用户调一下接口就能把订单状态改掉这在电商业务里是严重事故。合理的实现方式是 Service 层写一个“状态变更校验”只有允许流转的状态才能更新比如待支付→已支付已支付→已发货已发货→已收货。2.3 索引设计怎么加才不浪费商城系统一旦数据量上来查询性能基本都靠索引撑。商品表的category_id、订单表的user_id和order_no、购物车表的user_id都必须建索引。order_no这种单号字段建议建唯一索引既保证订单号不重复又能在按单号查询时快速命中。一个容易犯的错是给“性别”“状态”这种低区分度的字段也建索引。比如订单状态只有 0~5 六个值建索引后查出来的数据还是占全表很大比例MySQL 可能直接放弃索引走全表扫描索引反而白占空间。真正需要重点索引的是“高区分度、高频查询”字段比如user_id status做联合索引能直接覆盖“查某用户的订单列表”这个高频场景。3. 后端核心模块实现从登录到下单的完整链路3.1 登录鉴权JWT 的用户身份传递机制商城系统里前台用户和管理员都需要登录但权限肯定不同。项目里常用的做法是基于 JWT 的无状态鉴权方案。基本流程是这样的用户登录时后端校验用户名和密码成功后生成一个 JWT token 返回给前端。前端把 token 存在本地存储里每次请求时在 Authorization 请求头中带上。后端有一个拦截器专门拦截需要登录的请求从 token 中解析出用户信息放行或拒绝。前端请求头 Authorization: Bearer eyJhbGciOiJIUzI1NiJ9...拦截器里做的是三件事一是检查 token 是否存在不存在直接返回 401二是解析 token 是否过期或非法解析失败也返回 401三是把解析出来的用户名或用户 id 存入请求上下文方便后续业务逻辑直接用。这一步很关键不然每个 Controller 里都得重复做一次 token 解析。JWT 这种方案的好处是后端不用存 session服务重启后用户登录状态依然有效水平扩容时也不需要额外做 session 共享。但要说清楚它的局限token 一旦签发在有效期内没法主动让“某用户下线”所以如果要做“强制退出”功能就得引入额外的黑名单机制。对于这个商城项目JWT 的默认有效期通常设置 2 到 7 天已经够用了。有些源码会区分前台用户和管理员两套 token我这里更建议用同一套 JWT 机制但用户表和管理员表分开token 里用 role 字段区分身份。这样拦截器可以统一处理只是针对后台管理的接口额外校验 role 是否匹配。3.2 MyBatis 分页查询别被 PageHelper 坑了商品列表、订单列表肯定要分页项目里主流方案是 PageHelper。它的原理是拦截 Mapper 接口的调用在执行 SQL 之前自动生成一条 COUNT 查询和一条带 LIMIT 的分页查询。用起来很简单PageHelper.startPage(pageNum, pageSize); ListProduct productList productMapper.selectProductList(); PageInfoProduct pageInfo new PageInfo(productList);PageHelper 的坑在于“侵入性太强”。一旦你在某个查询方法里调用了PageHelper.startPage()紧接着的“第一条查询语句”就会被分页不管那条语句是不是你想分页的。如果方法里前面做了其他查询比如先查分类再查商品列表那么分页就会加在分类查询上结果数据错乱还不报错调试起来非常头疼。我的建议是分页查询方法里只写一条查询主语句不要混入额外查询更不要在一个方法里多次调用 startPage。如果想做得更稳可以直接手写 LIMIT用 PageHelper 只是为了少写几行 SQL不要为了省这几行代码反而埋了坑。手写分页 SQL 其实也很简单SELECT * FROM product WHERE category_id #{categoryId} ORDER BY create_time DESC LIMIT #{offset}, #{pageSize}3.3 购物车与下单链路事务保证和库存防超卖商城项目最核心最紧张的地方就是下单这一段。用户点击“确认下单”的时候后端要做的事不止是往订单表里插一条数据而是要做一个完整的事务链校验用户购物车中商品是否存在、是否上架。计算订单总金额注意用数据库里的价格不能信任前端传过来的价格。扣减商品库存如果库存不足直接抛出异常让事务回滚。生成订单主记录状态为待支付。生成订单明细记录。清空购物车中已下单的商品。整个过程必须加上Transactional保证每一步要么全部成功要么全部失败。否则就会出现“库存扣了但订单没生成”或者“订单生成了但库存没扣”这种数据不一致后面对账和用户投诉都会找上门。事务的本质就是数据库层面的“全有或全无”这从生活上类比就像转账你转给别人 100 块不可能出现自己余额扣了但对方没收到的情况。防超卖是另一个必提的点。在高并发并发下单场景下传统做法是“先查库存再判断再更新”这样会出问题两个请求同时读到库存为 1同时判断“库存足够”同时执行 UPDATE导致超卖。正确做法是让扣库存的 UPDATE 语句带上“库存大于扣减数”的条件UPDATE product SET stock stock - #{quantity} WHERE id #{productId} AND stock #{quantity}然后检查受影响的行数如果为 0说明库存不足抛出异常。这种做法利用了数据库行锁在“扣减”这一步天然完成原子操作比先查后改靠谱得多。这也是从源码里能看到的最值钱的设计之一。3.4 统一返回格式与全局异常处理接口返回格式统一开发联调会省心很多。项目里通常定义一个通用返回类所有接口都返回同一种结构{ code: 200, message: success, data: { ... } }code 200 表示成功其他数字表示各类业务错误。message 是对用户友好的提示文字。data 放具体业务数据。前端在 axios 拦截器里统一判断 code如果是 200 就直接取 data否则弹出错误提示。整个前端就不用每个请求单独处理错误分支异常提示非常一致。后端还需要一个全局异常处理器用RestControllerAdvice注解捕获各类异常。业务异常统一抛自定义 RuntimeException捕获后返回对应的 code 和 message参数校验失败返回 400 类错误系统未知异常返回 500并打印完整堆栈日志方便排查。没有全局异常处理的后果是什么用户操作时只要服务器报一个空指针接口直接返回一个巨大的异常堆栈 JSON前端根本没法解析体验极差还暴露了内部实现细节。4. 前端 Vue 实现要点商城前台与后台管理一体4.1 页面结构规划与组件复用前端部分可以拆成两个大块商城前台用户看到的部分和后台管理管理员操作的部分。商城前台页面通常包括首页轮播图、分类入口、热门商品推荐商品列表页按分类筛选、分页浏览商品详情页图片轮播、价格展示、加入购物车购物车页修改数量、勾选购买、计算小计订单确认页选择收货地址、生成订单个人中心页查看订单列表、订单详情后台管理页面包括登录页管理员单独入口仪表盘简单统计商品管理商品列表、新增商品、编辑商品、上下架分类管理一级/二级分类维护订单管理查看所有订单、修改订单状态、处理发货开发时尽量把商品卡片、分页组件、弹窗组件抽成公共组件。同一个商品卡片在首页推荐位能用在商品列表能用在搜索结果里也能用。前端代码的一大原则就是“不写重复结构”如果发现两处页面的模板结构基本一样就应该考虑抽组件了。源码里让我印象比较深的是弹窗确认和图片上传这类高频组件每个管理页面都会用到抽出来之后省了很多重复代码。4.2 前端路由与权限控制前端使用 Vue Router 管理页面跳转。路由需要区分“公开路由”和“需要登录的路由”。const routes [ { path: /, component: Home }, { path: /product/:id, component: ProductDetail }, { path: /cart, component: Cart, meta: { requiresAuth: true } }, { path: /admin, component: AdminLayout, meta: { requiresAdmin: true } } ]配合路由守卫在跳转前检查登录状态router.beforeEach((to, from, next) { const token localStorage.getItem(token) if (to.meta.requiresAuth !token) { next(/login) } else { next() } })后台管理的路由守卫更严格不仅要求登录还要检查用户的角色。我这里想提醒一句前端路由守卫只是“体验层面的保护”真正的安全校验必须在后端也做一遍。因为前端代码在浏览器里是可以被改的用户完全可以绕过前端跳转到某个接口地址所以后端接口的权限校验才是真正安全防线。4.3 axios 封装与 token 携带前端与后端交互通常会把 axios 实例单独封装成一个文件统一配置基础 URL 和超时时间再通过拦截器处理 token 注入和统一错误提示。// http.js const service axios.create({ baseURL: /api, timeout: 10000 }) service.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers[Authorization] Bearer token } return config }) service.interceptors.response.use(response { const res response.data if (res.code 200) { return res.data } if (res.code 401) { router.push(/login) } Message.error(res.message) return Promise.reject(new Error(res.message)) })把 token 放在拦截器里统一处理之后业务代码里就不用再关心“每个请求手动带 token”的细节写起来很清爽。如果请求返回 401就在拦截器里统一跳转登录页而不是在每个页面里重复写这段逻辑。关于 baseURL 要特别说明一下。本地开发时前端端口通常是 8080后端端口是 8081存在跨域问题。常规做法是在 vue.config.js 里配置 devServer 代理module.exports { devServer: { proxy: { /api: { target: http://localhost:8081, changeOrigin: true } } } }这样前端请求 /api/login代理会转发到后端 http://localhost:8081/api/login。上线部署时会用 Nginx 做同样的反向代理把 /api 前缀的请求转发到后端服务。我想强调一下开发环境下千万不要用“前后端都改成同一个端口”来绕开跨域那只是自欺欺人上线环境还是需要 nginx 配置直接用代理才是正规流程。5. 项目部署运行从零到完整跑通的每一步5.1 环境准备别在第一步翻车这个项目要跑起来本地环境至少要准备JDK 1.8 以上新版本用 JDK 11 或 17 也没问题Maven 3.6负责依赖管理和后端构建Node.js 14前端构建工具链的基础MySQL 5.7 或 8.0数据库IDE 建议使用 IDEA后端和 VSCode 或 WebStorm前端这里最容易翻车的是 JDK 版本和 SpringBoot 版本不匹配。部分源码基于 SpringBoot 2.x建议直接用 JDK 8 和 SpringBoot 2.7.x 的组合兼容性最好。如果强行用 JDK 17 配旧版 SpringBoot可能会遇到一些依赖注入的兼容性问题排查起来费时费力。遇到这种情况不要慌把 SpringBoot 升到 2.7 以上或者降回 JDK 8选一个最顺手的组合就好。5.2 数据库初始化与配置数据库部分源码里通常会提供 .sql 文件里面包括建库语句和表结构部分还会附带测试数据。先在 MySQL 里执行CREATE DATABASE huan_dimai_mall DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE huan_dimai_mall; SOURCE /path/to/huan_dimai_mall.sql;这里我强烈建议字符集用 utf8mb4 而不是 utf8原因很实际utf8 在 MySQL 中最多存 3 字节一些特殊字符和表情符号存不进去下单地址里如果用户填了生僻字或者表情符号插入时就直接报错。utf8mb4 是 utf8 的超集能完整覆盖这些情况。我见过不止一次因为字符集问题导致商品中文内容乱码或者插入失败的案例提前用对字符集才是治本。然后修改后端配置文件 application.yml 里的数据库连接spring: datasource: url: jdbc:mysql://localhost:3306/huan_dimai_mall?useUnicodetruecharacterEncodingutf8mb4serverTimezoneAsia/Shanghai username: root password: yourpassword需要注意 url 里的 serverTimezone 参数如果你的 MySQL 是 8.0不加时区参数很可能报错关于 server time zone 的异常。这是个新手高频问题排查方向基本都是先看时区。5.3 后端启动步骤后端启动很简单但有几个细节会影响第一次启动的顺利程度。第一确认 Maven 依赖已经下载完整。如果网络不好导致依赖下载失败可以先清理本地仓库缓存换成国内 Maven 镜像源然后把 IDEA 的 Maven 设置里的 offline 模式关掉。第二执行mvn spring-boot:run启动看到类似Tomcat started on port(s): 8081的日志就说明启动成功了。第三建议先用接口测试工具验证几个关键接口比如登录、商品列表、商品详情确认数据库连接和接口逻辑没问题再开始联调前端。后端接口的默认端口通常在 application.yml 里配置为 8081避免和前端 8080 冲突。如果端口被占用在 yml 里改掉即可。5.4 前端启动步骤与后端联调前端部分进入项目目录安装依赖npm install如果 npm install 太慢可以临时配置国内镜像源安装完成后启动开发服务器npm run serve前端默认端口是 8080启动后浏览器输入 http://localhost:8080 就能看到首页。由于 devServer 已经配置了 /api 代理前端请求会自动转发到后端 8081理论上直接就能联调。这里我想特别提醒如果你在源码里看到的接口请求路径是前缀 /api 开头的代理配置一定要和后端实际路径保持一致。比如后端接口是/user/login前端请求/api/user/login代理转发到后端时要确保最终转发的 URL 不带多余的 /api否则会 404。常见的处理方式是在 proxy 配置里加一个重写规则去掉 /api 前缀或者后端接口本身就带统一的 /api 前缀两种方式各有优缺但一定要“对得上号”。6. 上线前的代码打磨与问题排查实录6.1 常见问题速查表下面这些问题是这个项目、以及类似商城开发过程中出现频率最高的我整理成一张排查速查表现象可能原因排查方向前端请求返回 404代理路径配置不匹配检查请求路径和代理 rewrite 规则后端接口返回 401token 缺失/过期检查拦截器放行路径配置数据库中文乱码连接字符集/表字符集错误统一设置 utf8mb4商品库存数据混乱并发扣减库存没有加条件检查 UPDATE SQL 是否带 stock quantity分页查询结果不对PageHelper 调用位置/次数错误检查 startPage 与查询的对应顺序前端点击按钮无响应跨域或接口报错被拦截先看浏览器 F12 的 Network编译报错显示找不到包Maven 依赖冲突/未下载完整刷新依赖或检查版本号6.2 本地开发中容易踩的细节坑关于“拦截器放行路径”的配置我觉得值得多说几句。如果没有在拦截器中显式放行登录接口、注册接口、商品列表、商品详情这些公开接口那前端还没登录所有请求都会被拦截页面根本加载不出数据。很多新人一上来看到 401 就以为是自己代码写错了其实只是拦截器把不该拦的请求也拦了。正确做法是在拦截器配置中定义一个 excludePathPatterns 列表把公开接口加进去。另一个容易出问题的地方是“新增商品时日期字段的处理”。前端的日期选择器返回的是带时区的字符串后端如果直接用Date类型接收很容易在序列化和反序列化时出现时区偏移。建议后端配置统一的全局日期格式前端也按同样的格式传输两边对齐就不会莫名其妙差 8 小时。还有关于 JSON 序列化的坑。实体类里如果有createTime、updateTime这类字段默认序列化出来是一长串时间戳前端如果用字符串格式展示就会很怪要么后端在实体类的日期字段上配置统一格式化要么前端在渲染时用 dayjs 或 moment 做格式化二者选一个并保持全项目一致。6.3 源码安全与上线检查清单如果这个项目要正式上线除了把功能和性能做好安全方面的功课也不能落下。有几个最基本的检查项把明文密码换成 BCrypt 加密存储数据库中不要出现可直接读到的密码哪怕只是内部系统也建议加密。检查 Swagger 之类的接口文档组件是否在生产环境关闭不要给外部暴露过多接口信息。后端中敏感配置信息如数据库密码要从配置文件中抽离改用环境变量或配置中心管理避免源码泄露造成连带风险。前端构建生产包时确认没有把测试环境或开发环境接口地址打包进去否则上线后接口全指向内网用户访问一片空白。这里讲的几点不是全部但属于“最基础不要踩”的等级。电商项目一旦涉及真实支付、真实用户信息安全底线必须更高。对于学习项目而言边界可以适当放宽但安全思维最好从一开始就建立起来。7. 项目扩展方向这套架构能做到什么程度这套 SpringBoot Vue MyBatis MySQL 的商城系统如果只做商品浏览和下单其实只发挥了三分之一的能力。后续扩展空间非常大而且每个方向都能把当前架构的潜力进一步发挥出来。第一个扩展方向是“多商户支持”。现在是一套商家后台管一个商城做多商户改造时只需要在商品表和订单表里新增一个商户 id 字段作为隔离维度再额外开发一个商户端的商品管理页面。底层表结构和订单流程基本不用大改这得益于最初的订单快照设计。第二个扩展方向是“营销活动”。秒杀、优惠券、满减活动这些本质上都是“价格计算”和“库存扣减”的特殊模式。有了基础的购物车和订单流程加营销模块时只需要在订单计算环节插入活动规则解析逻辑。比如满减就是一个配置表加一个金额计算器秒杀就是复用防超卖的库存扣减 SQL。第三个扩展方向是“消息通知”。订单状态变化以后需要给用户发短信、站内信或者邮件。可以把状态变更处加一个事件发布后续接入消息队列做异步通知不需要改动原有的订单流转逻辑。做技术选型时很多人喜欢追新框架、换语言但我觉得对于业务系统来说“稳定、可控、团队熟悉”是更要紧的属性。这套技术栈虽然听着不够炫酷但它能撑起业务从零到一再到一定体量的全过程。在开发这类型商城项目时我自己有几点体会最后分享给正在动手的同学。第一个体会是拿到一套源码不要急着跑起来先花半小时读一遍数据库表和项目结构这半小时能顶得上后面调试两小时。你理解了数据怎么流转的也就理解了代码为什么这么写。第二个体会是改别人的代码前先做一次“全量备份”或者用版本管理工具建一个分支。尤其是数据库脚本改之前一定要确认当前库的结构和脚本是否一致不然改完连不上了都不知道是自己的问题还是环境的问题。第三个体会是一定要自己在本地把“从首页浏览到最终下单”这个完整流程走一遍。光调通接口不算完成页面上能不能顺畅走通购物车清没清、订单状态对不对、库存扣没扣这些都要实际点一遍。很多逻辑上的问题看着代码根本发现不了只有实际操作时才会暴露。这套欢迪迈手机商城的源码覆盖面很完整从设计模式、分层架构到具体的事务处理都有参考价值。如果你正在找一套完整的前后端分离项目来练手照着这个思路去跑一遍、改一遍、拆一遍收获会相当大。