ZKMall（Spring Boot 3 多商户商城）项目介绍

一句话定位：ZKMall 是深圳中科鑫智科技做的 B2B2C 多商户 Java 商城，后端一套 Spring Boot 3.4 工程拆成平台端、商家端、H5/小程序端三个服务，前端另配 Vue3 管理端与 UNIAPP 两个仓库。它的技术栈是这类国产商城里比较新的，但仓库里没有完整建库脚本（sql/ 只有一个 1.1 KB 增量文件），装起来要先进官方 QQ 群或走商务渠道拿 SQL，这是使用前最该知道的一件事。

1. 项目是什么

它是「一套后端 + 三套前端」里的那套后端。 仓库里只有 Java 代码、配置和少量文档，平台管理界面、商家管理界面、H5/小程序都不在这个仓库里，分别对应 b2b2c-admin、b2b2c-merchant、b2b2c-uniapp 三个独立仓库。想跑起来，四个仓库都得拉。

它的三个后端服务对应三种使用者：

先认清三点：

• 它不是开箱即用的交付包。README 写「开箱即用」，但完整数据库脚本不在仓库里。sql/250917.sql 只有 1 张 AI 问答表、两条菜单权限和一条索引，属于增量补丁。README 也直接写了「Sql 脚本及详细文档进群获取（QQ 群 984772612）」。
• 它是一个「商业产品的开源版」。官网 mallzk.com 同时卖商业版源码，README 明确「除开源版本外，还提供商业版本的商城」。
• 它的技术栈偏新：Spring Boot 3.4.7 + Java 17 + MyBatis-Plus 3.5，不是那种停在 Boot 2.x 时代的存量项目。这一点在国产 Java 商城开源项目里不算常见。

2. 核心特性

需要注意：这些功能是否全部在开源版可用，仓库本身无法证明。README 的功能清单更像产品介绍，哪些模块被商业版切走，只能装上跑一遍才知道。

3. 技术架构

整体结构：一个 Maven 父工程带 5 个业务模块 + 1 个内置的 XXL-Job 源码目录，三个可独立启动的 Spring Boot 应用共享 commons 与 10 个自封装 starter。典型的多服务单体：代码在一起，部署可以分开。

自封装 starter 是这套工程的结构特点，zkmall-starter 下 10 个模块各管一件事：

几个关键取舍：

• 三个服务共用一套库：admin、business、app 连的是同一个 MySQL，靠不同端口与拦截器区分身份，没有服务间调用。部署简单，但三套服务要同时升级。
• 多环境靠 profile 文件硬切：application-admin-local.yml 与 application-admin-open.yml 各存一份数据源，application.yml 里 profiles.active 默认写的是 admin-open,security。
• XXL-Job 源码直接内置：zkmall-xxl-job 是一份完整的调度中心源码（含 xxl-job-admin），需要自己起调度中心才能用定时任务。
• RSA 加密是自定义协议：前端 src/utils/rsaEncrypt.js 与后端配置必须使用同一对密钥，换行符必须去掉，否则所有请求解不开。

4. 目录结构

代码包内部分层统一：controller、service、dao、redis、pay、jobs、interceptor、param、utils。三个服务的 Controller 数量分别是 30（admin）、21（business）、19（app）。

5. 快速上手

前置条件

文档给的环境表：JDK 17、MySQL 8.0+、Maven 3.8.3+、Redis 5.0.0、Node.js 20.18.0。另外要准备一个 XXL-Job 调度中心（默认指向 127.0.0.1:8081/xxl-job-admin）。

第一步：拿到完整 SQL，建库导入

这一步是门槛。仓库 sql/ 里没有全库脚本，需要按 README 进 QQ 群取，或走官网商务渠道。拿到后：

mysql -uroot -p -e 'CREATE DATABASE zkmall DEFAULT CHARSET utf8mb4'
mysql -uroot -p zkmall -e 'source /path/to/zkmall.sql'

表统一用 cere_ 前缀，例如商品、订单、权限表都是这个前缀。

第二步：改配置

三个服务都要改，重点四处：

• 数据源：application-*-local.yml 或 application-*-open.yml 里的 url、用户名、密码；
• Redis：默认 127.0.0.1:6379，库号 admin 用 1；
• JWT：application-security.yml 里的 base64-secret，必须换成自己生成的 88 位以上 Base64 串；
• RSA：按部署文档用在线工具生成密钥对，后端填配置，前端填 src/utils/rsaEncrypt.js，粘贴时去掉换行。

文档还要求配置超级管理员手机号（用于查看完整手机号等敏感信息）、App 服务刷新商品校验码、快递鸟或快递 100 的账号（在 cere_platform_express 表插一条记录）。

第三步：构建与启动

mvn clean package -DskipTests

java -jar zkmall-admin/target/zkmall-admin-enterprise.jar
java -jar zkmall-business/target/zkmall-business-enterprise.jar
java -jar zkmall-app/target/zkmall-app-enterprise.jar

产物名以各模块 finalName（等于 artifactId）为准。也可以直接在各模块里跑启动类的 main 方法，文档就是这么写的。

第四步：起前端

平台端与商家端仓库各自 npm install 后 npm run dev；UNIAPP 仓库用 HBuilderX 打开，npm install 后编译到 H5 或小程序。三套前端都要改 rsaEncrypt.js 里的公钥，并指向对应后端端口。

第五步：验证

curl -I http://127.0.0.1:9003/swagger-ui
curl -I http://127.0.0.1:9007/

文档页面能开说明 admin 服务起来了；买家端接口要配合 H5 才能验。定时任务相关功能需要先启动 XXL-Job 调度中心并在其中注册执行器，否则 xxl.job.enable=true 的配置会一直刷连接失败日志。

6. 功能模块清单

7. 版本与授权

AGPLv3 的实际含义，比 Apache-2.0 严格得多：

• 你可以商用、可以改，但一旦把修改后的程序作为网络服务对外提供（商城天然属于这种），就必须向使用者提供完整对应源码；
• 分发时必须带上许可证与修改说明；
• 与 GPL 不同，AGPL 把「SaaS 使用」也算作分发触发条件，这正是商城项目选 AGPL 的原因——想闭源商用就得买商业授权；
• 文件头又写「All rights reserved」，与 AGPL 的授权表述并存，严格说存在冲突。要走商用，以官方书面商业授权为准，不要拿「仓库里有 AGPL 全文」当免费商用依据。

另一个细节：zkmall-xxl-job 是第三方项目（XXL-Job，GPLv3）的整份源码，混在同一个仓库里。二次分发时两个协议的义务要分别履行。

8. 商业模式说明

这是标准的「开源版引流 + 商业版收费 + 定制服务」结构，且开源版刻意留了一道门槛：

把 SQL 放在群里，是一种很有效的「留资」设计：代码你能看，但要真正跑起来，得先加群或联系商务。对评估者来说这意味着试用成本被前置——在决定是否投入之前，你没法先跑一遍验证功能边界。

事实与宣传要分开看：README 里「开箱即用」「功能全面」「马上可以投入经营」属于官方宣传口径；可核对的事实是代码规模（1502 个 Java 文件）、技术栈版本（Boot 3.4.7 / Java 17）、以及仓库里确实没有建库脚本。

9. 生态与周边

生态上要说清楚：没有 Docker Compose、没有 Helm、没有公开的镜像仓库，Dockerfile 只解决单服务打包；数据库、Redis、调度中心都要自己备。文档只有 doc/ 下一篇部署说明和官网价格页，没有完整的开发手册与 API 手册。

10. 选型建议

适合你，如果：

• 团队是 Java 栈，想要 Spring Boot 3 + Vue3 的现代组合，而不是 PHP 系商城；
• 你要做多商户平台，且能接受 AGPLv3 或直接买商业授权；
• 你有能力自己补齐缺失的建库脚本、部署脚本与运维体系；
• 你愿意为「省下从零写商品/订单/营销」而接受一套 1500 个类的中型代码库。

不适合你，如果：

• 你想先在本地跑通再决策——没有 SQL，跑不起来；
• 你要求协议明确的宽松授权（Apache/MIT），AGPLv3 会约束你的闭源商业化；
• 你需要开箱即用的部署包（Compose、初始化数据、安装向导），这套没有；
• 你只做单店商城，多商户的角色与权限会变成负担。

和同类怎么比：和 ShopWind（Yii2/PHP）、CRMEB、NIUSHOP 比，这套的优势是运行时更现代（Boot 3.4 / Java 17 / Vue3 / UNIAPP，不是 PHP 7.4 那种已停止维护的组合）；劣势是交付完整度更低（ShopWind 至少带 structure.sql 与演示数据，这套连建库脚本都要另取），授权也更严（AGPL 对 SaaS 有传染性）。选型时把「能不能拿到完整 SQL 与文档」和「授权是否可接受」放在功能对比之前。

11. 风险与坑

• 没有完整建库脚本：sql/250917.sql 只有 1.1 KB，一张 AI 问答表加两条菜单权限。没有全库结构就无法启动，必须进群或买商业版。这是第一道门槛。
• 默认激活的是 open 环境而非 local：application.yml 里 profiles.active: admin-open,security，意味着你改 application-admin-local.yml 不会生效，很多人会卡在这里。
• 数据库口令明文入库：默认配置里 username: root、password: 12345678，且 spring.datasource.url 指向 zkmall-v3-open。上生产前必须全量替换并改掉默认库名。
• JWT 密钥是占位串：application-security.yml 的 base64-secret 由大量重复字符拼成，明显是示例值。不换等于任何人可伪造管理员令牌。
• XXL-Job 默认开启但地址指向本机 8081：open 配置里 enable: true、admin-addresses 指 127.0.0.1:8081，没起调度中心就会持续报连接失败，还可能影响定时任务相关业务。
• 三个服务共用一个库、必须同时升级：admin 改了表结构，business 与 app 不跟着发版就会出字段错误。没有数据库迁移工具（Flyway/Liquibase），升级靠手工执行 SQL。
• 前端是三套独立仓库：b2b2c-admin、b2b2c-merchant、b2b2c-uniapp 都不在后端仓库里，版本对齐没有任何机制保证，只能按 README 与提交时间自己判断。
• RSA 密钥配对是硬要求：后端配置与前端 rsaEncrypt.js 必须同一对密钥，且粘贴不能带换行。配错的表现是「所有接口 500 或解密失败」，排查成本高。
• cert/wechat 目录是空的：微信支付证书要自己申请放入，README 与文档都没给校验步骤，容易到支付环节才发现。
• AGPLv3 的传染性：把改过的版本作为商城对外服务，就要向用户提供源码。想闭源必须买商业授权，别只看「代码能下载」。
• 文件头与许可证冲突：All rights reserved 加商务电话，与 AGPLv3 并存。真要商用，取书面授权，别自行解释。
• 标签与版本号不一致：唯一标签 v1.9.10，POM 版本 3.5.0，没有 changelog、没有 release 说明。想回退某次改动只能翻提交记录。
• 内置 XXL-Job 是 3.0.0-SNAPSHOT：快照版本混进主仓库，与 2.5.0 客户端的兼容性要靠自己验；这也会让构建产物里混入第三方 GPL 代码。
• 增量 SQL 用 utf8 而非 utf8mb4：cere_ai_default_question 表是 CHARSET=utf8，存 emoji 或生僻字会出问题，二次开发建表时注意统一。
• Star 数不等于可用度：10.8K Star 与 7 个 Issue、3 个 PR 的组合说明社区讨论极少，问题基本只能走群或商务，遇到坑缺少公开检索记录。

12. 参考链接

本文基于 2026-11-10 对 master 分支的浅克隆源码（pom.xml、三个服务的 application.yml、doc/README.md、sql 目录、模块包结构、license-header.txt）、README 与 Gitee 项目页整理；Star、Fork、Issues、标签与最后提交时间均以该日为准。仓库未包含完整数据库脚本，功能是否全部在开源版可用需以实际运行结果为准。*