做母婴商城这种项目和做普通电商完全不是一回事。不是说换个商品品类、把页面做粉嫩一点就叫母婴商城了选品逻辑、用户决策周期、敏感信息保护、售后规则这些业务差异都会直接反应在系统架构和代码实现上。我最近把一套基于SpringBoot2 Vue3 MyBatis-Plus MySQL8.0的母婴商城系统从零到部署完整跑了一遍把源码、数据库脚本和开发文档都整理齐了。这篇就当作一次完整的项目复盘从技术选型到核心模块实现再到实际部署踩过的坑一次性说清楚。这套东西适合谁一种是学校或者培训机构里做毕业设计、课程项目的同学需要一套能跑通、有文档、能讲清楚技术点的完整系统另一种是想自己练手做全栈项目、但不想从零搭框架的开发者拿这套代码当骨架往里面填自己的业务逻辑。这两种场景我都帮你考虑到了下面讲的内容也尽量兼顾原理和实操。1. 项目整体设计与技术选型思路1.1 为什么是这套组合SpringBoot2 Vue3 MyBatis-Plus MySQL8.0先聊技术栈。很多人上来就问现在不都SpringBoot3了吗你怎么还在用2.x这个问题我在做技术选型的时候也纠结过。最终确定SpringBoot2的原因有两个第一市面上大部分成熟的中间件、第三方SDK对SpringBoot2的兼容性最稳比如很多支付SDK和短信服务商官方文档仍然以SpringBoot2为主2.7版本是2.x的最后一个大版本生命周期足够长第二对学习者来说SpringBoot2的教程、案例、问题解答在社区里的存量最大遇到问题更容易找到参考。Vue3这边没有太多犹豫Composition API写起来比Options API舒服很多配合Vite开发时的热更新速度快到起飞。而且Element Plus这个组件库在Vue3生态里已经非常成熟后台管理界面基本不用自己费劲写样式。MyBatis-Plus选择它是冲着快去的。单表CRUD不用写SQL内置的分页插件、代码生成器、逻辑删除功能直接省掉一大半的基础编码工作。很多人觉得MyBatis-Plus就是简单版MyBatis其实它的动态数据源、多租户插件、乐观锁插件在复杂业务里也是能扛事的。MySQL8.0相比5.7我觉得最值得用的特性是窗口函数和公用表表达式CTE。做商品评价排行、订单统计分析这类需求时一条SQL就能搞定的东西不用再写复杂的子查询。另外8.0默认的utf8mb4字符集和更好的JSON支持对电商这种需要存扩展属性的场景很友好。1.2 母婴商城的业务特殊性不是普通电商的换皮母婴商城看着是电商实际一拆解就能发现它比普通服饰、数码商城多出好几层特殊逻辑。第一是用户决策周期长。买一罐奶粉用户可能会反复对比配方、看评价、问客服所以商品详情的浏览轨迹记录、评价体系的权重设计、搜索的关键词匹配策略都要做得比普通电商更细致。第二是敏感信息多。母婴用户从怀孕建档到孩子出生会涉及孕产信息、宝宝月龄、身高体重等个人敏感数据再加上收货地址里的家庭住址这些信息在数据库里绝对不能明文存储。第三是商品逻辑复杂。母婴商品跨度极大从几十块的奶瓶到几千块的婴儿车从消耗品尿不湿到长周期耐用品不同品类的库存策略、物流策略都不同。比如临期奶粉的促销逻辑、跨境商品的清关状态这些都会影响订单状态的流转设计。第四是售后规则特殊。食品类目拆封不退婴幼儿服装又涉及到贴身用品这些规则要在订单状态机里体现出来不能像普通电商那样一个退货退款走天下。这些特殊性决定了系统在设计阶段就不能照搬通用的电商脚手架下面我会逐个模块说清楚是怎么处理的。2. 数据库设计与核心表结构拆解2.1 商品SPU/SKU模型与多规格处理商品模块是整个系统的地基我采用了经典的三层结构分类表category、SPU表商品主体、SKU表具体规格。分类表设计成支持无限极分类用parent_id关联父级配合一个level字段标记层级。这里有个小技巧查询某个分类下的所有商品时如果用递归查询数据量一大性能就崩。我实际用的是路径枚举方案在分类表里加一个path字段比如0_12_34这样查某个分类及其所有子分类的商品时用LIKE 0_12_34_%就能一把梭查出来比递归的效率高一个量级。SPU表存商品的基础信息标题、副标题、品牌、适用年龄段、图片列表JSON格式存储、详情富文本等。注意适用年龄段是母婴商品的独有字段我用的是age_min和age_max两个整数单位是月龄前端展示的时候再格式化成0-6个月1-3岁这种文案这样做的好处是后端可以做范围查询比如给我筛选适合3-6个月宝宝的玩具这种需求一条SQL就解决了。SKU表挂SPU下面存储具体规格组合和价格库存。规格属性我单独设计了一张属性表attribute和属性值表attribute_value用通用的SPU-属性-属性值关联而不是给每个类目单独建表。比如奶粉有段数属性纸尿裤有尺码属性都走同一套结构。这样新增类目时不用改表结构。库存扣减这块MySQL8.0下我用的是乐观锁方案在SKU表加一个version字段扣减库存时执行UPDATE sku SET stock stock - #{num}, version version 1 WHERE sku_id #{skuId} AND stock #{num} AND version #{version}这里受影响行数为0就说明库存不足或者版本冲突代码里抛异常回滚事务。高并发场景下这个方案比悲观锁select for update性能好比纯Redis预扣减方案实现又简单得多。母婴商城这种量级的系统乐观锁完全够用。2.2 订单、购物车与库存的协同设计订单模块我拆成了五张表购物车表cart、订单主表orders、订单明细表order_item、订单状态日志表order_log、退款售后表refund。购物车表字段比较直接user_id、sku_id、quantity、checked是否选中、create_time。注意一定要加user_id和sku_id的联合唯一索引防止同一用户重复添加同一商品产生脏数据插入时用ON DUPLICATE KEY UPDATE quantity quantity 1的方式实现累加逻辑。订单主表是核心除了常规的订单号、用户ID、总金额、支付方式我专门加了几个字段status订单状态0待支付、1已支付待发货、2已发货、3确认收货、4已完成、5已取消、6售后中close_reason关闭原因这个字段在客服纠纷排查时能救命address_snapshot收货地址快照JSON格式下单那一刻把地址原样存进来后续用户修改默认地址不影响已下订单订单明细表里我冗余了商品标题、主图URL、规格文案、下单时单价。电商界的老规矩订单生成后商品改价、改图、改标题历史订单显示必须不变所以不能去关联SKU表查询实时数据。订单状态日志表很多人会忽略但我强烈建议做。每单的每一次状态变更都插一条记录包括操作人用户/系统/管理员、变更前状态、变更后状态、变更原因。后面出现我明明没点取消怎么订单没了这种客诉一查日志全清楚了。订单号生成我用了时间戳 用户ID后四位 随机数的组合方式避免用数据库自增ID直接当订单号一个是安全问题暴露销量另一个是不好做分表。2.3 会员信息与敏感数据加密存储母婴商城的用户数据里有太多敏感字段手机号、生日用于计算宝宝月龄、宝宝昵称、收货地址。我的处理原则是分级加密。手机号是登录凭证必须能查询但绝对不能明文存。我用的是AES对称加密密钥放在配置中心同时单独建了一张user_mobile_index表存手机号的哈希值SHA-256加盐登录时先通过哈希匹配到userId再解密获取明文。这样可以兼顾查询效率和存储安全。宝宝信息表baby_info关联user_id存储昵称、性别、出生日期。这类数据不参与任何查询条件只做展示所以我直接用了AES加密存储查询出来后在Service层统一解密。收货地址表里收货人姓名和详细地址也是AES加密手机号也是。这里有个坑加密后的密文长度会变长比如11位手机号加密后变成44位左右的字符串建表时字段类型我特意用的VARCHAR(128)预留了充足空间否则后面改表结构很痛苦。对于安全管理上还有个容易忽视的点接口层返回的JSON自动过滤敏感字段。我用了一个自定义注解SensitiveField标注在实体类的敏感属性上配合Jackson的序列化拦截器在响应输出前自动解密、自动脱敏。这样即使某个接口忘记处理也不会把密文或者完整敏感信息打给前端。3. 后端核心模块实现与接口设计3.1 统一返回结构、全局异常与参数校验后端接口设计我遵循了前后端彻底分离的规范所有接口统一返回ResultT结构{ code: 200, // 业务状态码200成功其他为各种失败 message: success, data: {} // 泛型数据 }状态码我自定义了一套业务码200成功、400参数错误、401未登录、403无权限、404资源不存在、500系统异常、1001库存不足、1002订单状态不允许操作等。注意HTTP状态码和业务状态码是两回事比如用户未登录时HTTP返回200但业务码是401这样前端拦截器可以根据业务码做统一跳转。全局异常处理用Spring的RestControllerAdvice统一拦截。最核心的是把MethodArgumentNotValidException参数校验异常和BusinessException业务异常分开处理前者返回具体是哪个字段不合法后者返回给用户可读的业务提示。我在参数校验上用的Hibernate Validator的注解字段上标NotNull、Size、Pattern写起来方便校验逻辑也都集中在实体类里。登录鉴权这块用的是JWTJSON Web Token。用户登录成功后生成tokentoken里只放userId和角色信息过期时间设为2小时同时维护一个refresh_token用来续期有效期7天。这里有个实践心得JWT的最大缺点是不可撤销用户修改密码后旧token依然有效。所以我在Redis里存了一份token黑名单用户登出、改密码时把对应token加入黑名单过期时间设为token剩余有效期这样既保留了JWT的无状态优势又解决了它的安全隐患。还有一个容易踩的坑跨域配置。前后端分离部署时必然遇到CORS问题我用了一个CorsFilter统一处理allowedOriginPatterns配置成*但allowCredentials设为true。注意allowedOrigins不能和allowCredentials同时使用通配符这是个老坑SpringBoot版本不同表现还不一样建议直接在WebMvcConfigurer里配置。3.2 商品搜索MySQL全文索引与缓存设计母婴商品搜索有一个特点用户搜索词比较口语化比如半岁宝宝吃什么奶粉这种长尾长句。直接把整句拆词匹配效果很差。我的方案是两步走。第一步维护一份商品搜索分词表。商品上架时除了标题和副标题运营还可以配置一组搜索关键词比如新生儿 奶粉 一段 0-6个月 不上火这组词被空格分词后存入search_index表。这一步虽然人工成本高一点但搜索精准度远超纯分词器自动拆词。第二步搜索查询时把用户的输入先做简单的预处理去停用词的了什么、提取数字单位组合6个月2段然后去匹配标题和搜索关键词字段。MySQL8.0自带的全文索引FULLTEXT在这个场景下够用配合BOOLEAN MODE可以实现包含多个关键词的逻辑SELECT * FROM product WHERE MATCH(title, sub_title) AGAINST(奶粉 6个月 IN BOOLEAN MODE)注意全文索引有最小分词长度限制默认innodb_ft_min_token_size是3中文单字搜索会失效我把这个参数调整成1或者在索引表里直接存好了分词后的词组。缓存层我用Redis做了两级缓存。商品详情等热点数据用手动缓存策略更新商品时同步更新缓存首页推荐、分类导航这种聚合数据用定时缓存每10分钟刷新一次实际上访问最多的Top商品列表。这比把全部商品都塞缓存要实际得多内存占用低命中率也高。3.3 会员成长体系与优惠券状态机母婴商城和普通电商的关键差异之一就是用户生命周期运营。我做了两个模块会员等级和优惠券系统。会员等级表很简单等级名称、成长值下限、折扣率、权益描述。用户每天签到、下单、完善宝宝信息都会加成长值。下单加成长值这里用的是延迟计算订单确认收货后才真正累加防止用户下单后退款刷成长值。优惠券系统比想象中复杂。我把优惠券拆成三张表优惠券模板表coupon_template、用户持有的优惠券表user_coupon、优惠券使用记录表coupon_usage。模板表定义券的基本信息面额、使用门槛、有效期类型固定时间段或者领取后N天有效、适用品类。发放时机包括新用户注册送、满额返券、定向营销发券。用户领取优惠券时根据模板复制一张券到user_coupon表带独立的有效期。下单时锁定可用券支付成功后标记已使用。这里有个业务细节要处理好优惠券的校验必须在后端完成不能依赖前端传参。用户提交订单时只传user_coupon_id后端去数据库查出这张券核对归属、有效期、使用门槛、是否与商品品类匹配全部通过才允许使用。我还做了一个很实际的防刷设计注册送券接口做了同一设备ID限领一次的限制Redis里以设备指纹为key记录领券次数避免羊毛党批量注册刷券。母婴用品单价高、利润薄风控这块不敢马虎。3.4 订单状态机与支付回调处理订单状态的流转我用状态机模型来管理而不是散落的if-else。搞了一个OrderStatusMachine组件定义状态转移表当前状态触发事件目标状态前置校验待支付用户取消已取消无待支付支付成功回调待发货校验签名、金额一致待发货商家发货已发货补录物流单号已发货用户确认收货已完成无已完成用户发起售后售后中在售后时效内每次状态转移都同步写order_log日志表。状态机的好处是后续加需求比如超时自动取消时只需要在状态表里加一行配置不用动核心业务代码。支付回调是整个系统里最容易出bug的地方核心原则就三个字幂等性。第三方支付平台的回调通知因为网络原因可能重复发送服务端必须保证同一条回调处理一次和多次的结果完全一致。我的做法是回调接口第一件事就查订单状态如果已经是待发货了直接返回成功不再执行后续逻辑。另外还要校验回调的金额和订单金额是否一致防止支付平台传错参数或者被人恶意伪造回调。支付的异步通知处理完后再主动查询一次支付平台的订单状态做二次确认双保险。3.5 商品收藏与浏览历史的实现母婴决策周期长收藏和历史记录功能看似简单但对用户体验很重要。用户可能一周前看的婴儿车今天想起来再对比。收藏功能用的Redis里的Set结构存储key是user:favorite:{userId}value是商品ID集合。用户点击收藏时用SADD命令取消收藏用SREM查询是否收藏用SISMEMBER。商品收藏数量可以查询SCARD获取。Redis的集合操作天然去重而且性能极好。但Redis数据容易丢所以收藏状态在数据库中还有一份表favorite做持久化备份Redis只做查询加速。浏览历史我用的最近最少使用LRU思路在Redis里存一个ZSetkey是user:history:{userId}member是商品IDscore是浏览时间戳。每次浏览商品时用ZADD更新分数拉取历史时用ZREVRANGE按时间倒序取前20条。这种方式天然支持去重 排序两个需求代码量很少。但要注意MySQL中的数据也需要定期同步。我的方案是每天凌晨批量把Redis里的浏览记录写入MySQL的浏览历史表保留最近30天的数据Redis中保留最近7天的热数据。这样既保证读取快速又不丢失用户数据。4. 前端Vue3实现从页面到状态管理4.1 项目结构、路由守卫与登录态管理前端用的Vue3 Vite Pinia Element Plus Vue Router。项目结构上我按功能模块而不是文件类型来组织目录src/ api/ // 接口请求封装按模块拆分product.js, order.js, user.js assets/ // 静态资源 components/ // 通用组件商品卡片、轮播图、地区选择器等 router/ // 路由配置 stores/ // Pinia状态管理userStore, cartStore views/ // 页面组件按用户端/管理端分目录 utils/ // 工具函数request拦截器、格式化工具用户在母婴商城的浏览路径是首页 - 分类 - 商品列表 - 商品详情 - 购物车 - 订单结算 - 支付 - 订单中心。这个路径上有一个核心体验点所有涉及用户身份的页面购物车、订单结算等都需要登录态但用户在浏览商品时不一定需要登录。所以路由守卫不能简单地未登录全部拦截桌球。我的做法是登录态用Pinia的userStore保存用户信息和token路由守卫里区分需要登录的页面和游客可访问页面。用户进入结算页时如果发现未登录弹窗提示登录登录成功后通过redirect参数跳回原来要去的页面保证流程不断。管理端和用户端是两套独立的Vue应用吗我在这个项目里用的是同一个应用通过路由前缀区分/admin和/管理端的路由用单独的路由表懒加载配合一个角色判断的全局前置守卫。这样部署时只有一套前端资源维护成本小。4.2 移动端适配、购物车交互与性能细节母婴商城的用户大部分都是拿手机逛的所以前端必须要做移动端适配。我用的方案是rem布局在入口文件里根据屏幕宽度动态设置根元素的font-size配合postcss-pxtorem插件开发时直接写px编译时自动转rem。购物车的交互做得比较细致。选中状态用checkbox控制所有涉及金额的数字我都会做精度处理。这里有个经典的JavaScript浮点数问题0.1加0.2不等于0.3在计算商品总价时如果直接用浮点数相加最终金额可能差几分钱。我的做法是价格统一用分为单位存储在数据库前端展示时再转成元计算过程全部用整数运算。后端返回的数据也直接给分单位格式化展示用组件formatPrice过滤函数统一处理。商品列表页的性能优化图片懒加载用Element Plus自带的v-lazy指令滚动加载更多用IntersectionObserver监听页面底部的占位元素触发分页请求。接口请求统一走了封装的request工具里面做了token自动附加、错误码统一提示、401自动跳转登录。详情页的富文本图片我用了缩放处理在富文本内容渲染后把大图等比缩放到屏幕宽度同时给图片加了点击放大预览这套交互能明显提升阅读体验。4.3 商品筛选与搜索交互设计母婴商城的筛选需求比普通网购更精细用户经常要按年龄、价格、品牌、功能组合筛选。比如我要找200-300元之间适合1-2岁宝宝的玩具是一个非常常见的需求。前端筛选栏我设计成多维度的筛选项每个维度可以展开收起选中的条件显示在筛选栏顶部支持一键清除。筛选参数通过URL的query参数传递这样用户筛选完刷新页面也不会丢失条件而且可以分享链接给其他妈妈参考。这个交互实现的关键点筛选条件变化时重新请求商品列表接口后端用Page对象接收分页参数配合一个Map类型的筛选条件参数动态拼接MyBatis-Plus的QueryWrapper。需要注意不同商品类目的筛选维度不一样奶粉有段数筛选纸尿裤有尺码筛选所以在接口设计时筛选条件用了一个通用结构categoryIdListFilterItem每个FilterItem包含attributeId和attributeValueIds的数组这样前端配置类目筛选维度时后端接口完全不用改动。5. 部署上线与排坑实录5.1 从本地到服务器的部署要点开发环境跑通之后部署上线是另一道坎。这套系统的部署链路是Nginx做前端静态资源服务和反向代理SpringBoot应用打包成jar包用systemd服务托管MySQL和Redis都用Docker部署在云服务器上。jar包打包前有几个细节要注意。第一是配置文件要区分环境我用application.yml公共配置、application-dev.yml开发环境、application-prod.yml生产环境打包时通过--spring.profiles.activeprod参数激活对应环境。第二是MySQL连接串里要加useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai这三个参数否则中文乱码和时区问题会让你排查到怀疑人生。Nginx配置上有一个关键点前端路由用的history模式刷新页面时Nginx需要配置try_files回退到index.html否则用户刷新详情页直接404location / { try_files $uri $uri/ /index.html; }/api前缀的请求反向代理到后端服务同时配置了gzip压缩和静态资源的浏览器缓存策略。前端打了包之后静态文件的体积能优化就优化路由懒加载、组件按需引入、打包时把第三方库单独拆chunk这些都能明显减少首屏加载时间。生产环境的MySQL我单独跑了一个初始化脚本创建了专门的业务账号不是root只授予业务库的增删改查权限所有远程登录都通过SSH隧道或者内网IPMySQL端口不对公网开放。这个安全习惯做好了能省掉很多被拖库的风险。5.2 开发中遇到的典型问题与排查实录开发过程中我踩了不少坑挑几个有代表性的列出来也是大家复现这个项目时最可能遇到的。第一个是跨域问题。前后端分离开发时前端跑在8080端口后端跑在8081端口所有请求都会被浏览器拦截。我一开始在Controller上加了CrossOrigin注解结果只能解决部分接口的跨域后来统一改成了WebMvcConfigurer里的全局跨域配置问题才彻底解决。这里有个坑要注意如果你同时上了Spring Security等安全框架跨域配置要做两次——一次在安全过滤链里一次在MVC层不然放行的请求会在安全层又被拦掉。第二个是MyBatis-Plus的字段映射问题。数据库字段我用的是下划线命名create_timeJava实体用的是驼峰命名createTimeMyBatis-Plus默认开启了下划线转驼峰但如果用了自定义SQL且查询结果返回的是Map而不是实体返回值key永远保持数据库字段名前端拿到的字段名就对不上。解决方式是写Results注解明确映射关系或者在SQL里手动起别名转成驼峰。第三个是后端传时间字段的时区差8小时问题。Java的LocalDateTime序列化默认用的是UTC而用户在中国东八区导致前端展示的时间总是比实际慢8小时。排查发现是Jackson序列化的时区设置问题在application.yml里加一行配置解决spring: jackson: time-zone: Asia/Shanghai第四个是Redis缓存穿透。商品详情页如果传一个不存在的商品ID请求会直接打到数据库缓存里没有、数据库也没有这个数据恶意循环请求就能打挂数据库。我的解决方式是缓存空值把不存在的商品ID也缓存进去value存一个特殊标记过期时间设成正常缓存的1/5比如正常缓存30分钟空值缓存6分钟这样能挡住大部分穿透流量。同时加了一个简单的接口限流商品详情接口对同一IP的访问频率做限制300次/分钟超过就拒绝。第五个是文件上传问题。商品图片上传用的本地磁盘存储开发环境没问题但生产环境如果用多实例部署文件会存在不同机器的磁盘上导致图片加载不稳定。我换成了阿里云OSS的SDK市面上主流的云存储方案都行上传接口返回URL直接存数据库。如果只是自己部署演示用本地存储配一个绝对路径也够用但要注意Nginx需要把/uploads路径映射到磁盘目录否则图片同样加载不出来。5.3 文档编写与二次开发建议这套项目附带的文档我花了很大心思。很多开源项目源码质量不错但文档拉胯接手的人看代码就像在看天书。我的文档分成三部分部署文档从环境准备JDK版本、Maven配置、MySQL初始化、数据库导入、Redis启动、前端打包到后端jar包启动每一步都有截图和命令。接口文档我用的是Apifox也可以导出OpenAPI格式把全部接口的请求参数、返回结构、业务码含义、示例都整理清楚。开发指南讲清楚项目目录结构、代码分层规范、如何新增一个模块、公共组件的使用方式。二开的时候我建议从这几个地方下手把支付模块从模拟支付换成真实的第三方支付需要企业资质接入短信验证码登录增加限时秒杀功能用Redis预扣库存 消息队列异步削峰把单机部署升级成前后端分离部署再加上容器化编排。6. 写在最后这套系统让我重新理解了电商开发做这个母婴商城之前我以为电商系统最难的是那些花哨的营销功能做完才发现真正决定系统质量的是最基础的那些模块库存扣减的一致性、订单状态的闭环、敏感信息的加密、接口的幂等性。母婴这个领域又额外加了一层约束——你对用户的数据安全、对商品的品质管控承担的责任更大。特别是当我把这套代码部署上线用一个真实的手机号注册、下单、模拟支付、确认收货走完整个流程之后对系统设计决定业务上限这句话的理解比看十遍理论都深刻。给正在做类似项目的同学一个建议不要急着堆功能先把主链路走通从商品浏览到支付完成所有环节的数据在数据库里能完美闭环这个系统就算立住了。至于营销活动、积分商城、直播带货那些花活等主链路稳定了再逐步加上去完全来得及。项目代码整理得比较干净数据库脚本和开发文档也齐全需要的直接拿去用有问题欢迎随时交流。