1. 这套销售系统解决的实际问题与功能全景先说个场景。前阵子有个做二手3C回收的朋友找我说想把手头的电子产品库存搬到线上卖但市面上现成的商城系统要么太贵要么塞了一堆用不上的模块什么积分、拼团、直播带货全来了反而连最基本的商品上下架订单管理客户信息都做得稀烂。我一看这需求干脆自己搭一套——SpringBoot做后端接口Vue做前端页面MySQL存数据就是这次要分享的这套Web电子产品销售系统信息管理系统的完整实现。这套系统定位很明确面向电子产品手机、电脑、耳机、配件这类的销售管理场景提供从商品录入、库存变动、购物车下单到订单状态流转、客户信息沉淀的完整闭环。核心价值不在于功能多花哨而在于每一个模块都紧贴真实业务打开就能用改改就能上生产。整体技术形态是典型的前后端分离后端SpringBoot提供RESTful API负责业务逻辑、权限校验、数据持久化前端Vue做单页应用负责页面渲染和用户交互MySQL作为唯一的存储层保存商品、分类、用户、订单、购物车等核心数据。三者通过JSON格式的HTTP请求串联起来。适合谁来参考这套系统呢三类人最合适正在做毕业设计或课程设计的学生需要一个结构完整、可演示、可答辩的全栈项目作为基线再往上加创新点。刚入行一到两年的Java开发想看看一个规范化的前后端分离项目Controller、Service、Mapper各层怎么划分权限怎么做事务怎么加代码怎么写才算能维护。想做小型电商系统的个人开发者或小团队需要一个靠谱的起点而不是从零开始造轮子。这套系统最让我满意的一点是可运行这三个字不是空话。MySQL建库脚本、后端配置文件、前端接口地址全都对得上本地装好环境后按步骤启动前后端就能连起来跑通。很多开源项目死就死在文档与实际代码不一致这次我特意把环境版本和启动顺序都标注清楚后面细说。2. 技术选型背后的取舍逻辑2.1 为什么是SpringBoot而不是SSH或微服务很多新手上来就问现在不是流行Spring Cloud微服务吗怎么还在用单体SpringBoot答案是业务规模决定架构形态。一套电子产品销售系统日订单量在几千到几万这个量级甚至还没到这个量级单体应用完全能扛住。SpringBoot的意义在于它把Spring生态的配置复杂度降到了最低——内嵌Tomcat、自动装配、起步依赖开发者不需要再折腾一堆XML配置一个main方法就能启动整个服务。选SpringBoot还有两个少有人提的理由。第一社区成熟度高遇到任何问题Stack Overflow上几乎都有答案对新手极其友好第二招聘市场认可度高SpringBoot几乎是Java后端岗位的标配技能用这套项目去面试面试官看到的是这个求职者用的是主流技术栈。2.2 前端框架选了Vue的理由Vue在国内的普及度不用多说。对比ReactVue的模板语法对后端开发者来说上手成本最低——在HTML里写{{ }}插值、v-for循环、v-if条件渲染思维方式与写模板页面很接近。而React的JSX虽然灵活但对习惯HTML语义的人来说心理转换成本更高。这套系统用的是Vue 2 Element UI组合。为什么不追Vue 3 Element Plus坦白说Electron UI对Vue 3的适配早期并不完善而且很多教学资源、成熟组件示例都沉淀在Vue 2生态里。对于一套要可直接运行的交付系统稳定压倒一切。如果你自己后续要升级Vue 3的组合式API在逻辑复用上确实更强但核心业务代码的迁移成本也不低建议先跑通这套再考虑。另外前端配套了Axios做HTTP请求封装Vue Router做页面路由Vuex做全局状态管理登录态、购物车数量这类共享数据。这些都是Vue生态里的标准配置组合起来就能支撑一个完整的单页应用。2.3 MySQL最稳妥的选择数据存储没有悬念地选了MySQL 5.7/8.0。对比PostgreSQLMySQL在Web应用场景的普及率更高云数据库支持也最广泛。对比NoSQL电商交易数据要求强一致性——订单金额不能错、库存不能超卖这必须靠关系型数据库的事务机制来保证。有朋友问过为什么不加Redis做缓存我的回答是小程序项目初期加缓存是优化手段而非必需手段。商品详情、分类列表这类热点数据确实适合缓存但你首先要把业务跑通、数据一致性逻辑搞清楚。这套系统的设计里预留了缓存接口位置但核心交易链路下单、扣库存、更新订单必须走MySQL事务这是底线。3. 数据表设计的业务映射与边界处理3.1 六张核心表的结构与关系这套系统的数据库叫electronics_mall共有六张核心表。我先用表格把表结构和业务定位列清楚再逐个讲设计意图表名核心字段业务职责t_userid, username, password, real_name, phone, role, status存储系统用户区分管理员与普通客户t_categoryid, name, parent_id, sort_order, status商品分类支持两级层级如手机下分智能手机功能机t_productid, category_id, name, main_image, price, stock, sales, status商品基本信息核心是价格、库存、上下架状态t_product_attrid, product_id, attr_name, attr_value商品扩展属性如手机的颜色、内存、屏幕尺寸t_cartid, user_id, product_id, quantity, checked购物车数据支持勾选结算t_orderid, order_no, user_id, total_amount, status, receiver_name, receiver_phone, receiver_address, create_time订单主表记录订单状态流转和收货信息t_order_itemid, order_id, product_id, product_name, product_image, price, quantity订单明细快照下单时的商品信息3.2 为什么订单明细要做商品快照这是很多人忽略但实际业务中非常关键的设计点。订单明细表里除了product_id外还冗余存了product_name、product_image、price这些字段。这么做的原因很直接用户在购买后商家可能修改了商品名称、调整了价格甚至下架了商品。如果订单明细只存一个product_id历史订单展示时就得去查当前商品表——万一商品删了订单就变成幽灵数据既显示不出商品名金额也对不上。所以业界通行做法是订单生成那一刻把商品的关键信息复制一份到订单明细表。这相当于给每笔订单拍了张当时的照片后续无论商品怎么变订单始终能还原出下单那一刻的完整事实。这也是面试时关于订单表设计最喜欢问的点之一。3.3 商品属性表电子产品sku化的另一条路电子产品有个特殊性同款手机颜色、内存版本、存储容量不同价格和库存都可能不同。市面上成熟的电商系统一般会引入SKU库存单位概念每个SKU对应一个价格和库存组合。但SKU的设计复杂度很高属性组合膨胀后管理起来很头疼。这套系统做了一个折中商品主表记录基础价格和总库存扩展属性表记录规格信息。好处是简单直接坏处是做不到按规格区分库存。对于教学项目和小型业务来说这个折中是划算的——你能把核心流程跑通后续要升级到SKU体系只要围绕t_product_attr做扩展即可不会推翻重来。注意如果业务规模到了需要精确管理每个规格的库存量就不要偷懒了老老实实引入t_sku表把价格、库存下沉到SKU维度。这个决策点要提前想清楚。3.4 逻辑删除与状态字段这套系统里大量使用了status字段比如商品表有status表示上架/下架用户表有status表示正常/禁用分类表有status表示显示/隐藏。我特意没有做物理删除——除非是清库操作生产环境的数据删除都应该走逻辑删除路线。原因有两条。一是系统的数据具有连续性比如下架的商品可能还在处理售后、对账直接物理删除会导致历史数据断裂。二是软删除的成本极低无非是多一个字段查询时默认加where status 1过滤即可。当你需要统计历史累计上架过多少商品这类问题时软删除的价值就会体现出来。4. 后端SpringBoot核心模块的实现逻辑4.1 工程分层与包结构先看后端工程的包结构我习惯按功能模块分包而不是按技术层分包com.example.electronics ├── config // 配置类CORS跨域、拦截器注册 ├── controller // 接口层接收请求参数校验返回结果 ├── service // 业务层核心业务逻辑事务控制 │ └── impl // service接口的实现 ├── mapper // 数据访问层MyBatis接口SQL映射 ├── entity // 实体类对应数据库表 ├── dto // 数据传输对象接收前端参数返回前端数据 ├── vo // 视图对象定制化返回结构 ├── common // 通用工具统一返回结果、异常处理、常量 └── interceptor // 拦截器登录态校验、管理员权限校验这个分层的核心逻辑是依赖单向流动Controller依赖ServiceService依赖Mapper谁都不允许反向依赖。这样做最大的好处是每个类只干一件事、只依赖下层接口改一处不影响全局。比如你把MyBatis换成MyBatis-Plus只需要动Mapper层Controller和Service完全不用碰。4.2 JWT登录认证与权限控制的落地系统有两种角色管理员和普通客户。管理员能操作后台管理功能商品管理、订单处理、分类维护普通客户只能在前台浏览、加购、下单。权限控制不能只靠前端隐藏按钮——那只是用户体验层面的处理真正的防线在后端的每个接口上。登录流程是这样的用户提交用户名和密码到/api/user/login。后端用MD5加盐校验密码通过后生成JWT TokenToken里写入userId和role。Token通过响应头返回给前端前端存在localStorage里之后每个请求的Authorization头都会带上它。后端拦截器解析Token校验签名和有效期把用户信息放入ThreadLocal供后续逻辑使用。带有RequireAdmin注解的接口拦截器会额外校验角色是否为管理员。为什么用JWT而不是Session核心区别在于Session依赖服务端存储集群部署时要引入Session共享方案如Spring Session Redis而JWT是无状态的服务端不存任何登录数据天然适合前后端分离、后面可能要拆多服务的场景。代价是JWT签发后无法主动失效但在这个量级的系统里Token有效期设短一点比如2小时配合前端跳转登录页完全够用。4.3 商品查询接口的前后端协同商品列表是前台最核心的接口我做了分页和条件筛选。前端传pageNum、pageSize、categoryId、keyword后端按条件拼接SQLselect idselectProductPage resultTypecom.example.electronics.vo.ProductVO SELECT p.*, c.name AS category_name FROM t_product p LEFT JOIN t_category c ON p.category_id c.id WHERE p.status 1 if testcategoryId ! null and categoryId ! AND p.category_id #{categoryId} /if if testkeyword ! null and keyword ! AND (p.name LIKE CONCAT(%, #{keyword}, %) OR p.description LIKE CONCAT(%, #{keyword}, %)) /if ORDER BY p.create_time DESC /select分页用PageHelper插件实现一个PageHelper.startPage(pageNum, pageSize)就能自动拦截SQL并生成分页结果比手写LIMIT offset, size省心得多而且返回的分页对象里自带total、pages等元数据前端拿到就能渲染分页组件。4.4 下单扣库存的事务边界订单模块是全系统事务最密集的地方。用户点击提交订单后后端要做一系列操作校验购物车数据、生成订单号、明细快照、扣减商品库存、清空已购商品、返回订单信息。每一步都不能出错必须放在同一个事务里。我在OrderServiceImpl的下单方法上加了Transactional(rollbackFor Exception.class)并把事务传播行为设为默认的REQUIRED——一旦方法内任何一步抛异常整个事务回滚库存和数据不会出现不一致。值得单独说的是扣库存的SQL写法。如果先查库存再在Java层判断够不够并发场景会出现超卖。正确姿势是直接在UPDATE语句里加条件UPDATE t_product SET stock stock - #{quantity} WHERE id #{productId} AND stock #{quantity}这条SQL返回的影响行数如果为0说明库存不足直接抛出业务异常触发回滚。这是利用数据库行锁解决并发的经典做法比在Java里synchronized靠谱一百倍务必记住。4.5 统一返回结构与全局异常处理为了让前端处理数据时的逻辑统一所有接口返回的JSON结构都是同一个格式{ code: 200, message: success, data: {} }code200表示成功非200表示业务异常比如401表示未登录、403表示无权限、500表示系统错误。前端Axios拦截器统一判断code非200统一跳转或弹提示不用每个页面单独写错误处理。全局异常处理用RestControllerAdvice实现业务异常我自定义了BusinessException会被统一捕获并返回清晰的中文提示系统异常记录日志后返回系统繁忙的兜底信息。这样做的价值是Controller代码变得非常干净不会再出现大片的try-catch业务逻辑一目了然。5. Vue前端页面的功能拆解与代码实现5.1 前台页面与后台页面的双端结构前端按访问角色拆成两个部分面向普通客户的前台商城页面和面向管理员的运营后台页面。前台包含首页商品推荐、商品列表页支持分类筛选、关键词搜索、分页、商品详情页、购物车页、结算下单页、订单列表页、登录注册页。后台包含仪表盘统计用户数、商品数、今日订单量、商品管理新增、编辑、上下架、库存调整、分类管理、订单管理发货、查看详情、用户管理禁用/启用。这种双端结构在代码上通过路由分开管理。我用路由懒加载来拆包这样用户访问前台页面时不会加载后台代码首屏加载速度快不少const routes [ { path: /, name: Home, component: () import(../views/Home.vue) }, { path: /admin, component: () import(../layout/AdminLayout.vue), children: [ { path: dashboard, name: Dashboard, component: () import(../views/admin/Dashboard.vue) }, { path: product/list, name: ProductList, component: () import(../views/admin/ProductList.vue) } ] } ]5.2 Axios封装与接口层的统一管理我把所有HTTP请求封在service目录下每个模块一个文件比如product.js、order.js、cart.js。这样做的直接好处是页面组件里只调用getProductList(params)这类语义清晰的函数不会到处散落axios.get(/api/product/list?pageNum...)这种裸请求。后端接口路径变了只需要改一个文件。请求拦截器统一注入Tokenservice.interceptors.request.use( config { const token localStorage.getItem(token) if (token) { config.headers[Authorization] Bearer token } return config }, error Promise.reject(error) )响应拦截器统一处理业务错误码和HTTP状态码401时清空本地登录态并跳转登录页。这块代码只要写一次全站受益。5.3 商品列表的条件查询与分页联动商品列表页是整个前台交互最复杂的页面。左侧是分类树顶上是搜索框中间是商品卡片网格底部是分页条。每当分类、关键词或者页码变化时触发一次接口请求拿到新数据后刷新列表和分页组件。我用了watch监听筛选条件的变化配合deep: true对条件对象做深度监听任何字段变化都自动触发重新查询。这个方案对比手动在每个事件里调用查询函数代码更集中也不容易漏掉某个入口。watch( () filterParams, () { filterParams.pageNum 1 loadProducts() }, { deep: true } )有个细节值得注意当筛选条件变化时页码要重置为1否则用户在第一页筛选后翻到第5页看到的可能是空数据。这个条件变化重置页码的逻辑很多新手项目会漏掉。5.4 购物车状态管理与结算逻辑购物车数据放在Vuex里因为购物车是全局共享的状态——用户可以从商品详情页加入购物车也可以从底部导航栏直接进入购物车页两边数据必须同步。Vuex的state里存储购物车列表每次增删都通过mutation触发并同步到后端接口。结算逻辑是用户勾选要结算的商品点击去结算前端把勾选商品的id列表传给后端后端生成订单主表和明细同时扣减库存。这里有个数据一致性细节——前端要校验勾选的商品不能为空后端也要再校验一遍库存和价格防止有人直接构造请求绕过前端。前后端双重校验不是浪费而是所有支付类系统的安全底线。5.5 Element UI组件的高效组合使用UI层完全基于Element UI组件库搭建这是我强烈推荐给全栈项目的原因——表格、表单、分页、弹窗、消息提示这些高频组件都现成可用而且样式统一、文档完善。商品管理表格用el-table加el-pagination实现表单用el-form加校验规则。最省心的是el-upload组件的图片上传——配合SpringBoot的MultipartFile接口一行配置就能把商品图片传到后端的静态资源目录访问路径通过/api/file/upload返回给前端存入商品表的main_image字段。这比嵌入七牛云、阿里云OSS这些第三方存储的方案少了账号配置的麻烦更适合本地跑通。6. 从零到一完整跑通的部署流程6.1 环境版本与安装关键点这是我实际练习时踩过最多坑的环节。给出我验证过的版本组合软件版本关键配置JDK1.8或8环境变量JAVA_HOME指向安装目录Maven3.6.xsettings.xml配置阿里云镜像加速依赖下载MySQL5.7 或 8.0字符集设为utf8mb4避免中文乱码Node.js14建议LTS版本npm源切到国内镜像IDEA任意安装Lombok插件有一个容易忽略的地方后端项目的application.yml里MySQL用户名、密码、端口必须与本地实际环境一致。很多人报Access denied for user rootlocalhost十有八九是这里没改对。6.2 数据库初始化三步走打开MySQL命令行创建数据库CREATE DATABASE electronics_mall DEFAULT CHARACTER SET utf8mb4;导入项目sql/electronics_mall.sql文件source /你的路径/electronics_mall.sql;验证表是否创建成功SHOW TABLES;看到七张表就对了。提示SQL文件里包含了测试数据测试账号、示例商品等这是特意保留的。没有数据的前端页面光秃秃的很多功能都展示不出来有测试数据才能让整个系统一上来就有活着的感觉。6.3 后端启动的关键配置第一步确认application.yml里的数据库连接信息正确无误。第二步用IDEA打开后端工程等待Maven自动下载依赖。首次下载可能需要几分钟取决于网络和Maven镜像速度。第三步直接运行ElectronicsApplication类的main方法看到类似下面的日志就表示启动成功Tomcat started on port(s): 8080 (http) with context path 后端默认跑在8080端口接口前缀是/api。可以用curl http://localhost:8080/api/product/list快速验证接口是否活着。6.4 前端启动与代理配置前端工程打开后先执行npm install安装依赖。如果速度慢换成国内镜像源立刻见效npm config set registry https://registry.npmmirror.com npm install npm run serve启动成功后访问http://localhost:8081Vue默认端口。这里有个关键配置前端访问后端接口会跨域我在vue.config.js里配了开发代理把/api前缀的请求转发到后端8080端口module.exports { devServer: { port: 8081, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } }用了代理之后前端代码里请求路径只需写成/api/xxx浏览器不会产生跨域报错。同时后端也配置了CORS允许跨域双保险。6.5 常见启动报错与快速定位我把自己实际遇到过的报错整理成一张排查表报错信息原因分析解决方案Access denied for user rootlocalhostapplication.yml的账号密码错误改为本地MySQL真实账号密码Unknown database electronics_mall没有导入SQL文件或库名不一致检查库名重新导入Port 8080 was already in use8080被其他程序占用换端口或杀掉占用进程java.sql.SQLNonTransientConnectionExceptionMySQL驱动版本与MySQL版本不匹配5.7用mysql-connector-java5.1.x8.0用8.x驱动Failed to bind properties under spring.datasource配置缩进或字段名写错检查yml文件的缩进和key拼写npm ERR! code ELIFECYCLE前端依赖安装不完整删除node_modules后重新npm install图片上传后访问404静态资源路径与访问路径不一致检查上传目录与spring.mvc.static-path-pattern匹配7. 这个项目最值得借鉴的几处设计经验套系统跑通之后回头看有几处设计是我自己最满意、也是被朋友反复问到的。第一统一返回结构加全局异常处理这套组合拳。很多新手项目里的Controller是报错方式千人千面——有的返回null、有的返回自定义Map、有的直接抛5xx。这套系统凡是接口必然返回{code, message, data}前端处理逻辑极度统一。这个模式完全可以迁移到任何企业级后端项目里。第二订单明细快照表的设计思路。很多人第一次看到t_order_item里冗余了商品名称和价格会质疑为什么不直接JOIN商品表——等你真实运营一段时间、改过几次商品价格之后就会明白快照方案是唯一能保证历史订单可追溯的做法。这是数据库设计里空间换时间、冗余换稳定的典型案例。第三库存扣减的乐观锁思路。用一条带条件的UPDATE语句解决并发超卖代码简洁、性能高效、事务安全。这里强烈建议把这条SQL背下来面试聊到秒杀、库存、并发的时候这就是亮眼的实战细节。第四Vue前端把Axios请求统一收口的做法。业务代码里不直接出现axios全部走service层封装这让接口维护变得极其轻松。哪怕后端接口路径大改前端只需动一个文件。关于这套系统后续还能扩展的方向我多说两句想接入支付可以在下单流程后增加支付宝/微信支付回调接口想增加数据看板后端加一套统计SQL前端用ECharts画图想提升性能把商品列表和分类数据放入Redis缓存想支持多商户把t_user扩展出merchant_id字段并重新梳理权限模型。这些方向都不需要推翻现有架构在既有代码上叠加即可。我个人的看法是一套系统直接跑通只是底线真正让人受益的是藏在每个模块背后的设计决策。这篇文章里我把自己做的取舍逻辑、踩过的坑、修复的过程都写出来了如果你照着搭一遍收货的绝对不只是一个能跑的项目而是一整套电商后端的设计方法论。
1. 这套销售系统解决的实际问题与功能全景先说个场景。前阵子有个做二手3C回收的朋友找我说想把手头的电子产品库存搬到线上卖但市面上现成的商城系统要么太贵要么塞了一堆用不上的模块什么积分、拼团、直播带货全来了反而连最基本的商品上下架订单管理客户信息都做得稀烂。我一看这需求干脆自己搭一套——SpringBoot做后端接口Vue做前端页面MySQL存数据就是这次要分享的这套Web电子产品销售系统信息管理系统的完整实现。这套系统定位很明确面向电子产品手机、电脑、耳机、配件这类的销售管理场景提供从商品录入、库存变动、购物车下单到订单状态流转、客户信息沉淀的完整闭环。核心价值不在于功能多花哨而在于每一个模块都紧贴真实业务打开就能用改改就能上生产。整体技术形态是典型的前后端分离后端SpringBoot提供RESTful API负责业务逻辑、权限校验、数据持久化前端Vue做单页应用负责页面渲染和用户交互MySQL作为唯一的存储层保存商品、分类、用户、订单、购物车等核心数据。三者通过JSON格式的HTTP请求串联起来。适合谁来参考这套系统呢三类人最合适正在做毕业设计或课程设计的学生需要一个结构完整、可演示、可答辩的全栈项目作为基线再往上加创新点。刚入行一到两年的Java开发想看看一个规范化的前后端分离项目Controller、Service、Mapper各层怎么划分权限怎么做事务怎么加代码怎么写才算能维护。想做小型电商系统的个人开发者或小团队需要一个靠谱的起点而不是从零开始造轮子。这套系统最让我满意的一点是可运行这三个字不是空话。MySQL建库脚本、后端配置文件、前端接口地址全都对得上本地装好环境后按步骤启动前后端就能连起来跑通。很多开源项目死就死在文档与实际代码不一致这次我特意把环境版本和启动顺序都标注清楚后面细说。2. 技术选型背后的取舍逻辑2.1 为什么是SpringBoot而不是SSH或微服务很多新手上来就问现在不是流行Spring Cloud微服务吗怎么还在用单体SpringBoot答案是业务规模决定架构形态。一套电子产品销售系统日订单量在几千到几万这个量级甚至还没到这个量级单体应用完全能扛住。SpringBoot的意义在于它把Spring生态的配置复杂度降到了最低——内嵌Tomcat、自动装配、起步依赖开发者不需要再折腾一堆XML配置一个main方法就能启动整个服务。选SpringBoot还有两个少有人提的理由。第一社区成熟度高遇到任何问题Stack Overflow上几乎都有答案对新手极其友好第二招聘市场认可度高SpringBoot几乎是Java后端岗位的标配技能用这套项目去面试面试官看到的是这个求职者用的是主流技术栈。2.2 前端框架选了Vue的理由Vue在国内的普及度不用多说。对比ReactVue的模板语法对后端开发者来说上手成本最低——在HTML里写{{ }}插值、v-for循环、v-if条件渲染思维方式与写模板页面很接近。而React的JSX虽然灵活但对习惯HTML语义的人来说心理转换成本更高。这套系统用的是Vue 2 Element UI组合。为什么不追Vue 3 Element Plus坦白说Electron UI对Vue 3的适配早期并不完善而且很多教学资源、成熟组件示例都沉淀在Vue 2生态里。对于一套要可直接运行的交付系统稳定压倒一切。如果你自己后续要升级Vue 3的组合式API在逻辑复用上确实更强但核心业务代码的迁移成本也不低建议先跑通这套再考虑。另外前端配套了Axios做HTTP请求封装Vue Router做页面路由Vuex做全局状态管理登录态、购物车数量这类共享数据。这些都是Vue生态里的标准配置组合起来就能支撑一个完整的单页应用。2.3 MySQL最稳妥的选择数据存储没有悬念地选了MySQL 5.7/8.0。对比PostgreSQLMySQL在Web应用场景的普及率更高云数据库支持也最广泛。对比NoSQL电商交易数据要求强一致性——订单金额不能错、库存不能超卖这必须靠关系型数据库的事务机制来保证。有朋友问过为什么不加Redis做缓存我的回答是小程序项目初期加缓存是优化手段而非必需手段。商品详情、分类列表这类热点数据确实适合缓存但你首先要把业务跑通、数据一致性逻辑搞清楚。这套系统的设计里预留了缓存接口位置但核心交易链路下单、扣库存、更新订单必须走MySQL事务这是底线。3. 数据表设计的业务映射与边界处理3.1 六张核心表的结构与关系这套系统的数据库叫electronics_mall共有六张核心表。我先用表格把表结构和业务定位列清楚再逐个讲设计意图表名核心字段业务职责t_userid, username, password, real_name, phone, role, status存储系统用户区分管理员与普通客户t_categoryid, name, parent_id, sort_order, status商品分类支持两级层级如手机下分智能手机功能机t_productid, category_id, name, main_image, price, stock, sales, status商品基本信息核心是价格、库存、上下架状态t_product_attrid, product_id, attr_name, attr_value商品扩展属性如手机的颜色、内存、屏幕尺寸t_cartid, user_id, product_id, quantity, checked购物车数据支持勾选结算t_orderid, order_no, user_id, total_amount, status, receiver_name, receiver_phone, receiver_address, create_time订单主表记录订单状态流转和收货信息t_order_itemid, order_id, product_id, product_name, product_image, price, quantity订单明细快照下单时的商品信息3.2 为什么订单明细要做商品快照这是很多人忽略但实际业务中非常关键的设计点。订单明细表里除了product_id外还冗余存了product_name、product_image、price这些字段。这么做的原因很直接用户在购买后商家可能修改了商品名称、调整了价格甚至下架了商品。如果订单明细只存一个product_id历史订单展示时就得去查当前商品表——万一商品删了订单就变成幽灵数据既显示不出商品名金额也对不上。所以业界通行做法是订单生成那一刻把商品的关键信息复制一份到订单明细表。这相当于给每笔订单拍了张当时的照片后续无论商品怎么变订单始终能还原出下单那一刻的完整事实。这也是面试时关于订单表设计最喜欢问的点之一。3.3 商品属性表电子产品sku化的另一条路电子产品有个特殊性同款手机颜色、内存版本、存储容量不同价格和库存都可能不同。市面上成熟的电商系统一般会引入SKU库存单位概念每个SKU对应一个价格和库存组合。但SKU的设计复杂度很高属性组合膨胀后管理起来很头疼。这套系统做了一个折中商品主表记录基础价格和总库存扩展属性表记录规格信息。好处是简单直接坏处是做不到按规格区分库存。对于教学项目和小型业务来说这个折中是划算的——你能把核心流程跑通后续要升级到SKU体系只要围绕t_product_attr做扩展即可不会推翻重来。注意如果业务规模到了需要精确管理每个规格的库存量就不要偷懒了老老实实引入t_sku表把价格、库存下沉到SKU维度。这个决策点要提前想清楚。3.4 逻辑删除与状态字段这套系统里大量使用了status字段比如商品表有status表示上架/下架用户表有status表示正常/禁用分类表有status表示显示/隐藏。我特意没有做物理删除——除非是清库操作生产环境的数据删除都应该走逻辑删除路线。原因有两条。一是系统的数据具有连续性比如下架的商品可能还在处理售后、对账直接物理删除会导致历史数据断裂。二是软删除的成本极低无非是多一个字段查询时默认加where status 1过滤即可。当你需要统计历史累计上架过多少商品这类问题时软删除的价值就会体现出来。4. 后端SpringBoot核心模块的实现逻辑4.1 工程分层与包结构先看后端工程的包结构我习惯按功能模块分包而不是按技术层分包com.example.electronics ├── config // 配置类CORS跨域、拦截器注册 ├── controller // 接口层接收请求参数校验返回结果 ├── service // 业务层核心业务逻辑事务控制 │ └── impl // service接口的实现 ├── mapper // 数据访问层MyBatis接口SQL映射 ├── entity // 实体类对应数据库表 ├── dto // 数据传输对象接收前端参数返回前端数据 ├── vo // 视图对象定制化返回结构 ├── common // 通用工具统一返回结果、异常处理、常量 └── interceptor // 拦截器登录态校验、管理员权限校验这个分层的核心逻辑是依赖单向流动Controller依赖ServiceService依赖Mapper谁都不允许反向依赖。这样做最大的好处是每个类只干一件事、只依赖下层接口改一处不影响全局。比如你把MyBatis换成MyBatis-Plus只需要动Mapper层Controller和Service完全不用碰。4.2 JWT登录认证与权限控制的落地系统有两种角色管理员和普通客户。管理员能操作后台管理功能商品管理、订单处理、分类维护普通客户只能在前台浏览、加购、下单。权限控制不能只靠前端隐藏按钮——那只是用户体验层面的处理真正的防线在后端的每个接口上。登录流程是这样的用户提交用户名和密码到/api/user/login。后端用MD5加盐校验密码通过后生成JWT TokenToken里写入userId和role。Token通过响应头返回给前端前端存在localStorage里之后每个请求的Authorization头都会带上它。后端拦截器解析Token校验签名和有效期把用户信息放入ThreadLocal供后续逻辑使用。带有RequireAdmin注解的接口拦截器会额外校验角色是否为管理员。为什么用JWT而不是Session核心区别在于Session依赖服务端存储集群部署时要引入Session共享方案如Spring Session Redis而JWT是无状态的服务端不存任何登录数据天然适合前后端分离、后面可能要拆多服务的场景。代价是JWT签发后无法主动失效但在这个量级的系统里Token有效期设短一点比如2小时配合前端跳转登录页完全够用。4.3 商品查询接口的前后端协同商品列表是前台最核心的接口我做了分页和条件筛选。前端传pageNum、pageSize、categoryId、keyword后端按条件拼接SQLselect idselectProductPage resultTypecom.example.electronics.vo.ProductVO SELECT p.*, c.name AS category_name FROM t_product p LEFT JOIN t_category c ON p.category_id c.id WHERE p.status 1 if testcategoryId ! null and categoryId ! AND p.category_id #{categoryId} /if if testkeyword ! null and keyword ! AND (p.name LIKE CONCAT(%, #{keyword}, %) OR p.description LIKE CONCAT(%, #{keyword}, %)) /if ORDER BY p.create_time DESC /select分页用PageHelper插件实现一个PageHelper.startPage(pageNum, pageSize)就能自动拦截SQL并生成分页结果比手写LIMIT offset, size省心得多而且返回的分页对象里自带total、pages等元数据前端拿到就能渲染分页组件。4.4 下单扣库存的事务边界订单模块是全系统事务最密集的地方。用户点击提交订单后后端要做一系列操作校验购物车数据、生成订单号、明细快照、扣减商品库存、清空已购商品、返回订单信息。每一步都不能出错必须放在同一个事务里。我在OrderServiceImpl的下单方法上加了Transactional(rollbackFor Exception.class)并把事务传播行为设为默认的REQUIRED——一旦方法内任何一步抛异常整个事务回滚库存和数据不会出现不一致。值得单独说的是扣库存的SQL写法。如果先查库存再在Java层判断够不够并发场景会出现超卖。正确姿势是直接在UPDATE语句里加条件UPDATE t_product SET stock stock - #{quantity} WHERE id #{productId} AND stock #{quantity}这条SQL返回的影响行数如果为0说明库存不足直接抛出业务异常触发回滚。这是利用数据库行锁解决并发的经典做法比在Java里synchronized靠谱一百倍务必记住。4.5 统一返回结构与全局异常处理为了让前端处理数据时的逻辑统一所有接口返回的JSON结构都是同一个格式{ code: 200, message: success, data: {} }code200表示成功非200表示业务异常比如401表示未登录、403表示无权限、500表示系统错误。前端Axios拦截器统一判断code非200统一跳转或弹提示不用每个页面单独写错误处理。全局异常处理用RestControllerAdvice实现业务异常我自定义了BusinessException会被统一捕获并返回清晰的中文提示系统异常记录日志后返回系统繁忙的兜底信息。这样做的价值是Controller代码变得非常干净不会再出现大片的try-catch业务逻辑一目了然。5. Vue前端页面的功能拆解与代码实现5.1 前台页面与后台页面的双端结构前端按访问角色拆成两个部分面向普通客户的前台商城页面和面向管理员的运营后台页面。前台包含首页商品推荐、商品列表页支持分类筛选、关键词搜索、分页、商品详情页、购物车页、结算下单页、订单列表页、登录注册页。后台包含仪表盘统计用户数、商品数、今日订单量、商品管理新增、编辑、上下架、库存调整、分类管理、订单管理发货、查看详情、用户管理禁用/启用。这种双端结构在代码上通过路由分开管理。我用路由懒加载来拆包这样用户访问前台页面时不会加载后台代码首屏加载速度快不少const routes [ { path: /, name: Home, component: () import(../views/Home.vue) }, { path: /admin, component: () import(../layout/AdminLayout.vue), children: [ { path: dashboard, name: Dashboard, component: () import(../views/admin/Dashboard.vue) }, { path: product/list, name: ProductList, component: () import(../views/admin/ProductList.vue) } ] } ]5.2 Axios封装与接口层的统一管理我把所有HTTP请求封在service目录下每个模块一个文件比如product.js、order.js、cart.js。这样做的直接好处是页面组件里只调用getProductList(params)这类语义清晰的函数不会到处散落axios.get(/api/product/list?pageNum...)这种裸请求。后端接口路径变了只需要改一个文件。请求拦截器统一注入Tokenservice.interceptors.request.use( config { const token localStorage.getItem(token) if (token) { config.headers[Authorization] Bearer token } return config }, error Promise.reject(error) )响应拦截器统一处理业务错误码和HTTP状态码401时清空本地登录态并跳转登录页。这块代码只要写一次全站受益。5.3 商品列表的条件查询与分页联动商品列表页是整个前台交互最复杂的页面。左侧是分类树顶上是搜索框中间是商品卡片网格底部是分页条。每当分类、关键词或者页码变化时触发一次接口请求拿到新数据后刷新列表和分页组件。我用了watch监听筛选条件的变化配合deep: true对条件对象做深度监听任何字段变化都自动触发重新查询。这个方案对比手动在每个事件里调用查询函数代码更集中也不容易漏掉某个入口。watch( () filterParams, () { filterParams.pageNum 1 loadProducts() }, { deep: true } )有个细节值得注意当筛选条件变化时页码要重置为1否则用户在第一页筛选后翻到第5页看到的可能是空数据。这个条件变化重置页码的逻辑很多新手项目会漏掉。5.4 购物车状态管理与结算逻辑购物车数据放在Vuex里因为购物车是全局共享的状态——用户可以从商品详情页加入购物车也可以从底部导航栏直接进入购物车页两边数据必须同步。Vuex的state里存储购物车列表每次增删都通过mutation触发并同步到后端接口。结算逻辑是用户勾选要结算的商品点击去结算前端把勾选商品的id列表传给后端后端生成订单主表和明细同时扣减库存。这里有个数据一致性细节——前端要校验勾选的商品不能为空后端也要再校验一遍库存和价格防止有人直接构造请求绕过前端。前后端双重校验不是浪费而是所有支付类系统的安全底线。5.5 Element UI组件的高效组合使用UI层完全基于Element UI组件库搭建这是我强烈推荐给全栈项目的原因——表格、表单、分页、弹窗、消息提示这些高频组件都现成可用而且样式统一、文档完善。商品管理表格用el-table加el-pagination实现表单用el-form加校验规则。最省心的是el-upload组件的图片上传——配合SpringBoot的MultipartFile接口一行配置就能把商品图片传到后端的静态资源目录访问路径通过/api/file/upload返回给前端存入商品表的main_image字段。这比嵌入七牛云、阿里云OSS这些第三方存储的方案少了账号配置的麻烦更适合本地跑通。6. 从零到一完整跑通的部署流程6.1 环境版本与安装关键点这是我实际练习时踩过最多坑的环节。给出我验证过的版本组合软件版本关键配置JDK1.8或8环境变量JAVA_HOME指向安装目录Maven3.6.xsettings.xml配置阿里云镜像加速依赖下载MySQL5.7 或 8.0字符集设为utf8mb4避免中文乱码Node.js14建议LTS版本npm源切到国内镜像IDEA任意安装Lombok插件有一个容易忽略的地方后端项目的application.yml里MySQL用户名、密码、端口必须与本地实际环境一致。很多人报Access denied for user rootlocalhost十有八九是这里没改对。6.2 数据库初始化三步走打开MySQL命令行创建数据库CREATE DATABASE electronics_mall DEFAULT CHARACTER SET utf8mb4;导入项目sql/electronics_mall.sql文件source /你的路径/electronics_mall.sql;验证表是否创建成功SHOW TABLES;看到七张表就对了。提示SQL文件里包含了测试数据测试账号、示例商品等这是特意保留的。没有数据的前端页面光秃秃的很多功能都展示不出来有测试数据才能让整个系统一上来就有活着的感觉。6.3 后端启动的关键配置第一步确认application.yml里的数据库连接信息正确无误。第二步用IDEA打开后端工程等待Maven自动下载依赖。首次下载可能需要几分钟取决于网络和Maven镜像速度。第三步直接运行ElectronicsApplication类的main方法看到类似下面的日志就表示启动成功Tomcat started on port(s): 8080 (http) with context path 后端默认跑在8080端口接口前缀是/api。可以用curl http://localhost:8080/api/product/list快速验证接口是否活着。6.4 前端启动与代理配置前端工程打开后先执行npm install安装依赖。如果速度慢换成国内镜像源立刻见效npm config set registry https://registry.npmmirror.com npm install npm run serve启动成功后访问http://localhost:8081Vue默认端口。这里有个关键配置前端访问后端接口会跨域我在vue.config.js里配了开发代理把/api前缀的请求转发到后端8080端口module.exports { devServer: { port: 8081, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } }用了代理之后前端代码里请求路径只需写成/api/xxx浏览器不会产生跨域报错。同时后端也配置了CORS允许跨域双保险。6.5 常见启动报错与快速定位我把自己实际遇到过的报错整理成一张排查表报错信息原因分析解决方案Access denied for user rootlocalhostapplication.yml的账号密码错误改为本地MySQL真实账号密码Unknown database electronics_mall没有导入SQL文件或库名不一致检查库名重新导入Port 8080 was already in use8080被其他程序占用换端口或杀掉占用进程java.sql.SQLNonTransientConnectionExceptionMySQL驱动版本与MySQL版本不匹配5.7用mysql-connector-java5.1.x8.0用8.x驱动Failed to bind properties under spring.datasource配置缩进或字段名写错检查yml文件的缩进和key拼写npm ERR! code ELIFECYCLE前端依赖安装不完整删除node_modules后重新npm install图片上传后访问404静态资源路径与访问路径不一致检查上传目录与spring.mvc.static-path-pattern匹配7. 这个项目最值得借鉴的几处设计经验套系统跑通之后回头看有几处设计是我自己最满意、也是被朋友反复问到的。第一统一返回结构加全局异常处理这套组合拳。很多新手项目里的Controller是报错方式千人千面——有的返回null、有的返回自定义Map、有的直接抛5xx。这套系统凡是接口必然返回{code, message, data}前端处理逻辑极度统一。这个模式完全可以迁移到任何企业级后端项目里。第二订单明细快照表的设计思路。很多人第一次看到t_order_item里冗余了商品名称和价格会质疑为什么不直接JOIN商品表——等你真实运营一段时间、改过几次商品价格之后就会明白快照方案是唯一能保证历史订单可追溯的做法。这是数据库设计里空间换时间、冗余换稳定的典型案例。第三库存扣减的乐观锁思路。用一条带条件的UPDATE语句解决并发超卖代码简洁、性能高效、事务安全。这里强烈建议把这条SQL背下来面试聊到秒杀、库存、并发的时候这就是亮眼的实战细节。第四Vue前端把Axios请求统一收口的做法。业务代码里不直接出现axios全部走service层封装这让接口维护变得极其轻松。哪怕后端接口路径大改前端只需动一个文件。关于这套系统后续还能扩展的方向我多说两句想接入支付可以在下单流程后增加支付宝/微信支付回调接口想增加数据看板后端加一套统计SQL前端用ECharts画图想提升性能把商品列表和分类数据放入Redis缓存想支持多商户把t_user扩展出merchant_id字段并重新梳理权限模型。这些方向都不需要推翻现有架构在既有代码上叠加即可。我个人的看法是一套系统直接跑通只是底线真正让人受益的是藏在每个模块背后的设计决策。这篇文章里我把自己做的取舍逻辑、踩过的坑、修复的过程都写出来了如果你照着搭一遍收货的绝对不只是一个能跑的项目而是一整套电商后端的设计方法论。
