带多租户和代码生成的 Java 中后台框架（ContiNew Admin）

做一套带权限、组织架构、操作日志和租户隔离的中后台系统，登录鉴权、菜单权限、数据权限、字典项、文件上传、消息通知这些模块几乎每个项目都要重写一遍。选型落后一两个大版本，升级代价会落到后面几年。

ContiNew Admin 是一套用 Java 写的多租户中后台管理框架，输入数据表和业务字段，输出带权限、日志、代码生成的前后端管理后台。

后端的组合是 Spring Boot 3（Java 17）配 Sa-Token、MyBatis Plus、Redisson、JetCache、JustAuth、Crane4j、SpringDoc、Hutool；前端是 Vue3 加 Arco Design、TypeScript 和 Vite。仓库默认分支为 dev，最近一次提交是 2026 年 10 月 6 日，Star 2125，Fork 457，Watcher 14，开放 Issue 11 个。项目地址在 https://github.com/continew-org/continew-admin，采用 Apache License 2.0，主要语言是 Java，占仓库语言比例 97.9%。

五分钟先跑通

运行环境要求 Java 17，后端是一个 Maven 多模块工程。仓库根目录里有 pom.xml、mvnw、mvnw.cmd，另有 docker/ 与 style/ 两个目录。后端模块包括 continew-common、continew-system、continew-auth-refresh、continew-extension、continew-plugin、continew-server。

前端不在这个仓库里，需要另外拉取适配项目 continew-org/continew-admin-ui。

git clone https://github.com/continew-org/continew-admin.git
git clone https://github.com/continew-org/continew-admin-ui.git

组件依赖上，Redisson 与 JetCache 指向 Redis，MyBatis Plus 指向关系型数据库。Issue 区出现过 PostgreSQL 的 SQL 兼容问题，说明支持的数据库不止一种，完整清单仓库节选里没有列全。

README 节选没有给出完整的启动命令、数据库初始化脚本路径和默认端口，这几步仓库里没有说明，以官方在线文档 continew.top 为准。

跑通之后你会得到什么

启动起来看到的是一套现成的后台：登录、个人中心、用户管理、角色管理、组织管理、系统配置、系统日志、消息中心、通知公告都在内置模块里，第三方登录、邮箱与短信服务也一并配有。

后端这边，接口文档由 SpringDoc 生成。数据表设计完之后跑代码生成器，会产出前端页面与后端 CRUD 代码。

产出散在三处：跑起来的前端页面、接口文档页面、以及代码生成器落到工程里的源码文件。接下来要做的事是把生成出来的骨架改成真实业务逻辑，或者直接取用 ContiNew Starter 里的组件放进自己已有的项目。

主要功能

CRUD 套件：增删改查被封装成「注解 + 基类」的形式，控制器继承 BaseController 并声明需要的接口类型，一次就能拿到新增、修改、批量删除、查询详情、分页列表、全部列表、树型列表、Excel 导出和字典列表。

@Tag(name = "部门管理 API")
@RestController
@CrudRequestMapping(value = "/system/dept", api = {Api.TREE, Api.GET, Api.CREATE, Api.UPDATE, Api.DELETE, Api.EXPORT, Api.TREE_DICT})
public class DeptController extends BaseController<DeptService, DeptResp, DeptDetailResp, DeptQuery, DeptReq> {}

示例里的 api 数组决定这组接口开放哪些能力，可以按需裁剪或扩展。

代码生成器：数据表设计完成后做简单配置，即可生成前后端 80% 的代码，包含 CRUD 接口、权限控制、参数校验和接口文档；业务不复杂时能覆盖到 95%。v3.5.0 给生成预览加了批量能力，并新增 Mapper.xml 模板。

多租户：v4.0.0 加入多租户插件模块，配合基于 RBAC 的权限控制与通用数据权限管理，用于 SaaS 场景下按租户隔离数据。

文件管理：v3.7.0 支持目录层级，v4.1.0 加入多文件分片上传，存储后端覆盖本地存储和 S3 存储两种。

登录与消息渠道：第三方登录基于 JustAuth，v4.1.0 补了微信开放平台的登录配置示例；v3.6.0 加入短信配置，v3.7.0 让短信渠道支持用数据字典配置。

缓存与链路追踪：JetCache 提供注解式方法级缓存，支持二级缓存配置与分布式自动刷新，v3.6.0 增加了字典和菜单的缓存清除接口。开发期还有 P6Spy 观察 SQL 执行性能，TLog 在日志里定位单次请求的完整链路。

Starter 组件库：从 v2.1.0 起，后端基础组件与各框架集成配置被抽到 ContiNew Starter，已发布到 Maven 中央仓库，可以脱离整套框架单独引入使用。

工程化配置：后端集成统一版本管理和编译时自动代码格式化，提供配置文件、第三方依赖与主程序分离的打包方式，以及一套 Docker Compose 部署脚本。全局 Lombok 配置在继承场景默认带上 @EqualsAndHashCode(callSuper = true) 与 @ToString(callSuper = true)，同时禁用了 @Val、@Log4j 这类注解。

常用参数与配置

接触最多的参数是 @CrudRequestMapping：value 写接口前缀路径，api 用 Api 枚举数组声明开放哪些能力，取值包括 Api.TREE、Api.GET、Api.CREATE、Api.UPDATE、Api.DELETE、Api.EXPORT、Api.TREE_DICT。

部署配置放在 docker/ 目录，仓库提供环境与应用的 Docker Compose 脚本。打包方式支持把配置文件、第三方依赖和主程序分开，改配置不必重新打包。

业务侧的开关大多以插件或独立模块的形式存在，例如多租户插件模块、文件存储的本地与 S3 选择、短信渠道的数据字典配置。

至于 application.yml 里具体有哪些字段、Redis 与数据库连接怎么填，仓库节选没有列出，这部分要看官方在线文档。

结果在哪里看

前端页面是主要入口，用户、角色、组织、日志、消息这些模块都能在界面上直接操作。

接口层面看 SpringDoc 生成的接口文档页面。

代码生成器的产出是源码文件，生成后落到工程对应目录，v3.5.0 之后可以同时选中多张表批量生成。

运行日志走终端输出，链路追踪信息由 TLog 写在日志里。默认端口、初始账号这些内容仓库节选没有说明。

实际使用中的坑

PostgreSQL 兼容问题：有 Issue 反馈 UserPasswordHistoryMapper.xml 里的 SQL 语法不兼容 PostgreSQL，根源在 SQL 写进了 Mapper XML。这条已经解决，用 PostgreSQL 的团队仍需留意自己添加的 XML 语句。

多级菜单展示异常：开启多级菜单后，上级菜单会被吃掉，界面只展示最底层的菜单。已解决。

代码生成器接口报错：在 release 4.0.0 上生成代码后报错，问题定位到 dev 分支的 continew-plugin/continew-plugin-generator/src/main/resources/templates/frontend/api.ftl 第 71 行。已解决。

租户表前缀：其他表都有前缀，租户表没有，有用户提出加上。这条目前仍是待解决状态。

刷新 token：有 Issue 提出增加刷新 token 的功能，同样处于待解决状态。

选型参考

ruoyi-vue-pro 与本项目重合在 Java 后台底座这一层，不重合的地方在于它覆盖的场景更宽。只缺一套前端管理界面的团队，引入 ContiNew Admin 会连后端一起带进来，模块数量和分层约束比单拿一个前端模板更重，这种场景先看 SoybeanAdmin。ruoyi-vue-pro 的 Star 数是 39,562，本项目是 2,125，社区体量差一个量级，看重现成插件和第三方教程的团队值得把两者放在一起比。

什么情况下别用它

团队技术栈是 Node、Go 或 Python，别用。整套框架建立在 Java 17 与 Spring Boot 3 上，换语言的成本高于重写。

只需要一套前端管理界面，后端已经跑得挺好，别用。前端适配项目本来就是独立仓库，单拉前端更省事。

想要拖拽配置、一句话生成整个系统的低代码体验，别用。这里的代码生成器产出的是前后端源码，剩下 20% 甚至 5% 的逻辑要自己写。

业务简单到只有几张表、不做多租户，也别用。多租户插件、数据权限、消息中心这些模块在简单场景里只会变成需要读懂的额外代码。

必须前后端同仓管理、不接受两个仓库分别拉取，这个项目不满足，另外找单体仓库的方案。

焚评：这个项目的量化评分

本项目的选题来自 焚.com（一个按公开公式给 GitHub 项目打分的站）。焚评当前总分 9.3 分（满分 10）。下表是各维度的得分：

评分口径、权重与计算方式见焚.com 的评分方法页；数据随 GitHub 指标刷新，具体数值以焚.com 当前页面为准。本文正文为诀.com 独立撰写，评分数据由焚.com 授权引用。