Mall（电商系统）项目介绍

一句话定位：国内 Java 圈最有名的「电商实战教学项目」——Spring Boot 多模块单体 + Vue 3 后台 + uni-app 前台，功能完整、文档极全，但它首先是用来学架构的，不是拿来直接开店的。

1. 项目是什么

mall 是一套功能完整的电商系统参考实现，包含后台管理（mall-admin）、前台商城（mall-portal）、商品搜索（mall-search）三个可独立启动的服务，配 Vue 3 后台前端与 uni-app 移动端，用 Docker 容器化部署。

它和一般「开源商城」最大的区别在于定位：它的第一属性是教学项目。作者围绕它写了整套学习教程（架构篇 / 业务篇 / 部署篇 / 扩展篇）和 115 期视频课程，代码组织的首要目标是「让人看得懂、能照着搭」，而不是「让商家直接开张」。

它解决的核心问题：

1. 缺少一个能完整学习的电商范例 —— 商品/SKU、购物车优惠计算、确认单、订单状态机、权限 RBAC、ES 搜索、延迟消息关单，这些在企业里看不到全貌的东西它都摆出来了。
2. 不知道主流 Java 技术栈怎么串起来 —— Redis、MongoDB、RabbitMQ、Elasticsearch、MinIO、ELK、Jenkins 一次性整合在一套业务里，不是孤立的 Hello World。
3. 毕设与面试需要一个「完整项目经验」 —— 文档全、能跑通、讲得清设计思路，这一档几乎没有更强替代品。

不适用的场景：它没有内置支付（支付宝对接只在「扩展篇」教程里讲实现思路）；没有多商户、分销、拼团、风控、对账；不做秒杀级高并发压测；没有生产级监控告警与安全审计。直接拿它当生产电商系统用，是选型误判。

2. 核心特性

3. 技术架构

整体结构：多模块单体（modular monolith），不是微服务。四个可启动的 Spring Boot 应用 —— mall-admin（后台接口）、mall-portal（前台接口）、mall-search（搜索服务）、mall-demo（框架搭建期的测试代码，可忽略）。业务层各自独立，底层共用 mall-common、mall-mbg、mall-security。

技术选型（版本取自仓库根 pom.xml，master 分支实测）：

关键取舍：选择「多模块单体 + 中间件全家桶」而非微服务，是为了让一个学习者在一台机器上跑通全链路；代价是环境依赖极重（六个中间件起步）。mall-security 独立成模块、mall-mbg 用代码生成器产出、mall-demo 保留在仓库里，都是教学优先的痕迹 —— 这不是缺点，但你得知道自己在用什么。

4. 目录结构

mall
├── mall-common      工具类与通用代码（返回体、异常、Redis 配置等）
├── mall-mbg         MyBatis Generator 生成的数据库操作代码（实体 + Mapper）
├── mall-security     Spring Security + JWT 封装，供 admin / portal 复用
├── mall-admin        后台管理系统接口（商品、订单、营销、权限、内容、报表）
├── mall-search       基于 Elasticsearch 的商品搜索服务
├── mall-portal       前台商城系统接口（门户、购物车、下单、会员中心）
├── mall-demo         框架搭建期的测试与示例代码
├── document          架构图、功能结构图、SQL 等文档资源
└── pom.xml           Spring Boot 3.5.14 parent，全模块依赖管理

5. 快速上手

环境硬门槛（官方给出的版本组合，照抄最省事）：

重要提示：只启动 mall-admin 的话，只需 MySQL + Redis。学习和二次开发从这一步切入，别一上来就装六个中间件。

方式 A：本地开发运行

# 1. 克隆（后端）
git clone https://gitee.com/macrozheng/mall.git

# 2. 导入 IDEA，等 Maven 依赖下载完成
# 3. 建库并导入 document 目录下的 SQL 脚本
# 4. 改各模块 application.yml：数据库、Redis、MongoDB、RabbitMQ、ES 连接信息
# 5. 按需启动
#    mall-admin    → 后台管理接口
#    mall-portal   → 前台商城接口
#    mall-search   → 商品搜索（需先启动 ES）

# 6. 克隆并部署前端
git clone https://gitee.com/macrozheng/mall-admin-web.git
# 安装依赖、改接口地址、npm run dev

方式 B：Docker 部署

# 中间件按文档逐个起，或用 Docker Compose 一次性拉起
# 后端镜像构建走 pom 里的 fabric8 docker-maven-plugin
# 注意：需先修改 pom.xml 中的 docker.host（默认是作者内网地址，见第 11 节）
mvn clean package -DskipTests
# 前端构建产物交给 Nginx 托管

启动失败高频原因：Redis 没起（登录直接失败）；ES 版本与代码里的客户端不匹配（7.17.x 才对应当前代码）；MongoDB 未启动导致前台商品详情 500；docker.host 未改导致镜像构建连不上 Docker；JDK 用了 8 跑 master 分支（编译直接报错）。

6. 功能模块清单

7. 版本与授权

版本跟踪方式：项目不发布 Release 版本号，靠分支区分。

协议要点

• Apache-2.0：可商用、可闭源分发、可改可卖，只需保留版权与许可声明。
• 没有商业版、没有授权费、没有功能阉割。它的全部源码就是全部能力，这点在国内同类项目里相当少见。
• 无「禁止商用」条款、无「必须保留 Logo」要求、无二次授权限制。

8. 商业模式说明

这是本篇最值得说清的一节：mall 是「知识型开源」的典型样本 —— 代码全免费，收费的是「怎么学」。

几个要点

• 不做 SaaS、不卖源码、不接定制。对比 MCMS（公司卖四档授权）和微同商城（卖商业版源码），mall 走的是完全第三条路：用免费代码换影响力，用影响力卖课程。
• 这套模式成立的前提是「项目本身足够好、足够完整、足够有学习价值」—— 代码质量就是产品力，一旦变成「能用就行」，课程就没人买。这解释了为什么它的文档和注释质量在同类项目里明显高一档。
• 对使用者意味着什么：代码零成本，时间成本自负。你不需要为授权付钱，但如果想省掉「自己啃代码」的时间，付费课程就是那个商品。反过来说，只看网页教程 + 读代码，也完全够把项目跑通并二次开发 —— 没有功能锁。
• 单人维护是这套模式的必然结果，也是它最大的结构风险（见第 11 节）。

9. 生态与周边

扩展方式三条路：① 在 mall-* 业务模块加 Service/Controller，按现有分层照写；② 用 MyBatis Generator 加表再生成 mall-mbg；③ 换前端（mall-admin-web 或 mall-app-web 整套替换），后端接口不用动。

10. 选型建议

强烈建议用

• Java 学习者与面试准备者 —— 想讲清「电商系统怎么设计」，这一套的教程密度几乎无对手。
• 毕设、课程设计 —— 模块全、文档全、演示站能看效果。
• 企业内部技术培训与脚手架参考 —— 拿来当规范样板，比自研一套教学材料便宜得多。

可以试试

• 企业内部系统或小电商 MVP：功能骨架够用，但支付、物流、对账、风控要自己补，别低估这部分工作量。
• 想学微服务的团队：直接上 mall-swarm，别在单体上硬改。

不建议用

• 直接当生产电商系统上线 —— 无支付、无风控、无多商户、无压测与监控体系，教学定位决定了它不做这些。
• 需要开箱即用商用商城的商家 —— 转微同商城商业版、CRMEB、likeshop 这类有商业支持的。
• 追求自动化测试与 CI 质量门禁的团队 —— 根 pom 全局 skipTests=true，项目基本没有自动化测试兜底。

同类对比

11. 风险与坑

定位层（最需要提前认清的一条）

• 它没有内置支付。README 承诺「完整订单流程」，但支付成功回调、渠道对接属于「扩展篇教程」内容，代码里没有可用的生产级支付实现。任何「拿它开店」的计划都必须先算这块成本。
• 没有多商户、分销、拼团、秒杀防超卖方案（营销模块只是配置层面）、没有对账与风控。教学项目不做这些是合理的，但选型时要清楚。

环境与工程层

• 中间件太多（MySQL / Redis / MongoDB / RabbitMQ / ES / ELK / MinIO），新手一上来全装容易卡死在环境上。先只跑 mall-admin + MySQL + Redis。
• 根 pom.xml 里 docker.host 写死为 http://192.168.3.101:2375 —— 这是作者本机地址。用 docker-maven-plugin 构建镜像前必须改成自己的 Docker 地址，否则连不上。顺带提醒：2375 端口明文无 TLS 暴露在大网上是高危配置，不要照抄到生产机。
• 根 pom 全局 skipTests=true，并且仓库几乎没有自动化测试。二次开发改动后没有回归网，只能靠手工验证。
• mall-mbg 是生成代码，手改会被下次生成覆盖，业务扩展要写在 mall-* 模块里。

版本与信息一致性层

• 分支说明三处口径不一致：Gitee README 说 master = Spring Boot 3.5 + JDK 17、dev-v2 = 2.7 + JDK 8；GitHub 镜像 README 仍写 master = 2.7 + JDK 8、dev-v3 = 3.2 + JDK 17。以仓库 pom.xml 为准（实测 3.5.14 / Java 17），GitHub 那份说明已滞后。
• README 技术选型表里前端写「Vue + Element」，但 mall-admin-web 实际已是 Vue 3 + Element Plus。别按 README 的表去判断前端版本。
• 环境表写 MySQL 5.7，但驱动是 mysql-connector-j 9.3.0。装 MySQL 8.x 反而更匹配，5.7 属于历史遗留说明。
• 视频教程里的技术栈版本（如 Spring Boot 3.2.2、Druid 1.2.21）已经落后于当前 master，跟着视频搭环境会出现版本对不上的情况，以 pom 为准。

维护层

• 单人维护（bus factor = 1）。这不是团队项目，作者个人节奏直接决定项目生死；最近一次推送 2026-09-15，仍在维护但频率不算高。
• 无 CI、无自动化测试、无正式 Release 版本号，只有分支。生产使用要自己建质量体系。

生产落地 checklist

12. 参考链接