简介橙单中台化低代码生成器是一套面向企业级应用开发的完整工程源码适合需要快速搭建多应用、多租户、多渠道系统的开发团队与技术负责人。它集成了 Flowable 与 Activiti 双工作流引擎、在线表单、自定义数据同步、自定义 Job、多表关联及跨服务多表关联等能力并支持按项目实际需求自由组合前端与后端技术栈大幅降低复杂业务系统的构建门槛。压缩包共 2002 个文件以 1218 个 Java 源码文件为核心辅以 308 个 Vue 页面、191 个 JS 脚本、137 个 XML 配置及多份 properties 配置文件可完整支撑后端逻辑、前端交互与系统配置的二次开发包体约 21.47MB结构清晰。目前已有 100 人学习下载。资源中附有橙单若依环境使用手册及 SQL、Shell 等辅助文件便于开发者快速搭建环境、理解整体工程脉络并直接用于定制扩展。1. 低代码生成器啃中台橙单把多租户和工作流装进同一个工程橙单中台化低代码生成器很多人第一反应是“又是拖拽表单生成 CRUD”真正上手才发现它把多应用、多租户、多渠道、工作流这种中台底座直接生成出来。我拆这套资源时印象最深的是它没有把低代码做成黑匣子生成的是可读工程代码Flowable 与 Activiti 两套工作流引擎都能接在线表单、自定义数据同步、自定义 Job、多表关联甚至跨服务关联都有生成项。它适合两类人一类是做产品化交付的程序开发想在多个项目里复用同一套中台骨架另一类是做技术选型的熟手想摸清不同技术栈组合下生成器的边界。整包带 viewer.html 预览页和配套样式另附环境手册 docx。这篇把拆包逻辑、关键参数和翻车点按顺序讲清楚。2. 工程结构与多租户设计从 viewer 预览页到租户字段的三个落地层次拆包先看结构。整套资源不是一上来就甩一堆生成模板而是先放了一个 viewer.html 预览体系和一份环境手册 docx。这个顺序有讲究先用预览页确认生成器能输出什么再动手配环境。很多人拿到手直接去初始化数据库结果预览都没打开过环境变量配错一路走到最后才发现方向偏了返工成本全花在排查上。2.1 先盘文件清单viewer.html、样式表与手册各自管什么文件在包里的定位你会不会动它viewer.html生成结果预览入口读取页面 JSON 渲染界面预览时打开一般不修改ie.html旧版浏览器兼容入口基本不碰viewer.css / index.css预览页基础样式与布局想改预览效果时调整debugger.css调试态高亮布局、字段边界排查撑破布局问题时临时启用print.css打印表单、报表时隐藏操作按钮打印导出场景生效iconfont.css图标字体定义与 font-face 声明换图标时需要动.DS_StoremacOS 打包残留直接忽略环境手册.docx部署前置项数据库、缓存、存储、引擎初始化按它过一遍环境viewer.html 是典型的“配置驱动预览”生成器把页面描述序列化成 JSON字段、布局、按钮、校验规则全部放在 JSON 里预览页读取后用 viewer.css 渲染。这样你还没生成前后端工程就能先确认表单和列表长什么样避免生成完才发现字段配错。iconfont.css 里的 font-face 声明指向字体文件预览页图标全靠在它下面挂载的字体资源debugger.css 是调试样式打开调试开关后每个布局块会加虚线边框定位字段撑破布局非常直观print.css 会在打印时把操作列隐藏只保留业务内容。环境手册 docx 不在代码里但它是整套东西能不能跑起来的前置条件。常见做法是先把数据库初始化脚本、Redis、文件存储这三项按手册过一遍再去看生成器配置。手册里写的环境变量或配置项建议单独抄到一个本地配置备忘里别在多个文档窗口里反复翻。2.2 多应用与多租户表结构里的租户字段与上下文传递中台化生成器做多租户通常不是生成时把代码复制 N 份而是数据隔离加上下文传递。橙单这类生成器的典型产出是每张业务表带 tenant_id登录后把租户 ID 放入上下文数据访问层用一个拦截器统一拼 tenant_id 条件。// 租户上下文请求线程内持有当前租户 public class TenantContext { private static final ThreadLocalString HOLDER new ThreadLocal(); public static void set(String tenantId) { HOLDER.set(tenantId); } public static String get() { return HOLDER.get(); } public static void clear() { HOLDER.remove(); } }// MyBatis 拦截器查询时自动追加租户条件 Intercepts({ Signature(type StatementHandler.class, method prepare, args {Connection.class, Integer.class}) }) public class TenantInterceptor implements Interceptor { Override public Object intercept(Invocation invocation) throws Throwable { // 从 BoundSql 取原始 SQL解析主表别名 // 常见做法把 tenant_id #{tenantId} 拼到 WHERE 末尾 // 注意关联查询、子查询里的表也要处理否则会漏 return invocation.proceed(); } }第一个类把租户 ID 放在 ThreadLocal 里登录过滤器里 set请求结束 clear避免线程池复用导致串租户。第二个类是拦截器核心动作是改写 SQL 前先解析不是简单字符串拼接——如果表带别名拼接时要用别名而非表名否则带 schema 的数据库会报列名无效。多应用的区别在模块层面一个应用对应一组包名和表前缀生成的 controller、service、mapper 落在各自的包路径下互不引用。多租户加多应用叠加时请求头里同时透传 appCode 和 tenantId过滤器解析后写入上下文。这条线上最容易踩的坑是拦截器把不需要租户隔离的基础表也加了条件比如字典表、省市区表这类表在生成配置里要主动标记为“免租户”否则每次查询都多一个无用条件数据量一大性能问题就暴露了。2.3 多渠道接入统一响应结构与前端适配的边界多渠道指 Web、H5、小程序、App 共用一套后端接口。生成器在这块采用的通用策略是接口层只认 channel 参数业务层不感知渠道差异。生成产物里每个接口都返回统一结构public class ResultT { private int code; // 0 成功非 0 失败 private String msg; // 提示信息 private T data; // 业务数据 }前端按渠道差异做适配Web 端接收完整页面渲染小程序端拿 JSON 再渲染。登录态也不同Web 用 cookie小程序和 App 走 token 请求头所以生成器会同时生成登录过滤器和 token 校验过滤器。上面的统一结构里code 和 msg 前后端约定死了前端拦截器可以统一判断 code 是否为 0不为 0 直接弹出 msg不需要每个页面单独处理异常分支。参数上要注意多应用场景下渠道、租户、应用三者是一起透传的请求头建议统一带 appCode、tenantId、channel 三个字段网关或过滤器统一解析后写入上下文业务代码里不要再从请求里重复取。我一般会在生成后把这三个字段的校验单独写一个过滤器前置拦截非法请求避免在每个 controller 里手工取参数导致漏校验。3. 工作流与在线表单Flowable / Activiti 双引擎切换和表单数据回流工作流是中台化生成器里含金量最高的部分也是它和普通 CRUD 生成器拉开差距的地方。橙单同时支持 Flowable 和 Activiti不是两套代码各写一遍而是生成器按配置决定引入哪个引擎、生成哪套流程代码。这一章把它拆开讲清楚。3.1 Flowable 与 Activiti选型差异和切换配置这两个引擎血缘很近Flowable 是从 Activiti 5/6 分支出来的但发展路线已经分化。对使用者来说真正影响决策的是 Spring Boot 集成的活跃度、表结构差异和维护难度。对比项FlowableActiviti血缘从 Activiti 5/6 分支出来持续演进老牌 BPMN 2.0 引擎Spring Boot 集成官方 starter 维护活跃版本跟进快新版本配套 starter旧版坑多表结构ACT_ 前缀版本表独立ACT_ 前缀结构有历史包袱适合场景流程复杂、需要长期迭代维护团队已经很熟悉旧体系切换时生成器最关心的其实是三个配置引擎类型、数据库初始化脚本、BPMN 文件目录。常见做法是在 application.yml 里留一个开关orange: workflow: engine: flowable # flowable 或 activiti二选一 process-location: classpath*:processes/*.bpmn20.xmlengine 开关决定生成器引入哪个依赖、使用哪个 ProcessEngine 工厂process-location 指定 BPMN 文件扫描路径引擎启动时会自动部署该目录下的流程定义。切换后第一次启动引擎需要建表Flowable 走 flowable-schema-update 策略Activiti 走自身的建表脚本两者的表结构不完全兼容。库里已经存在一方引擎的表时直接切换启动必然报错具体现象和解决办法放在第 5 章。3.2 在线表单JSON Schema 描述字段渲染与流程共用一套定义在线表单的本质是“把表单定义数据化”。生成的表单定义存成 JSON字段类型、校验规则、布局全部写在 JSON 里运行期由渲染引擎解析。{ formKey: leaveApply, fields: [ { name: days, label: 请假天数, type: number, required: true, max: 30 }, { name: reason, label: 事由, type: textarea, required: true, maxLength: 200 } ] }type 字段决定渲染控件number 渲染数字输入textarea 渲染多行文本后续还能扩展日期、下拉、人员选择等类型。required 和 maxLength 这类约束写在定义里前后端共用一套校验规则避免前端验证过了后端又挡回去的尴尬。生成器会把这份 JSON 同时用于三处页面渲染、流程变量写入、列表查询条件。这意味着修改表单只需要改 JSON不需要改页面代码和接口代码。但三处共用也带来一个约束字段 name 必须全局唯一且不能随意改名否则已发起的流程实例里存的变量名和新的表单定义对不上历史数据回填就会丢。3.3 表单数据回流到流程启动、审批、驳回的数据链流程启动时表单值要写进流程变量否则下一个节点拿不到。常见做法是在启动流程的 service 里把 JSON 展开成变量写入// 启动流程实例并把表单数据写入流程变量 MapString, Object variables new HashMap(); variables.put(days, form.getDays()); variables.put(reason, form.getReason()); ProcessInstance pi runtimeService.startProcessInstanceByKey( leaveApply, businessKey, variables);businessKey 把流程实例和业务表主键绑在一起审批结束后逆查业务数据全靠它variables 里的字段名要和流程条件表达式里用到的变量保持一致比如审批节点判断 days 是否小于 3 走不同分支变量名写错分支就永远走不对。驳回场景下引擎会回到上一节点表单重新渲染时从流程变量取值回填。这里有个常见误用把整个表单 JSON 作为一个变量存入而不是展平字段取的时候又要解析 JSON回填逻辑复杂且容易出错。我一般建议展平存储保持字段名和表单 name 一一对应后续要追溯某个字段的历史值直接查流程变量表也比解析 JSON 快得多。4. 数据同步、自定义 Job 与多表关联把中台的数据关系盘活中台项目的痛点通常不在单表 CRUD而在数据流转源系统数据怎么进中台、定时任务怎么管理、跨服务数据怎么聚合。这一章对应橙单的三个生成能力自定义数据同步、自定义 Job、多表关联与跨服务关联。4.1 自定义数据同步增量拉取、幂等写入与冲突策略数据同步的本质是配置一张映射关系源表、目标表、增量字段、主键映射、同步频率。生成器把这张映射做成可视化配置运行时按配置生成执行器。// 同步任务执行器按增量字段拉取并 upsert public void sync(String sourceTable, String targetTable, String incrField, LocalDateTime lastSyncTime) { ListMapString, Object rows sourceJdbcTemplate.query( SELECT * FROM sourceTable WHERE incrField ?, new Object[]{lastSyncTime}); for (MapString, Object row : rows) { // 以业务主键判断存在则 update不存在则 insert upsert(targetTable, row); } // 同步结束后推进游标避免下次重复拉取 syncCursorCache.put(sourceTable, getMaxIncrTime(rows)); }增量字段一般选自增 id 或 update_time。自增 id 只增不改适合只追加的数据update_time 能覆盖更新场景但同一秒内多条更新可能被截断常见做法是把增量条件往前多留 5 秒做重叠窗口用主键幂等去重。幂等靠目标表唯一键写入用“先查再插或更”的 upsert同步失败重跑不会产生重复数据。冲突策略默认是“目标表最新一条生效”如果源系统有删除场景还得加一个删除标记字段同步否则目标表里永远留着已删除的数据。4.2 自定义 Job调度注册、参数透传与失败重试生成器把 Job 做成“配置化任务类 调度注册”的结构。每个任务对应一个类配置里声明 cron 表达式和参数项。Component public class OrderStatJob implements OrangeJob { Override public void execute(JobContext context) { String bizDate context.getParam(bizDate); // 每次执行可传不同值 int retryCount context.getRetryCount(); try { statService.rebuild(bizDate); } catch (Exception e) { // 记录失败状态交给调度中心按策略重试 context.markFailed(e.getMessage()); } } }调度注册有两种常见做法生成器自带调度表代码里注册 cron或者对接外部调度中心生成器只产出执行器。参数透传是容易忽略的点bizDate 这类参数每次执行可能不同JobContext 里要支持从触发记录里取参数而不是从配置文件里读死值。重试必须有次数上限和间隔我一般设 3 次、间隔 30 秒重试仍失败就写失败表并支持人工触发。日志要带任务名、参数、租户 ID 三个维度排查定时任务只靠业务日志根本不够用定位一个问题要翻好几个文件。4.3 多表关联与跨服务多表关联单库 JOIN 和微服务下的聚合单库多表关联生成器会在 mapper XML 里按外键关系生成 joinselect idselectOrderWithUser resultTypeorderVo SELECT o.id, o.order_no, u.name AS userName FROM biz_order o LEFT JOIN sys_user u ON o.user_id u.id WHERE o.tenant_id #{tenantId} /select生成逻辑依赖表注释里的外键说明生成器会读设计文档或数据库注释来推断关联字段。所以建表时外键注释必须写规范写得不明确生成器就只能生成单表查询后续的关联逻辑全要手补。跨服务多表关联不能直接 join常见做法是分两步先按主表条件分页查出一页主键再调用关联服务的批量查询接口补字段最后在内存里组装。// 跨服务先分页再批量查关联数据内存组装 PageOrder orders orderService.page(query); ListLong userIds orders.stream() .map(Order::getUserId).distinct().toList(); MapLong, User userMap userFeignClient.batchGet(userIds); orders.forEach(o - o.setUserName( userMap.getOrDefault(o.getUserId(), EMPTY_USER).getName()));关键点是批量接口一次传一批 ID 配合 IN 查询而不是 for 循环单条调用——循环调用会被网关限流也容易超时。分页必须先下推到数据库等内存组装时再做过滤数据量一大性能问题会非常明显。如果业务必须全量统计就不应该走实时接口改成定时任务预计算汇总表更稳。5. 避坑与常见问题环境手册没写明白的五个翻车点环境手册覆盖了常规部署流程但生成器最容易出问题的几个场景手册没有细讲。这些坑都是实际跑过之后才会暴露的我按现象、原因、解决的顺序写清楚。5.1 定时任务里查不到数据租户上下文丢在 Job 线程现象页面列表数据正常定时统计 Job 跑出来只有一半数据甚至 0 条。原因Job 线程没有经过登录过滤器TenantContext 为空。租户拦截器拿不到租户 ID 时的默认策略是返回空集或默认租户统计表自然缺数据。解决在 Job 执行器入口显式设置租户上下文或在任务配置里指定 tenantId 参数任务结束 finally 里 clear。我一般会在 Job 日志里打印本次运行用的租户 ID排查时一眼就能确认是不是上下文丢失。5.2 切换工作流引擎后起不来两套引擎的表不通用现象把 engine 从 activiti 改成 flowable启动直接报表不存在或列不存在。原因两套引擎虽然都叫 ACT_ 前缀但版本表、流程定义数据的存储结构有差异库里的旧表不会自动兼容新引擎。解决切换前导出原引擎的流程定义和待办数据清空引擎相关表让新引擎按建表脚本重建再重新部署 BPMN。线上环境不要直接改引擎先拿一个新的空库验证一遍再动线上。5.3 在线表单提交后流程变量丢字段现象用户填了五个字段下一节点只看到三个。原因表单 JSON 里部分字段没写进 variables常见于嵌套对象被当成整体存入或字段名与流程变量名不一致导致取值落空。解决提交时把表单 JSON 展平写入 variables字段名保持唯一。我在表单设计器里习惯加一个“变量映射预览”提交前确认每个字段都会落到流程变量里再放量使用。5.4 跨服务关联把全表数据拉进内存现象列表接口越来越慢数据量上去之后直接超时。原因跨服务场景下没下推分页把主表全量查出来再在内存做关联几千条数据就开始扛不住。解决先分页查出当前页主键再批量查关联字段最后内存组装。必须全量统计的业务改为走汇总表或定时任务预计算不走实时接口。5.5 预览页图标全是方块iconfont 路径问题现象viewer.html 打开后文字正常图标全部显示成空心方块。原因iconfont.css 里的 font-face 声明的字体文件路径是绝对路径浏览器按相对目录找不到字体文件。解决检查 font-face 的 src 是否指向包内相对路径.woff、.ttf 文件有没有随包一起拷贝。另外 .DS_Store 这类 macOS 残留文件不影响运行但建议打包前清掉避免污染版本仓库和交付物。6. 技术栈自由组合的验证技巧换模板、改配置、五分钟跑通6.1 换前端框架模板的三个位置技术栈自由组合是橙单的卖点但换前端框架不是改一个配置项就完事。前端模板一般落在独立目录切换时至少改三个位置页面模板管列表、表单、详情的结构路由模板管菜单到路由的映射API 请求模板管请求封装和拦截器。改了页面模板还要同步改 API 模板的请求头封装因为 appCode、tenantId、channel 三个上下文参数要从这里透传出去。只换页面模板不换请求封装接口路径对不上联调阶段才会发现全部请求都是 401 或 400。6.2 生成后的五分钟验证清单# 1) 后端编译确认生成代码无语法错误、依赖不冲突 mvn clean compile -DskipTests # 2) 初始化数据库和租户数据启动服务 mvn spring-boot:run # 3) 走通一条流程发起请假 - 审批 - 查看历史 curl -X POST /process/leave/start -d {days:2,reason:test} # 4) 手动触发一次同步 Job确认增量游标推进 curl -X POST /job/trigger -d {jobName:orderSync} # 5) 打开 viewer.html核对生成的页面和字段布局 open viewer.html这五步分别覆盖编译、环境、流程、定时任务、前端预览五条线。流程验证要从发起、审批到历史查询全链路走一遍只验证发起不验证审批流程引擎的变量回写问题就发现不了。同步 Job 手动触发一次确认增量游标确实推进了而不是报错后假装成功。最后打开 viewer.html 核对页面字段和数据库表结构比一遍字段漏生成在这个环节最容易暴露。我见过太多人换完模板只看页面好不好看结果接口路径没对上一直拖到联调才翻车。从那以后我每次换模板或改引擎配置都强制走一遍这个五分钟清单确认全链路通了再提交代码。真拿到这套生成器别急着生成第一个项目先把环境手册 docx 过一遍再打开 viewer.html 确认预览最后跑通这条验证链能省下后面大量的返工时间。希望帮到你。本文还有配套的精品资源点击获取