SpringBoot+Vue全栈手机商城系统：从架构设计到部署实战

做手机商城系统这种项目，圈内人都明白，真正的难点从来不在增删改查，而在订单、库存、支付这几个核心环节怎么设计得稳、可扩展、好维护。“欢迪迈手机商城”这个项目，属于典型的 SpringBoot + Vue + MyBatis + MySQL 全栈电商系统，从源码结构来看，它几乎把所有商城该有的模块都覆盖了：用户、商品、分类、购物车、订单、后台管理、权限控制。对于正在学 Java 全栈的人、准备做毕业设计的同学、或者刚进公司需要接手电商系统的新人来说，这套源码的参考价值非常高。下面我以实际开发者的视角，把这个项目的设计思路、关键实现、运行部署、避坑经验完整拆解一遍，尽量做到不只讲“怎么跑起来”，更讲清楚“为什么这么设计”。

1. 整体设计思路：先搞清楚这个商城到底解决了什么问题

1.1 技术选型背后的考量

先看技术栈：SpringBoot + Vue + MyBatis + MySQL。这套组合在中小型电商项目里极其常见，属于那种“稳得不能再稳”的方案。

• SpringBoot 负责后端接口服务和业务逻辑，它的核心价值是“约定大于配置”，能让我们少写大量 XML 配置，专注业务代码。
• Vue 负责前端页面渲染和交互，前端采用组件化开发，像轮播图、商品卡片、购物车列表这些都能拆成独立组件。
• MyBatis 负责数据库访问层，相比 JPA 那种全自动 ORM，MyBatis 的半自动特性非常适合电商这种 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 里直接写 JDBC，Service 里又放了一堆查询语句，最后改一个需求，所有层都要动一遍。分层设计的一个直观好处是“替换成本低”，比如未来想换从 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); List<Product> productList = productMapper.selectProductList(); PageInfo<Product> 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 购物车与下单链路：事务保证和库存防超卖

商城项目最核心最紧张的地方，就是下单这一段。用户点击“确认下单”的时候，后端要做的事不止是往订单表里插一条数据，而是要做一个完整的事务链：

1. 校验用户购物车中商品是否存在、是否上架。
2. 计算订单总金额（注意用数据库里的价格，不能信任前端传过来的价格）。
3. 扣减商品库存，如果库存不足，直接抛出异常让事务回滚。
4. 生成订单主记录，状态为待支付。
5. 生成订单明细记录。
6. 清空购物车中已下单的商品。

整个过程必须加上@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?useUnicode=true&characterEncoding=utf8mb4&serverTimezone=Asia/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 规则
后端接口返回 401	token 缺失/过期	检查拦截器放行路径配置
数据库中文乱码	连接字符集/表字符集错误	统一设置 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。

第三个扩展方向是“消息通知”。订单状态变化以后，需要给用户发短信、站内信或者邮件。可以把状态变更处加一个事件发布，后续接入消息队列做异步通知，不需要改动原有的订单流转逻辑。

做技术选型时，很多人喜欢追新框架、换语言，但我觉得对于业务系统来说，“稳定、可控、团队熟悉”是更要紧的属性。这套技术栈虽然听着不够炫酷，但它能撑起业务从零到一，再到一定体量的全过程。

在开发这类型商城项目时，我自己有几点体会，最后分享给正在动手的同学。

第一个体会是：拿到一套源码，不要急着跑起来，先花半小时读一遍数据库表和项目结构，这半小时能顶得上后面调试两小时。你理解了数据怎么流转的，也就理解了代码为什么这么写。

第二个体会是：改别人的代码前，先做一次“全量备份”或者用版本管理工具建一个分支。尤其是数据库脚本，改之前一定要确认当前库的结构和脚本是否一致，不然改完连不上了都不知道是自己的问题还是环境的问题。

第三个体会是：一定要自己在本地把“从首页浏览到最终下单”这个完整流程走一遍。光调通接口不算完成，页面上能不能顺畅走通，购物车清没清、订单状态对不对、库存扣没扣，这些都要实际点一遍。很多逻辑上的问题，看着代码根本发现不了，只有实际操作时才会暴露。

这套欢迪迈手机商城的源码覆盖面很完整，从设计模式、分层架构到具体的事务处理都有参考价值。如果你正在找一套完整的前后端分离项目来练手，照着这个思路去跑一遍、改一遍、拆一遍，收获会相当大。