# Lilishop: a B2B2C multi-merchant mall built on Spring Boot 3 and uni-app

> Lilishop is an AGPL-3.0 Java mall platform covering platform admin, seller admin, PC, H5, mini program and app from one codebase. The interesting part is the microservice split and the Docker deployment path; the hard part is the licence and the version drift between the 2022 releases and the current master branch.

**lilishop/lilishop** — Java 开源商城系统，基于 Spring Boot / Spring Cloud / Vue / Uniapp 的 B2B2C 多商户商城源码，支持小程序商城、微服务、分销、直播、秒杀、Docker 私有化部署。

- Repository: https://github.com/lilishop/lilishop
- Website: https://pickmall.cn
- Stars: 4,317 · Forks: 1,043
- Language: Java
- License: AGPL-3.0
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/lilishop-lilishop

## The problem Lilishop solves: one mall, three audiences, four front ends

Most open source storefronts are single-merchant. You install them, you get one admin panel, one product catalogue, one checkout, and that is the end of the model. Lilishop starts from a different premise: a platform operator who hosts many independent merchants, each with their own store, their own staff and their own settlement. That is the B2B2C shape, and it changes almost everything downstream. Orders belong to a store as well as to the platform. Promotions can be platform-wide or store-scoped. The admin surface splits in two, which is why the repository carries both a manager-api module and a seller-api module rather than one backend.

The audience is therefore narrower than a generic shop script. It is a team building a marketplace: an operator onboarding merchants, a Java shop that wants a working multi-vendor core rather than a greenfield build, or a company doing a private deployment where the code has to sit on its own infrastructure. The README lists exactly these cases, including secondary development on the Java source and study of the source itself.

The front end follows the same split. The management consoles for platform and merchant are Vue with iView, Vuex, Vue Router and axios. The customer-facing side is uni-app with uViewUI and SCSS, which is what lets one codebase target H5, WeChat mini program and app. If you only need a PC storefront, most of that structure is overhead you are carrying anyway.

## How the services are split and where the data flows

The top-level directories tell you the architecture before you read a line of Java. buyer-api, seller-api, manager-api, im-api and consumer sit alongside common-api and framework. That is a service-per-audience split: the buyer service handles browsing and ordering, the seller service handles merchant operations, the manager service handles platform operations, and im-api covers messaging. consumer is the module that would host RocketMQ listeners. framework and common-api hold the shared code that all of them depend on.

The backing stack is heavyweight and the README is explicit about it. Spring Boot 3.5.6 with MyBatis-Plus 3.5.8 for persistence, MySQL 8.3.0, Redis for caching, Elasticsearch for product search, RocketMQ 2.3.4 for asynchronous work and decoupling, ShardingSphere 4.0.0 for horizontal data scaling, XXL-Job 2.3.0 for distributed scheduling, Spring Security for auth and JWT for tokens. There is a dedicated xxl-job directory at the repository root, so the scheduler is a deployable component, not just a library.

Two consequences follow. First, order placement is not a synchronous database write. RocketMQ sits between the request and the downstream work, which is standard for flash sales and for the distribution commission logic the project advertises. Second, product search is not a SQL LIKE query. Elasticsearch is a required service, and a deployment without it will lose search functionality rather than degrade gracefully. The documentation does not describe fallback behaviour when Elasticsearch is unavailable, so treat it as a hard dependency.

## Installing Lilishop and reaching a first working mall

The README does not give a step-by-step local install. It points to the deployment guide at docs.pickmall.cn/deply/deply.html for environment preparation, and it recommends the project's docker-compose configuration as the way to bring up and initialise the database services. That compose file lives in a separate repository, not in this one, so the first thing to check is that the branch you clone matches the branch the compose file expects.

The README gives the GitHub repository address directly, and the default branch is master. The README also notes that the demo environment is deployed from master.

```bash
git clone https://github.com/lilishop/lilishop.git
```

After cloning, confirm you are on the default branch. The repository entry list at the top level includes pom.xml, DB/, config/, deploy-api.yml, docker-image.sh and the service directories, so a correct checkout should show all of them.

If you deploy manually instead of using compose, the README points at SQL scripts hosted in the project's docker repository under init/mysql. It adds a warning worth repeating: make sure the SQL file version matches your code version. That warning exists because it has bitten people. The DB directory is present at the repository root, so there is local database material to compare against the remote scripts. Whether the two are always in sync is not stated in the README.

Once the services are up, the fastest way to see the system working without deploying anything is the hosted demo. The README gives the platform admin console at admin-b2b2c.pickmall.cn with account admin and password 123456, the store console at store-b2b2c.pickmall.cn with account 13011111111, and the PC storefront at pc-b2b2c.pickmall.cn. Phone verification codes on the demo are fixed at 111111, which is what makes the demo usable without a real SMS provider. Log into the platform console first: if you cannot see the merchant list and the platform-level promotion screens, the deployment is not what the documentation describes.

## The AGPL-3.0 licence is the real adoption constraint

The README is unusually blunt about this, and it is the single most important thing to read before writing any code. The project is AGPL-3.0, and the README states the permitted scope as personal study, research and non-commercial use only. It explicitly forbids using the code or resources for commercial sale in any form. Commercial use requires authorisation from the vendor, described as a one-time permanent licence with continued version upgrade service. The software is also registered under a Chinese software copyright, registration number 2021SR0805085.

This is not a case where AGPL-3.0 alone governs. The README layers additional restrictions on top of the licence, which is a common pattern for Chinese dual-licensed mall projects and a genuine source of ambiguity for anyone outside that context. If you plan to run a commercial marketplace on this code, the practical path is to contact the vendor through the channels listed in the README rather than to reason your way around the licence text. Nothing here is legal advice, and the discrepancy between the AGPL-3.0 file and the README's usage clause is exactly the kind of thing a lawyer should look at, not an engineering blog.

For internal evaluation and for reading the source to learn how a multi-merchant order model is structured, the terms are not a barrier. For shipping a product, they are.

## Version drift between the releases and master

The most recent tagged release is v4.2.4 from 2022-02-15, preceded by v4.2.2 in 2021-09-22 and v4.2.0 in 2021-06-30. The last push to the repository was on 2026-06-13. That gap is the defining maintenance fact about this project: development has continued on master for years after the last release tag, so the release list does not describe the current code.

The README's technology table confirms the drift. It lists Spring Boot 3.5.6, MyBatis-Plus 3.5.8 and MySQL 8.3.0. A project whose last tagged release was in February 2022 was not running Spring Boot 3.5.x at that time. The upgrade from Spring Boot 2 to 3 is not cosmetic either: it moves the baseline to Java 17 and touches the javax to jakarta namespace change across the whole codebase, which affects every third-party integration. Anyone pinning to v4.2.4 is adopting a materially older stack than the one documented.

The practical implication is that master is the only branch worth evaluating, and that you should read pom.xml rather than the README tables when you need exact versions. It also means upgrade cost is on you. There is no published migration guide in the README, and the release cadence suggests you should not expect one.

## Where Lilishop is the wrong tool

If you want a single-merchant shop, Lilishop is the wrong shape. The multi-merchant model is not a feature flag you can switch off. Store ownership runs through the order, product and settlement schema, and the seller-api service exists to serve merchants who, in a single-merchant deployment, do not exist. You would be deploying and maintaining a service, a scheduler and a message broker for no reason.

If your infrastructure is small, the dependency list is the problem. MySQL, Redis, Elasticsearch, RocketMQ, ShardingSphere and XXL-Job are all named in the architecture table. That is a lot of operational surface for a shop doing modest volume, and each one is a component that can fail independently. ShardingSphere in particular is listed for horizontal data scaling, which is a capability you pay for in configuration complexity long before you need it.

If you need a commercially licensed product without paying for one, this is not it, and the README says so directly. And if you need a fast-moving upstream with frequent tagged releases to track, the release history argues against that expectation: three tags, all from 2021 and early 2022.

## Alternatives and how their approach differs

The related searches around this project are dominated by other Java mall systems, and the comparison is worth making concrete rather than gestural.

Mall4j is a Java mall project in the same language ecosystem, but it targets a single-merchant model rather than a platform hosting many merchants. If you do not need merchant onboarding and per-store settlement, Mall4j's simpler shape removes the seller service and the platform-versus-store admin split entirely. That is a real reduction in code and in deployment units.

CRMEB and ShopXO sit closer to the private-deployment commerce space. CRMEB is known for social commerce and distribution features with a PHP-based lineage, which changes the hiring and hosting picture substantially if your team is Java-only. ShopXO is a PHP mall system with a plugin-oriented extension model, so customisation happens through plugins rather than by forking a Spring service. If your team writes PHP, both avoid the JVM stack entirely.

Tigshop and JooLun appear in the same search cluster as other Java mall options. The axis that matters when comparing any of them to Lilishop is the same: does the project model one merchant or many, and does it ship a microservice split or a monolith. Lilishop has chosen many merchants and microservices. That choice is the source of both its completeness and its operational weight, and no amount of feature-list comparison substitutes for deciding which side of that line you need.

## What to verify before committing

Check the branch. Master is where development has continued since the last release tag in 2022, and the README ties the demo deployment to master. Cloning a release tag gives you a stack from a different era of the project.

Check the SQL scripts against your code. The README warns that the database scripts must match your code version, and the scripts are hosted outside this repository. Compare the DB directory at the root with the remote init/mysql scripts before you import anything.

Check the compose file. The README recommends docker-compose for automatic database deployment and initialisation, and that configuration lives in the separate docker repository. Confirm it targets the same branch you cloned.

Check the licence question with the vendor, not with the AGPL text alone. The README's usage clause is narrower than the licence file, and the commercial authorisation is described as a one-time permanent licence with ongoing upgrade service. That is a commercial decision with a support relationship attached, and it should be settled before engineering effort is spent.

## Conclusion

Lilishop fits teams that need a full B2B2C mall skeleton with separate platform, seller and buyer services, and that accept AGPL-3.0 terms or will buy the commercial licence. It does not fit anyone who wants to ship a closed-source commercial product without paying, or who needs a small dependency footprint: the stack pulls in MySQL, Redis, Elasticsearch, RocketMQ, ShardingSphere and XXL-Job before a single order is placed. Before adopting it, verify three things against the documentation at docs.pickmall.cn: which branch the SQL scripts in the DB directory match, whether the docker-compose configuration in the separate docker repository is current with master, and whether the commercial licence covers the deployment model you intend.

## FAQ

### What is Lilishop and what kind of mall does it build?

Lilishop is a Java open source mall system built on Spring Boot, Spring Cloud, Vue and uni-app, and it implements a B2B2C multi-merchant model where a platform hosts many independent stores. It covers platform admin, seller admin, PC, H5, mini program and app, with distribution, live commerce and flash sale features listed in the README.

### How do I install Lilishop?

The README does not give a step-by-step install; it points to the deployment guide at docs.pickmall.cn/deply/deply.html for environment preparation. It recommends the project's docker-compose configuration, hosted in a separate docker repository, as the way to deploy and initialise the database services automatically, with manual SQL scripts available under init/mysql.

### Can I use Lilishop for a commercial project?

The README states the project is AGPL-3.0 but restricts use to personal study, research and non-commercial purposes, and forbids commercial sale of the code or resources. Commercial use requires authorisation from the vendor, described as a one-time permanent licence with continued version upgrade service.

### Which database and middleware does Lilishop require?

The architecture table lists MySQL 8.3.0 for relational storage, Redis for caching, Elasticsearch for product search, RocketMQ 2.3.4 for asynchronous tasks, ShardingSphere 4.0.0 for horizontal data scaling and XXL-Job 2.3.0 for distributed scheduling. Spring Security handles authentication and JWT is the token scheme.

### Is Lilishop still being developed?

The repository is not archived and the last push was on 2026-06-13, so work has continued on master after the last tagged release. The three releases listed are v4.2.4 from 2022-02-15, v4.2.2 from 2021-09-22 and v4.2.0 from 2021-06-30, so the release tags do not describe the current code.

## Sources

- [License: AGPL-3.0](https://github.com/lilishop/lilishop/blob/master/LICENSE)
- [lilishop/lilishop on GitHub](https://github.com/lilishop/lilishop)
- [Project website](https://pickmall.cn)
- [README](https://github.com/lilishop/lilishop/blob/master/README.md)
- [Releases](https://github.com/lilishop/lilishop/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/lilishop-lilishop