如果你需要一个能跑起来的手机商城项目这套“欢迪迈手机商城”源码值得花十分钟看看。它不是什么概念Demo而是一个完整的全栈系统后端用SpringBoot提供RESTful接口前端用Vue搭建页面数据落在MySQL里代码拿到手之后按文档配好环境就能直接运行。手机商城最常见的功能——商品展示、搜索分类、购物车、下单、订单管理、后台商品与用户管理——全都包含在内。对于正在学SpringBoot和Vue的同学来说它是很不错的练手素材对于需要快速搭一套商城原型的人来说它也能省掉大量重复的前后端对接工作。1. 项目到底在解决什么问题1.1 商城系统的核心需求是什么很多人一听到“商城系统”第一反应就是淘宝京东那种体量。实际上绝大多数中小型商城项目核心需求并不复杂可以拆成两条主线用户侧要能逛能买管理侧要能管能看。用户侧至少要包含商品浏览、商品搜索、分类筛选、商品详情、加入购物车、提交订单、查看个人订单。这些是商城的基本盘缺了任何一个用户都会觉得“不完整”。管理侧管理员要能维护商品分类、上下架商品、处理订单状态、查看用户列表。另外前后端要能联调系统要能跑起来代码要能直接启动而不是一堆报错等着填。这套“欢迪迈手机商城”就是围绕这两条主线设计的。用户端对应前端Vue页面管理端也做在了前端工程里通过不同路由和权限入口分开后端SpringBoot统一提供接口MySQL负责持久化。所有功能都遵循“前端请求—后端处理—数据库读写—返回结果”的标准流程。理解这套流程比单纯会某个框架重要得多。1.2 为什么是SpringBoot加Vue加MySQL选这套技术栈不是因为它最新而是因为它最稳也最适合作为完整项目参考。SpringBoot解决了传统SSH项目复杂的XML配置问题。它内置Tomcat、默认提供自动化配置写一个main方法就能启动整个后端服务。对于商城这种典型CRUD加业务状态的系统SpringBoot的生态非常成熟做权限、事务、文件上传都有现成方案。Vue在前端开发里属于上手曲线比较平缓的那一类。它的响应式数据绑定、组件化开发非常适合商城这种“列表页、详情页、购物车、后台管理”页面结构清晰的项目。配合Vue Router做路由跳转、Vuex或Pinia做全局状态管理代码结构一眼就能看懂。Vue也方便做前后端分离开发时一个端口跑前端一个端口跑后端互不干扰。MySQL就更不用说了关系型数据库在订单、库存这类对一致性要求极高的场景里依然是最可靠的选择。它的事务机制能保证“下单扣库存”不出乱子数据量不大的商城项目用MySQL完全足够。这套技术栈的组合既能帮助初学者理解一个完整业务系统的运转逻辑也能让有经验的人快速改造复用。2. 系统架构与核心模块拆解2.1 前后端分离的协作方式这套系统采用的是典型的前后端分离架构。前端Vue工程通过HTTP请求调用后端SpringBoot提供的RESTful接口数据以JSON格式传输后端不关心页面长什么样只负责处理业务逻辑和返回数据。开发环境下前端和后端分别占用不同端口。前端可以把请求代理到后端这样本地联调时不会遇到跨域问题。生产环境下前端打包成静态文件由Nginx或任何静态服务器托管再把接口路径反向代理到后端服务。这样做的最大好处是职责清晰前端工程师只管页面和交互后端工程师只管接口和数据彼此通过接口文档协作不会出现改一个页面把后端代码也带崩的情况。在“欢迪迈”这个项目里前端工程的结构也非常标准。src/api目录集中封装所有接口请求src/router管理路由src/views下面按页面模块划分比如首页、商品列表、商品详情、购物车、订单确认、后台管理。后端则按照controller - service - mapper分层控制层接收参数业务层处理逻辑数据层访问数据库。这种分层结构在面试和实际工作中都是加分项。2.2 后端核心模块有哪些后端按业务域划分大概有五个核心模块。第一用户模块。负责注册、登录、个人信息查询和修改。登录成功后后端会签发一个Token前端保存起来之后每次请求都带上这个Token来识别用户身份。密码存储使用的是加密处理不会明文入库。第二商品模块。负责商品分类管理、商品列表、商品详情。商品表里包含名称、图片、价格、库存、描述、上下架状态等字段。后台管理员可以新增、编辑、删除商品前台用户只能看到上架状态且库存大于0的商品。第三购物车模块。用户可以把商品加入购物车也可以修改数量、删除条目、批量选中。购物车的数据结构比较简单核心是“用户ID 商品ID 数量”。这里要注意一点购物车操作只涉及当前用户自己的数据所以所有接口都必须先鉴权取到当前登录用户ID再操作。第四订单模块。这是整个系统里业务逻辑最复杂的部分。用户从购物车勾选商品后提交订单后端需要先生成订单主表记录再生成订单明细表记录每个商品的快照同时扣减商品库存清空对应的购物车条目。整个过程必须在一个事务里完成任何一个环节失败整体回滚保证数据一致。第五后台管理模块。管理员登录后可以对商品和订单进行管理。这里涉及到简单的权限控制普通用户不能访问后台接口后端通过拦截器或注解校验角色权限。2.3 前端页面与交互设计前端页面围绕用户购物路径设计。首页展示推荐商品和分类入口商品列表页支持按分类筛选、按关键词搜索、按价格排序。商品详情页展示大图、价格、库存和数量选择用户可以直接点击“加入购物车”或“立即购买”。购物车页面可以勾选商品、修改数量、计算总价然后进入结算流程。结算页面需要确认收货地址和订单信息提交后跳转到支付页面。这里的支付功能并不需要对接真实支付渠道而是做了一步“模拟支付”。前端点击“确认支付”后端把订单状态从“待支付”改成“已支付”整个过程跑通了交易闭环。如果你需要对接微信或支付宝只需要替换这个支付接口的实现后面第七章我会单独说。后台管理页面用的是另一套布局侧边栏导航分别是商品管理、分类管理、订单管理、用户管理。管理员登录后可以看到所有订单修改订单状态为已发货、已完成、已取消等。前端代码里提供了完整的管理页面模板可以直接在此基础上增加字段或按钮不用从零布局。3. 数据库设计与核心表结构3.1 核心表模块设计数据库是商城系统的地基。表结构设计得不好后面业务越做越别扭。这套系统涉及的数据库表主要包括用户表、商品分类表、商品表、购物车表、订单表、订单明细表。在完整版本中还可能包括地址表、轮播图表。用户表记录账号、密码加密后的密文、昵称、手机号、角色标识。商品分类表采用父子结构通过parent_id字段表示分类层级可以支持一级分类和二级分类。商品表是核心中的核心字段比较密集商品名称、商品图片、价格、库存、描述、上下架状态、创建时间、更新时间、逻辑删除标识。购物车表保存用户与商品的关联关系以及购买数量。订单表保存订单号、下单用户、订单状态、总金额、收货人信息、下单时间。订单明细表则保存每个商品在订单中的快照包括商品名称、商品图片、单价、数量、小计金额。这里为什么要做“订单明细快照”因为商品价格会变商品可能会下架但用户下单时的商品信息必须固定下来。如果订单明细里直接关联商品表商品价格一改历史订单金额就乱了。所以订单明细表里要冗余保存商品名称、商品图片和成交单价。这是一个典型的“空间换时间”设计。3.2 关键字段设计参考下面直接列一张核心字段表方便你对照建表表名关键字段说明userid, username, password, nickname, phone, rolerole区分普通用户和管理员categoryid, name, parent_id, sortparent_id为0表示一级分类productid, category_id, name, image, price, stock, status, deleteddeleted做逻辑删除cartid, user_id, product_id, quantity一个用户可以有多个条目ordersid, order_no, user_id, status, total_amount, receiver_info订单号要唯一order_itemid, order_id, product_id, product_name, product_image, price, quantity商品快照数据价格字段建议使用DECIMAL(10,2)不要使用FLOAT或DOUBLE因为浮点数在计算金额时会有精度丢失导致总价差几分钱。库存字段使用INT下单扣库存时要注意并发控制最简单的方式是在更新库存的SQL里加上stock quantity的条件防止超卖。订单号建议使用唯一的字符串可以用时间戳加随机数拼接也可以使用数据库UUID后续写订单查询时会用到。另外所有核心表都建议加上create_time和update_time字段订单、商品这类表还需要一个deleted字段做逻辑删除。逻辑删除的意思是删除不是真的在数据库里清掉记录而是把deleted置为1避免历史数据丢失。查询列表时统一加上WHERE deleted 0这是实际项目中很常见也很实用的做法。4. 从零启动环境准备与快速运行4.1 本地环境需要装什么开始跑项目之前先把环境准备好。这套系统的默认技术栈需要以下工具JDK 1.8或更高版本推荐使用JDK 8或JDK 11Maven 3.6以上用于后端依赖管理和构建MySQL 5.7或8.0用于数据存储Node.js 14以上npm随Node自带用于前端依赖安装和运行一个趁手的IDE后端推荐IDEA前端用VS Code就行环境安装好之后先确认各工具的版本号都能在命令行正常输出。比如java -version、mvn -v、node -v、mysql --version确保这些命令都能识别到环境变量。很多“项目跑不起来”的问题最后检查下来都是环境变量没配好这个坑提前排掉能省大量时间。4.2 数据库初始化与后端启动第一步创建一个空的数据库比如shop_system。项目里通常会附带sql文件里面包含建表语句和初始数据比如管理员账号、测试商品。直接使用数据库客户端导入即可。导入后检查一下确认核心表都已经建好并且有几条商品数据。第二步修改后端配置文件中的应用配置。重点检查数据库地址、端口、用户名、密码。常见的配置格式是spring.datasource.url、spring.datasource.username、spring.datasource.password。如果你本地的MySQL端口是3306用户是root密码是123456那基本不需要改动否则一定要改成你自己的实际配置。第三步在后端项目的根目录打开命令行执行mvn spring-boot:run。第一次运行需要下载大量依赖耐心等一会儿。看到控制台输出类似“Started Application”的日志就说明后端启动成功了。默认端口通常是8080可以访问http://localhost:8080确认没有报错。4.3 前端依赖安装与启动后端启动后接着启动前端。进入前端工程目录执行npm install安装依赖。这一步也可能耗时取决于网络状况。安装完成后执行npm run serve启动开发服务器。默认端口通常为8080但如果和后端端口冲突Vue脚手架会自动改为8081或其他端口。看到终端提示“App running at”就可以在浏览器打开对应地址了。这里有一个非常关键的配置前端工程的开发代理。打开前端配置文件把代理目标指向后端的接口地址例如http://localhost:8080。这样当前端发起/api开头的请求时开发服务器会转发给后端避免浏览器直接跨域请求后端地址。如果代理配置不对页面上会看到大量请求失败或者跨域报错。4.4 项目目录结构速览后端目录是按照SpringBoot标准结构组织的src/main/java/com/example/shop ├── controller # 控制层接收HTTP请求 ├── service # 业务逻辑层 ├── mapper # 数据访问层 └── entity # 实体类前端目录的关键部分src ├── api # 接口请求封装 ├── router # 路由配置 ├── views # 页面组件 ├── store # 全局状态管理 └── utils # 工具类拿到项目后先不要急着跑花十分钟把目录结构过一遍知道哪个文件负责哪块功能。后面定位问题时能直接找到对应代码不会一头雾水。5. 核心业务逻辑实现讲解5.1 登录鉴权与Token机制登录是商城系统最基础的模块也是一切业务前提。这套系统采用Token鉴权方案流程大概是用户提交用户名密码后端校验成功后生成一个Token返回前端前端把Token存到本地每次请求在请求头里带上后端拦截器检查请求头里的Token校验合法才放行。使用Token的好处是后端不需要保存登录状态服务器可以水平扩展多个实例之间不共享Session也能识别用户。具体实现时登录接口返回的Token里通常会包含用户ID和过期时间使用签名算法防止篡改。密码存储方面项目里使用加密工具对明文密码处理后再入库登录时对输入的密码做同样处理再比对。绝对不能把明文密码存进数据库一旦数据泄露用户密码全部暴露这是职业道德问题。实际开发中这里有一些细节容易被忽略。比如登录接口本身不需要鉴权但是购物车、订单接口都需要。所以拦截器里要配置好哪些接口放行哪些接口必须校验。常见做法是定义一个白名单登录、注册、商品列表、商品详情这些接口放行其余全部拦截。另外Token过期后前端要能识别并引导用户重新登录很多项目会在前端封装的请求工具里加一个统一响应处理发现Token失效时清掉本地登录状态并跳转到登录页。5.2 购物车与订单闭环购物车和订单是整个商城业务里交互最多的链路。用户先加购物车再去购物车页面勾选商品点击结算生成订单然后模拟支付。这个过程中涉及到商品库存和购物车数据的联动很考验事务控制能力。生成订单的后端接口大致逻辑是这样的前端把购物车中勾选商品的ID列表传给后端后端一次性查出这些商品信息计算总金额然后生成订单主记录状态置为“待支付”接着遍历商品列表生成订单明细记录同时执行库存扣减语句最后删除购物车中对应的商品记录。这四个步骤必须放在同一个事务方法里。中间任何一步抛出异常比如库存不足、商品已下架整个事务回滚订单和库存都不能出现“下了一半单”的脏状态。订单生成后前端跳转到支付页面。模拟支付接口需要把订单状态从“待支付”改成“已支付”有些版本还会生成支付流水记录。到这里整个交易闭环就完成了。需要提醒的是扣库存的SQL建议写成UPDATE product SET stock stock - #{quantity} WHERE id #{id} AND stock #{quantity}这样并发场景下数据库自己就能保证不会超卖。如果你先查出库存再判断库存够不够然后更新在高并发下很容易被“同时下单不通过”的请求打穿。5.3 商品分类与搜索实现商品列表页需要支持分类筛选和关键词搜索。这个功能在数据量不大的时候实现起来非常简单。后端接口接收两个可选参数分类ID和关键词。如果有分类ID就加AND category_id #{categoryId}如果有关键词就加AND name LIKE CONCAT(%, #{keyword}, %)。这个SQL拼接逻辑是商品搜索最基础的形态。分类表设计成父子结构后前端要能展示两级分类。一级分类点击后可以只查一级分类下的商品也可以同时查它所有子分类下的商品。如果只查一级分类那么SQL条件需要匹配该分类及其子分类ID列表。最直接的写法是先查出一级分类的所有子分类ID再用IN查询商品。这种写法逻辑清晰改动成本低。等数据量大了以后再考虑加全文索引或者引入Elasticsearch初期完全没必要。搜索排序也一样价格升序、价格降序、销量优先、最新上架这些都可以通过后端ORDER BY字段动态拼接实现。前端传一个排序参数后端根据参数配置对应的排序字段。这样做的好处是前端不需要处理数据排序后端SQL排序效率高结果稳定。6. 踩坑记录与常见问题排查6.1 数据库连接失败这是新手遇到最多的报错。SpringBoot启动时提示Access denied for user或者Communications link failure基本可以断定是数据库配置问题。检查三处数据库IP端口是否正确用户名密码是否正确目标数据库是否已经创建。还有一个容易忽略的是MySQL 8.0以上版本需要在驱动连接URL里加上时区和SSL配置否则可能报Public Key Retrieval is not allowed或Server timezone异常。解决方法很简单在数据库连接URL上追加参数?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai。如果你用的是MySQL 8.0或更高版本还要确认MySQL驱动版本匹配推荐使用8.0以上版本的驱动。6.2 跨域请求被拦截前后端联调时页面请求后端接口浏览器报跨域错误。开发环境下最省事的办法是在前端配置代理避免直接跨域。生产环境下更推荐在后端配置跨域过滤器允许指定来源域名访问接口。如果使用后端跨域配置需要注意限制请求方法一般允许GET, POST, PUT, DELETE, OPTIONS这几个就够了。OPTIONS预检请求不能漏浏览器在发送复杂请求前会先发一个OPTIONS请求探测服务端是否允许跨域如果后端把这个预检请求拦截了前端就会报跨域失败。很多跨域问题排查半天最后都是因为预检请求没有放行。6.3 图片上传后访问不到商城系统必然涉及商品图片。开发环境下前端上传的图片如果存在后端本地磁盘前端页面通过HTTP地址访问时必须把上传目录映射为静态资源路径。比如图片存在D:/shop/upload需要配置一个资源映射把/images/**路径映射到该目录。否则前端拿到/images/xxx.jpg这个地址请求会直接404。生产环境更简单直接把图片放到云存储或者图床数据库里存图片的完整URL。这样就不用为服务器磁盘空间和静态资源流量担心。这里也建议图片存储路径不要写死在中英文混用的路径下避免不必要的编码问题。6.4 常见问题速查表问题现象大概率原因处理方案后端启动报数据库连接失败数据库配置错误检查用户名、密码、库名、时区参数前端页面白屏路由模式问题使用history模式时生产环境需要后端配合重写路由登录接口返回404接口路径错误检查前端代理路径和后端Controller映射下单库存不减事务没加或SQL条件不对确认事务注解和stock quantity条件所有请求返回401Token未携带或过期检查请求头是否带上Token登录状态是否有效图片加载不出来静态资源映射缺失映射上传目录到可访问URL路径排查问题时第一步永远先看后端控制台日志。日志是最直观的线索报错信息会告诉你是参数问题、空指针还是SQL异常。不要直接去翻前端代码除非后端日志显示根本没有请求进来。这个思路能帮你节省大量时间。7. 代码改造与扩展建议7.1 怎么接入真实支付这套系统的支付功能是模拟的如果你想改成真实支付替换点其实很集中。支付流程的入口在订单确认后前端调用后端的“创建支付”接口后端根据订单生成一个支付请求然后跳转支付页面。支付成功后的回调接口再更新订单状态。对接微信或支付宝支付核心逻辑是准备必填参数订单号、金额、商品描述、回调地址后端调用支付SDK返回支付二维码或支付链接。用户支付成功后支付平台会异步通知回调接口后端校验签名后更新订单状态。这个过程里最关键的两个点是回调地址必须是公网可访问的地址用于本地联调可以用内网穿透工具回调接口一定要做签名校验防止伪造回调。真实支付涉及商户号和密钥本地开发时可以先用沙箱环境测试逻辑跑通后再替换成正式配置。7.2 商城系统的性能优化方向这套系统跑起来没问题但真要上生产环境还有几个优化点值得考虑。第一个是商品缓存。商品列表和详情是读多写少的数据大量用户同时访问时每次都查数据库会比较吃力。可以用缓存把热销商品和分类数据缓存起来商品更新时再删除缓存能显著提升接口响应速度。第二个是搜索优化。初期用LIKE模糊查询没问题商品数量和访问量上去之后LIKE %keyword%无法使用有效索引查询会越来越慢。这时候可以引入全文索引或者更重一点的Elasticsearch方案。但这两个方案都增加了系统复杂度中小型项目一定要评估必要性不要盲目堆技术栈。第三个是接口参数校验和日志记录。后台管理接口一定要做权限校验不能让普通用户直接调用接口修改商品。关键操作比如商品删除、订单状态修改最好记录操作日志方便出问题时追踪。这些改造点不需要动整体架构但能让系统更加健壮。7.3 从单体到微服务的演进路线“欢迪迈”当前是一个典型的单体应用代码结构简单、部署方便、维护成本低。如果项目规模持续增长需要拆分微服务时这套代码也是很好的起点。可以先按业务域拆分成独立的服务用户服务、商品服务、订单服务、支付服务。每个服务独立开发和部署服务之间通过HTTP或消息队列通信。拆分过程中最麻烦的是数据库拆库。原来所有表都在一个库里订单和商品表可以互相关联查询。拆分成独立数据库后跨库查询就需要服务之间通过接口调用来完成。这个演进过程是有很大代价的所以中小型项目不要过早微服务化。道理很简单你只有一个很小的团队维护多个服务的部署、链路追踪、配置中心成本远大于收益。单体应用做到代码规范、业务清晰足够支撑很长一段时间的业务发展。我在实际开发里的体会是这种全栈商城项目最大的价值不是“能跑”而是它把前后端、数据库、业务逻辑、部署方式这些零散知识点串联成了一个整体。很多人单独学框架时每个都懂但一碰到完整项目就不知道从哪里下手。原因就是缺少这种“通盘”的视角。如果你正在学SpringBoot和Vue我建议你不要只看文档而是把这类完整项目代码下载下来照着启动流程跑一遍再试着改改功能比看一百遍教程都有用。真要说遗憾就是这个项目里很多优化空间还没有完全展开比如支付、缓存、分布式事务。但正因为有这些空白你才有机会上手改造把它变成真正属于你自己的实战项目。后面我会继续分享这个项目的改造实操欢迎一起交流。
