JECloud AI 灵象 · 操作说明书 ​

灵象是什么 ​

JECloud AI 灵象是一套 AI 加持的低代码平台——基于元数据模型构建，可视化搭建 + AI 生成。让你不用从零写代码、不用扩编开发团队，就能把进销存、客户管理、生产报工这类业务系统搭出来：需求不再排进漫长的开发队列，系统按周上线、按天调整，业务怎么变，系统跟着变。

它的底层是深耕低代码十余年的原厂引擎——流程、表单、权限、报表都被打磨了十年，撑得起 ERP / CRM / MES 级别的复杂系统，不是只能做问卷的玩具。

灵象同时是 JECloud 数字员工生态的技术底座：智能体「烟花」在它之上搭系统，数字员工「小匠」在它产出的业务模块上跑业务。一句话——灵象建平台、烟花搭系统、小匠跑业务。

人提需求 → 智能体「烟花」在灵象上搭系统 → 系统长出来 → 数字员工「小匠」上岗跑业务：灵象建平台、烟花搭系统、小匠跑业务。

本手册讲的是灵象的「单机部署版」（standalone）。 它把平台原本的多个微服务合并成一个 Spring Boot 进程，内嵌 MariaDB 与 Redis，无需任何外部中间件；支持私有化部署、数据不出内网，解压后双击 start.bat（Windows）或执行 start.sh（Linux / macOS）即可运行——真正开箱即用。

适用场景——企业与个人信息化建设的技术中台 / 软件工具：

灵象把"建系统"的能力装进一个可本地运行的发行包，作为自有的低代码技术中台，沉淀业务、数据与流程：

• 企业信息化：中小企业或部门级团队，无需服务器集群，在一台机器上搭起进销存、CRM、OA、项目管理、MES 等业务系统，作为企业自有的技术中台持续沉淀与迭代。
• 个人 / 小团队：把它当作随身的低代码软件工具，在本机快速搭建、验证、交付业务应用——开箱即用、数据全在本机。
• 集成与二次开发：作为技术底座嵌入现有信息化环境，二次开发自定义模块，与已有 ERP / OA / 第三方系统打通。

单机版不替代微服务版——当并发或数据量超出单机承载能力时，可迁移至微服务版（数据 mysqldump 后导入）；也可就地横向扩展为多节点轮询集群（主节点 + 若干从节点 + nginx）应对更高并发。

作为低代码技术中台：新系统在其上快速搭建，老旧系统通过它打通数据孤岛、重新赋能。

平台能力引擎 ​

灵象用一组开箱即用的配置引擎驱动业务搭建——这些是你做低代码开发时真正用到的能力：

国产化适配：平台体系支持麒麟 / 普华操作系统、达梦 / 神通 / 人大金仓数据库、OpenJDK 1.8、龙芯 / 鲲鹏处理器、WPS 等国产软硬件环境（单机版以本手册 系统要求 为准）。

安全与性能：传输参数加密、统一 SQL 解析防注入、严格的数据访问授权、三级密码校验。

平台内置完整的组织 / 账号 / 角色 / 权限体系，支持单点登录与功能权限、数据权限的精细授权：

内外部组织机构、账号管理、角色授权与数据授权一体化（授权配置见 菜单配置）。

能做什么 ​

① 浏览器里低代码搭应用

在浏览器里按「资源表 → 数据字典 → 功能 → 功能列表 → 表单 → 子功能 → 菜单 → 授权」八步搭出业务模块，再叠加工作流与报表，AI 辅助生成页面与逻辑，全程无需编写后端代码。

② IDEA 里进行代码开发

在 IntelliJ IDEA 中开发自定义业务插件、功能事件与自定义服务，利用 dev-forward 断点调试功能在本机单步调试平台代码。

③ 单机或集群部署运维

配置证书、管理定时任务（XXL-Job 调度中心）、执行版本升级、备份与恢复数据，以及横向扩展为多节点集群。

这本手册怎么读 ​

手册按板块组织，按需选读：

默认端口与账号 ​

快速安装体验 ​

最快路径：解压 → 启动 → 申请证书 → 登录，几分钟跑起来。环境要求、端口、配置参数等放在本页末尾的 补充：环境与参数，正式部署再看。

第一步：解压发行包 ​

把你系统对应的发行包解压到一个目录即可（不需要安装程序）。各系统发行包：

第二步：启动 ​

Windows ​

进入解压后的根目录，双击 start.bat（或在命令行运行 start.bat）。首次启动约需 60–90 秒。

Linux ​

在根目录执行：

bash start.sh

macOS ​

macOS 会给从网络下载的文件加"隔离"标记，首次启动需先解除，再启动。在根目录执行：

sudo xattr -cr .
bash ./start.command

各系统更细的启动差异（后台运行、开机自启、macOS 签名修复等）见 部署集成 › 单机部署：Windows 部署 / Linux 部署 / macOS 部署。

第三步：申请并放入证书 ​

首次启动若 license/jecloud.license 不存在，平台会打印引导面板并退出（exit code 2）：

╔════════════════════════════════════════════════════════════════════╗
║ [!] 未检测到授权证书，系统无法启动                              ║
║ license\jecloud.license 不存在。                                   ║
║ 首次使用请到官网在线申请授权证书：                              ║
║     https://jecloud.net/download                                   ║
║ 申请后将 jecloud.license 放入 license\ 目录，重新运行 start.bat 即可。
╚════════════════════════════════════════════════════════════════════╝

申请并安装：

1. 访问 https://jecloud.net/download 在线申请授权证书，拿到官方签发的 jecloud.license（通常在一个 zip 包里）
2. 将 jecloud.license（及随附的插件 key）放入发行包根目录下的 license/ 文件夹（该目录始终存在，含 LICENSE-README.txt 说明）
3. 重新运行启动脚本

完整的申请与安装、续期、排错见 授权证书。

第四步：登录体验 ​

启动成功时，控制台会打印信息面板（StartupBanner）：

╔════════════════════════════════════════════════════════════════════╗
║ JECloud AI 灵象   启动完成 (耗时 XX 秒)                           ║
║ 访问地址    http://localhost:8080                                  ║
║ 登录账号    admin                                                  ║
║ 登录密码    123456                                                 ║
║ 数据库密码  root / bt5   (127.0.0.1:33306)                        ║
║ 关闭服务请运行 stop.bat（Linux/macOS：bash stop.sh）               ║
╚════════════════════════════════════════════════════════════════════╝

打开浏览器访问 http://localhost:8080，使用账号 admin / 123456 登录即可。

可通过以下接口验证服务就绪：

停止 ​

:: Windows
scripts\stop.bat

# Linux / macOS
bash scripts/stop.sh

停止脚本会依次关闭应用进程（8080）、WebSocket（7010）、内嵌 MariaDB（33306）、内嵌 Redis（61379）与调度中心（3060），并验证端口已释放。

补充：环境与参数（按需查阅） ​

快速跑通后，正式部署前可参考以下内容。

支持的操作系统 ​

硬件要求 ​

运行环境（Java 8） ​

灵象基于 Java 8（JDK/JRE 8） 构建，不兼容 JDK 17+。slim 包需目标机预装 JDK/JRE 8；full 包自带 OpenJDK 8 JRE，无需预装。命令行执行 java -version，确认包含 version "1.8.*"。

端口、目录与配置参数 ​

• 端口占用与目录结构完整清单见 附录。
• 配置参数（端口、数据库 / Redis 密码、XXL-Job 等）见 配置说明。

首次启动会发生什么 ​

首次启动会按顺序自动完成（约 60–90 秒，控制台打印 [1/8]…[8/8] 进度）：

1. 端口预检 — 检查 8080 / 7010 / 33306 / 61379 是否空闲，任一被占用则报错退出
2. 启动内嵌 MariaDB（33306）— 初始化数据目录 data/mysql/
3. 执行数据库初始化脚本 — 按文件名顺序运行 sql/schema、sql/data、sql/upgrade（幂等）
4. 启动内嵌 Redis（61379）
5. 启动应用服务（Tomcat 8080）— 加载平台服务插件、启动 Netty WebSocket（7010）
6. 启动调度中心（jecloud-job-admin，3060）— 主程序健康检查通过后自动拉起

遇到启动失败、端口冲突等问题，见 常见问题与排错。

快速上手应用 ​

目标 ​

跟着一条完整的「开发流转路线」走一遍，理解灵象低代码"不写后端代码就能搭出业务系统"的全过程。下文以平台内置的客户管理为例，每一步都配上系统真实界面。

开发流转路线 ​

一个业务模块从无到有，标准顺序如下——数据底座（①②）→ 业务功能（③）→ 交付（④⑤）→ 运行（⑥）：

下面每一步都遵循「先创建、再配置」两个动作：创建会弹窗输入基本信息，确定后进入配置 / 编辑区——对照两张截图即可看出"创建"与"配置"的区别。

① 资源表：定义业务数据 ​

创建——选中模块，点工具栏「新建表」，在弹出的对话框里选类型、填表名称与表编码，点「确定」：

配置——确定后（或在左侧资源树选中一张已有表），右侧进入字段设计区，逐字段定义字段名称、编码、类型、是否必填、排序等，保存同步后映射为业务库的物理表：

详见 资源表。

② 数据字典：维护可复用枚举 ​

创建——点「新建列表字典」，在弹出的空白表单里填字典名称 / 编码 / 类型 / 所属模块：

配置——切到「数据字典项」标签页，逐项维护项名称、值、排序、颜色、图标，把状态/类型/分类等下拉选项沉淀为可复用字典，改一处全局生效：

详见 数据字典。

③ 功能配置：列表 + 表单 + 子功能 ​

入口——从「开发 › 应用中心」进入，左上切到「业务服务」，逐级展开「子系统 › 模块 › 功能」：

创建——选中目标模块，点「+ 添加 › 功能」，在弹出的对话框里填名称、编码、功能类型、表名、主键：

配置——确定后双击该功能打开「功能配置」设计器，分页签配置列表（显示哪些列）、表单（录入哪些字段、必填/只读）、按钮与子功能：

详见 功能配置。

④ 菜单配置：挂入导航 ​

在「菜单管理」展开菜单树、选中一个节点，右侧即出现该菜单的配置信息（名称、图标、类型、所属服务、绑定的功能等）——新建菜单节点并绑定刚配好的功能，它就出现在导航树中：

详见 菜单配置。

⑤ 授权：授予角色 ​

没有授权的用户看不到入口。两种授权方式：开发期可在「菜单管理」工具栏点「授权给开发人员」一键授权；正式交付则用角色授权精细控制——顶部 管理 › 角色授权，选中角色后右侧管理该角色的账户：

关键一步——切到右侧「权限配置」页签，展开「菜单授权 / 功能授权」，勾选要开放给该角色的菜单与功能：

详见 菜单配置。

⑥ 运行验证：最终用户使用 ​

切换到运行态（工作 菜单），在导航中找到功能，录入数据验证新增、编辑、删除、查询：

至此，一个完整的低代码应用就搭建并交付完成了。

附录 ​

端口清单 ​

注意：MariaDB 默认使用 33306 而非标准的 3306，目的是避免与宿主机已安装的 MySQL 冲突。修改任何端口后须同时更新上表所列的所有联动点，否则会出现连接失败或端口预检 fail-fast 报错。

默认账号 ​

内置数据库 ​

三个数据库均运行在同一内嵌 MariaDB 进程（端口 33306）上，账号统一为 root/bt5：

详细说明见 配置说明 › 内置的三个数据库。

目录结构 ​

发行包解压后的完整目录树及各目录用途如下：

<发行包根>/
├── jeapp-standalone.jar        主程序 jar（薄壳 + 适配层 + FQN 复写 + PluginLoader）
├── plugins/
│   ├── system/                 平台内置 8 个微服务 jar（出厂自带，勿手动修改）
│   └── business/               业务插件放置目录（出厂为空，二次开发成果放此处）
├── lib/                        三方依赖 jar（由主程序自动加载，勿手动修改）
├── license/                    证书文件目录（jecloud.license + 各服务 plugin key）
├── data/
│   └── mysql/                  内嵌 MariaDB 数据目录（删此目录等于重置数据库）
├── files/                      用户上传 / 下载文件及临时文件（workflow / preview / local）
├── sql/
│   ├── schema/                 初始建表 SQL，按文件名顺序执行，幂等（_jecloud_schema_version 追踪）
│   ├── data/                   初始种子数据 SQL
│   └── upgrade/                增量升级 SQL，每次版本升级追加于此
├── config/
│   ├── application.yml         主配置文件（端口 / 数据库 / Redis / XXL-Job 等所有运行时参数）
│   └── jecloud-job.properties  XXL-Job 调度中心独立配置（datasource / 端口 / access token）
├── apollo-cache/               本地 Apollo 配置缓存（程序启动时自动生成，勿手动编辑）
├── logs/                       运行日志（spring.log，按日期滚动）
├── web/                        前端静态资源（Vue dist + ExtJS build，由 Tomcat 直接 serve）
├── job/
│   └── jecloud-job-admin.jar   XXL-Job 调度中心独立进程 jar
├── upgrade/                    版本升级包存放目录（upgrade.bat 读取此处的升级 zip）
├── nginx/                      集群模式专用：nginx 可执行文件 + nginx.conf（单机模式不启用）
└── scripts/                    辅助脚本（start-job-admin.bat/.sh、start-node.bat 等）

Windows 路径注意事项：发行包所在路径须为纯 ASCII 字符、不含空格、不含符号链接，否则内嵌 MariaDB 初始化（ibdata1）可能失败。

命令速查 ​

启停 ​

:: Windows 启动（主节点，all 模式：DB + Redis + 应用 + 定时任务）
start.bat

:: Windows 停止（同时终止应用进程、mysqld、redis-server、nginx）
stop.bat

# Linux / macOS 启动
./scripts/start.sh

# Linux / macOS 停止
./scripts/stop.sh

健康检查 ​

# 返回 {"status":"UP"} 表示服务就绪（可用于脚本轮询等待启动完成）
curl http://localhost:8080/actuator/health

端口排查 ​

:: Windows：查看指定端口占用情况（以 8080 为例）
netstat -ano | findstr :8080

# Linux / macOS：查看端口占用（以 8080 为例）
lsof -i :8080

备份 ​

:: Windows：备份数据目录与文件（停服后执行）
xcopy /E /I /H data\ backup\data\
xcopy /E /I /H files\ backup\files\

# Linux / macOS：打包备份（停服后执行）
tar -czf backup-$(date +%Y%m%d).tar.gz data/ files/

版本升级 ​

:: Windows：执行交互式升级向导（离线 / 在线 → 目标版本 → 自动 / 手动）
upgrade.bat

数据清理 ​

# 仅预览（confirm=true，只统计不动数据）
curl -X POST "http://127.0.0.1:8080/je/standalone/cleanup/data?productCode=<方案编码>&confirm=true"

# 真执行（缺省即真删，不带 confirm）
curl -X POST "http://127.0.0.1:8080/je/standalone/cleanup/data?productCode=<方案编码>"

源码构建 ​

# slim 构建（不含 JRE，依赖宿主机已安装 Java 8）
mvn clean package -P slim

# full 构建（含 JRE，需先将 OpenJDK 8 x64 放入 src/main/jre/）
mvn clean package -P full

术语表 ​

低代码总览 ​

本章目标 ​

理解灵象低代码的配置开发模型，掌握不写代码、只在浏览器里配置即可搭出一个完整业务应用的标准路径。

灵象平台引擎靠配置驱动：先建好数据底座（资源表 + 数据字典），再围绕资源表搭出业务功能（功能 + 功能列表 + 表单 + 子功能），最后通过菜单与授权把功能交付给指定角色使用。这是区别于「代码开发」（在 IDEA 里写 Java）的纯配置侧路径。

标准开发主线（八步） ​

一个业务模块从无到有，标准顺序如下：

①创建资源表 → ②创建数据字典 → ③创建功能 → ④配置功能列表
   → ⑤配置表单 → ⑥配置子功能 → ⑦创建菜单 → ⑧授权

前两步搭数据底座，③～⑥围绕资源表搭业务功能，⑦⑧通过菜单与授权完成交付——这条主线适用于绝大多数业务模块。

在主线之上叠加 ​

主线跑通后，按需叠加以下能力：

• 流程引擎：为功能绑定审批流程，驱动业务状态流转。见 流程引擎。

要点提纲 ​

• 产品与方案：产品是应用的顶层容器，方案是产品下的子模块；理解两者的层次关系
• 运行态 vs 设计态：设计态在管理界面编辑配置，运行态是最终用户看到的应用界面；两者可独立刷新
• 元数据与 loadFunc 链路：平台在运行时通过元数据驱动页面渲染，了解 loadFunc 的调用链路有助于排查问题
• 角色 / 权限模型：账号 → 角色 → 功能权限 / 数据权限，授权链路贯穿第⑧步
• 与代码开发的关系：低代码满足不了的场景可通过业务插件扩展，详见 代码开发

待补 ​

• [ ] 各步骤操作截图
• [ ] 端到端建一个完整业务模块的分步详解

资源表 ​

低代码开发主线第 ① 步：创建资源表——先把业务数据结构定下来，这是整个应用的数据底座。

本章目标 ​

用建模工具创建业务资源表与字段，保存同步后映射为业务库的物理表。

创建资源表 ​

打开「资源表」后，首页会给出资源总数、类型分布与名词解释（普通表 / 单根树形表 / 多根树形表 / 视图 / 导入表 / 关系视图）：

左侧「核心元数据」树按引擎分类组织全部资源表（资源表引擎 / 功能引擎 / 字典引擎 / 数据源引擎 …）：

新建一张业务表 ​

1. 切换到业务服务：左下角的服务下拉（默认「元数据服务」）切换到 业务服务——业务资源表都建在这里。
2. 选中模块：在左侧资源树展开目标子系统（如「客户关系管理（CRM）」），选中要建表的模块（如「销售管理」）。
3. 点击「新建表」：点击树上方工具栏的「新建表」图标，弹出新建表对话框——先选类型（普通表 / 单根树表 / 多根树表），再填 表名称 与 表编码（推荐命名规范 系统名_模块名_实体名，如 JE_RBAC_ENDUSER），点「确定」即创建：

4. 编辑字段：确定后进入字段设计，逐字段维护字段名称、字段编码、字段类型、是否为空、唯一/索引、排序等：

查看 / 编辑已有表（配置区） ​

在左侧资源树展开到具体表（如 客户关系管理 › 销售管理 › 客户相关 › 客户管理），选中即在右侧打开该表的设计视图，可继续维护列、键、索引，并通过顶部「设计视图 / 关系视图 / DDL 视图 / SQL 视图」切换查看：

设计视图内还有 表格列 / 表格键 / 表索引 / 历史留痕 四个子页签：

切到「表格键」页签，维护主键与外键关联（键编码、字段编码、类型、关联表 / 关联字段 / 关联类型）：

切到「表索引」页签，维护索引（索引编码、字段名称、是否唯一、分类、排序）：

操作要点 ​

1. 建模型 / 建表：在模型设计器中新建数据模型，映射为数据库物理表
2. 字段类型：文本、数字、日期、布尔、枚举等常用类型及其配置项
3. 主子表与关联关系：一对多主子表配置、外键关联关系的定义方式
4. 系统字段自动生成：平台默认为每张表追加 SY_ 开头的系统字段（主键、数据状态、登记人/时间、所属公司/机构、工作流字段等），无需手工维护
5. 生成数据库表：在设计态保存并同步后，平台自动在业务库执行 DDL
6. 与双库路由的关系：灵象在独立业务库与平台库之间路由查询，了解业务数据落在哪个库；详见 数据库使用规则

下一步 ​

数据底座建好后，继续 数据字典（第 ② 步），再到 功能配置。

待补 ​

• [ ] 主子表 / 关系视图建模的分步截图

数据字典 ​

低代码开发主线第 ② 步：创建数据字典——集中维护可复用的枚举 / 编码，供多个资源表字段引用。

本章目标 ​

维护可复用的数据字典（如状态、类型、分类），改一处全局生效，为表单下拉、列表展示提供统一取值。

创建数据字典 ​

左侧按业务套件分类组织字典，右侧是字典列表（字典名称 / 编码 / 类型 / 所属模块）：

新建字典：在字典列表上方点击「新建列表字典」，即弹出空白的字典编辑表单（也可双击已有字典进入编辑）。「基础信息」填写 字典名称 / 字典编码（如 CRM_SALES_SSHY）、字典类型（列表 / 树形 …）、所属模块：

基础信息填好后，切到下方「数据字典项」标签页，点「添加项」逐项维护 项名称、值（编码，全大写英文如 ISV/HLW）、排序、是否启用、背景/字体颜色、图标，最后「保存」：

操作要点 ​

1. 建字典：定义字典分类与字典项（编码 + 显示文本）
2. 字段引用字典：资源表字段绑定字典后，表单下拉、列表展示自动取字典文本
3. 维护与扩展：字典项可随业务增长持续追加，无需改表结构

下一步 ​

字典就绪后，进入 功能配置（第 ③～⑥ 步）。

待补 ​

• [ ] 字典类型选型与维护分步详解

功能配置 ​

低代码开发主线第 ③～⑥ 步：创建功能 → 配置功能列表 → 配置表单 → 配置子功能——围绕资源表搭出可操作的业务模块。

入口：应用中心 → 双击功能 ​

功能配置在「应用中心」里完成。从顶部 开发 › 应用中心 进入，左上角切换到对应服务 / 产品（业务功能在「业务服务」下），逐级展开「子系统 → 模块 → 功能」：

新建功能（创建） ​

要新建功能：在左侧选中目标模块，点工具栏「+ 添加 › 功能」，在弹出的「功能添加」对话框里填写 名称、编码、功能类型、表名、主键名，点「确定」即创建一个空功能：

打开功能配置（配置） ​

找到目标功能（如 客户关系管理 › 销售管理 › 客户管理），双击该功能，即弹出「功能配置」设计器。设计器顶部分为 功能 / 列表 / 表单 / 按钮 / 子功能 五个页签——列表归列表、表单归表单，各管各的配置。

③ 创建功能（功能页签） ​

「功能」页签是核心配置：功能编码、功能名称、绑定的表名、主键、功能类型、数据录入方式，以及视图操作表、主从展示、流程绑定等：

• 功能编码 = 资源表编码（如 CRM_SALES_CUSTOMER），表名指向资源表或其视图（如 V_CRM_SALES_CUSTOMER）
• 功能类型：操作视图 / 普通功能等
• 流程绑定：可为功能绑定工作流（如"客户报备审批"），录入数据即进入审批

④ 配置功能列表（列表页签） ​

「列表」页签配置列表视图：选哪些字段作为列、列宽、对齐、是否隐藏、排序、列锁定、是否可编辑等，逐列配置：

⑤ 配置表单（表单页签） ​

「表单」页签配置新增/编辑表单：设置表单宽度与列数，逐字段配置必填 / 只读 / 隐藏、列宽、控件类型，右侧"字段库"可把资源表字段拖入表单：

配置按钮（按钮页签） ​

「按钮」页签配置工具栏 / 表单 / 行菜单上的按钮：每个按钮设置编码、名称、类型（列表 TABLE / 表单 FORM）、绑定事件、隐藏 / 禁用 / 授权、图标与样式。除内置的新增 / 编辑 / 删除 / 导出外，可添加自定义按钮（如下图"转移负责人"）：

按钮的「事件」即在 平台功能事件 里为按钮（click / before-click / after-click）挂脚本。

⑥ 配置子功能（子功能页签） ​

「子功能」页签挂主子表 / 关联功能：每个子功能绑定一张表（或视图）、设置展示方式与父子关联字段。下图客户管理挂了 客户联系人、客户情报 两个子功能，运行时即表单顶部的页签：

运行效果 ​

配置完成后，运行态即得到一个可用的业务功能——列表、表单、子功能页签一应俱全，参见 场景案例 › 销售模块。

下一步 ​

功能搭好后，进入 菜单配置（第 ⑦⑧ 步）把它交付给用户。

待补 ​

• [ ] 字段控件类型（XTYPE）逐项说明与截图
• [ ] 按钮事件与权限配置分步详解

菜单配置 ​

低代码开发主线第 ⑦⑧ 步：创建菜单 → 授权——把搭好的功能挂到菜单树，并授权给角色，完成"从配置到用户可用"的交付闭环。

本章目标 ​

把配置好的功能挂到菜单树，并授权给角色，让最终用户能在导航中看到并使用。

⑦ 创建菜单 ​

菜单是功能暴露给最终用户的导航入口。在「菜单管理」中，左侧「菜单地图」按方案组织菜单树（开发平台 / 系统管理 / 工作），通过 添加 新建菜单节点并绑定功能：

操作步骤：

1. 在「菜单地图」中展开并选中要挂载的父节点，点击右侧上方的「添加」新建菜单节点。
2. 展开菜单树、选中某个菜单节点，右侧即出现该菜单的配置信息——名称、图标、类型、所属服务、绑定的功能、是否显示、排序等，逐项修改即可：

要点：菜单分一级 / 二级层级；叶子菜单绑定已配置好的功能；图标请用平台内置图标（见 菜单设计规范）。

⑧ 授权 ​

没有授权的用户看不到对应入口。授权有两种方式：

方式一：菜单一键授权给开发人员 —— 「菜单管理」工具栏上有「授权给开发人员」按钮，开发期可一键把菜单授权给开发角色，快速可见。

方式二：角色授权（精细控制） —— 顶部 管理 › 角色授权：左侧是角色列表（公司领导 / 销售总监 / 财务人员 …），选中角色后，右侧「账户配置」管理该角色下的账号：

切到右侧「权限配置」页签，展开「菜单授权 / 功能授权」，勾选要开放给该角色的菜单与功能（可「全部展开」逐项勾选）：

• 功能权限 vs 数据权限：功能权限控制菜单 / 按钮的可见性；数据权限（顶部 管理 › 数据授权）控制数据行的可读范围
• 账号 → 角色 → 权限：账号关联角色，角色获得勾选的功能与数据权限，完成授权闭环

下一步 ​

主线跑通后，可继续叠加 流程引擎。

待补 ​

• [ ] 菜单「添加」对话框（新建节点时填写的字段）截图

流程引擎 ​

在低代码主线之上叠加：为业务功能绑定审批流程，驱动业务状态流转。平台流程引擎基于 Activiti，支持发起、撤销、退回、转办、加签、会签、传阅等中国特色审批规则。

本章目标 ​

为业务配置审批流程，并把流程绑定到功能，让用户提交数据即进入审批流转。

流程列表 ​

「工作流引擎」左侧按业务分类组织流程，右侧是流程清单（流程名称、编码、分类、版本、是否部署等）：

打开流程设计器 ​

在流程列表中，点击某条流程 「规划」列下的 action 按钮（注意：不是双击行），即弹出流程引擎设计器：

• 左侧：节点组件库——开始 / 结束 / 判断 / 任务 / 分支 / 聚合 / 会签 / 固定人 / 候选 / 多人审批 等，拖到画布即添加节点。
• 中间画布：拖拽连线绘制审批流（如 开始 → 填单人 → 领导审核 → 结束）。
• 右侧：基础配置（流程名称、绑定功能、流程分类、部署环境）、启动配置（任何人启动 / 可启动角色 / 启动表达式 / 定时启动）、扩展配置。

要点提纲 ​

• 流程设计器：可视化绘制审批流程图，添加节点与连线
• 节点与审批人：配置各审批节点的处理人（指定人员、角色或动态表达式）
• 表单绑定：将流程与业务表单关联，控制各节点的字段可见与可编辑范围
• 发起与审批：最终用户如何发起审批申请、审批人如何处理待办任务
• 与 Activiti 引擎的关系：平台流程引擎底层基于 Activiti，ACT_* 表由平台初始化脚本预置，无需手动干预

待补 ​

• [ ] 可视化流程设计器（节点/连线/审批人）操作截图
• [ ] 发起与审批分步详解

代码开发总览 ​

代码开发是什么 ​

代码开发是指在 IDEA 里给灵象底座编写自定义 Java 代码——业务插件、自定义服务接口、数据库扩展——以满足超出浏览器低代码能力范围的定制需求。本板块区别于「平台配置（低代码）」——低代码是在浏览器里配资源表 / 功能 / 菜单，不写代码；代码开发是在 IDEA 里写 Java、构建产物、扩展平台行为。

本板块同时涵盖围绕平台的定时任务（XXL-Job）配置：XXL-Job 调度中心随发行包一同启动，执行器内嵌在主进程中，开发者在这里了解如何配置、注册和管理定时任务。

如果你的需求可以通过数据建模、表单设计、菜单配置、工作流来完成，那更推荐先走 低代码开发，无需编写 Java 代码。代码开发适合那些需要自定义接口逻辑、复杂数据计算、或深度集成外部系统的场景。

两仓协作 ​

灵象代码开发涉及两个 Git 仓库，职责严格分离：

同步微服务版更新的标准三连：

# 1. 进入微服务仓，拉最新
cd <微服务仓目录>
git pull

# 2. 安装到本地 Maven 仓库
mvn install -DskipTests

# 3. 回到 standalone 仓，重新打包适配层
cd jecloud-standalone
mvn -pl standalone-boot package -DskipTests

模块结构 ​

jecloud-standalone 仓包含以下模块：

三条红线 ​

代码开发（二次开发）时务必遵守以下约束，违反任一条都可能导致后续升级困难或功能失效：

后续章节导引 ​

本板块分为四组——项目代码开发（搭建工程、调试、构建的全流程）、微应用开发、平台功能事件、前端组件与工具。

项目代码开发 ​

围绕 jecloud-standalone 工程的搭建、调试、扩展与构建：

微应用开发 ​

平台功能事件 ​

前端组件与工具 ​

获取源码与产物 ​

① 业务 service 工程骨架 ​

业务后端逻辑（自定义 Controller / Service / DAO）在一个独立的 Maven 工程中开发，构建产出 business 插件 jar。这个工程从官方提供的 archetype 模板一键生成。

它是什么 ​

• 仓库：https://gitee.com/ketr/jecloud-service-archetype
• 定位：JECloud 微服务项目骨架（Maven archetype 模板），用来快速生成符合平台规范的业务 service 工程——预置好包结构、pom.xml 依赖、manifest 等，避免从零搭建。

前置环境 ​

安装与创建工程 ​

本地方式——先克隆 archetype 仓库并安装到本地 .m2：

git clone https://gitee.com/ketr/jecloud-service-archetype
cd jecloud-service-archetype
mvn clean install

安装完成后，在 IDEA 的 New Project → Maven → Create from archetype 中点击 Add Archetype，选用刚安装的 jecloud:jecloud-service-archetype，填写你自己的 GroupId / ArtifactId 创建工程。

远程方式——不在本地预装，直接在 IDEA 的 archetype 配置中添加私服 http://maven.jepaas.com，然后选用同一个 jecloud-service-archetype 创建工程即可。

产出与挂载 ​

构建生成的就是 business 业务插件 jar。在单机 SKU 下，把它放入发行包的 plugins/business/ 目录，由平台在启动期加载——挂载流程、manifest 规范与类加载顺序详见 业务插件开发与打包。

② 平台内置服务源码（开源） ​

平台自身的 8 个微服务及配套基础库均开源，托管在 Gitee 组织 https://gitee.com/ketr 下。阅读这些源码是定位平台行为、在 IDEA 中做断点调试（见 IDEA 配置与运行）的基础。

后端服务与基础库：

• jecloud — 低代码平台旗舰仓库（聚合入口）
• jecloud-common — 基础模块（公共工具、基类）
• jecloud-gateway — 动态网关
• jecloud-meta — 元数据服务
• jecloud-rbac — 权限服务
• jecloud-bpm — 工作流中间件
• jecloud-connector — 推送连接器
• jecloud-job — 改造版 XXL-Job 调度
• jecloud-auth — 认证服务
• je-ibatis — 定制版 MyBatis

前端：

• jecloud-pc-archetype — 微应用骨架
• jecloud-pc-libs — 前端基础库

待补 ​

• jecloud-service-archetype 生成工程的目录树，以及打包 / 插件挂载的精确命令：archetype 仓库 README 外链至 doc.jepaas.com，此处尚未文档化，待补齐后补充示例工程结构与逐步命令。

IDEA 配置与运行 ​

本页讲如何在 IntelliJ IDEA 中跑一个平台服务（以 jecloud-meta 元数据服务为例）、命中源码断点调试。聚焦四个关键点，最后给出"调试配置中心"截图。

要点一：引入单体调试桥接 starter ​

在服务工程的 aggregate-tomcat/pom.xml 中增加依赖：

<dependency>
  <groupId>com.je.standalone</groupId>
  <artifactId>jecloud-standalone-bridge-debug</artifactId>
  <version>3.1.1</version>
</dependency>

作用（pom 注释要点）：当开关 jecloud.standalone-debug.enabled=true 打开后——

• 本服务在无注册中心的环境下也能对外提供 controller / RPC（ServiceComb 的 SCBEngine 直接进入 READY 状态）；
• @RpcReference 远程引用被短路成本进程内本地 bean，不再发起远程调用；
• 于是本服务可被单机的 dev-forward 把流量转发过来，落到源码做断点调试。

要点二：修改 dev 环境配置 ​

在服务工程的 aggregate-tomcat/src/main/resources/dev/ 目录下，改三个配置文件。

application.yml ​

端口设为 8085，且 ServiceComb 的 REST 监听地址与之保持一致；打开桥接开关；关闭配置中心与 Apollo（避免去连远程拉旧配置）；允许 bean 覆盖：

server:
  port: 8085

servicecomb:
  rest:
    address: 0.0.0.0:8085          # 必须与 server.port 一致

jecloud:
  standalone-debug:
    enabled: true                  # 要点一的桥接开关

enableConfigCenter: 0              # 关闭配置中心

apollo:
  bootstrap:
    enabled: false                 # 关闭 Apollo
  meta: http://127.0.0.1:1         # 指向不可达地址，确保不去连远程

spring:
  main:
    allow-bean-definition-overriding: true

jdbc.properties（指向单机内嵌库） ​

让本地服务实例连单机主进程的内嵌 MariaDB（33306）：

jdbc.url=jdbc:mysql://localhost:33306/jecloud_platform?useOldAliasMetadataBehavior=true&characterEncoding=UTF-8
jdbc.username=root
jdbc.password=bt5

redis.properties（指向单机内嵌 Redis） ​

让本地服务实例连单机的内嵌 Redis（61379）。必须显式写密码，否则报 NOAUTH：

redis.host=localhost
redis.port=61379
redis.pass=123456
spring.redis.host=localhost
spring.redis.port=61379
spring.redis.password=123456

要点三：找到启动类并运行 ​

服务工程的启动类是 com.je.AppMain，路径 aggregate-tomcat/src/main/java/com/je/AppMain.java。它带有 @SpringBootApplication(scanBasePackages = {"com.je"})、@EnableServiceComb 等注解。

在 IDEA 中把 com.je.AppMain 设为 Run/Debug 主类直接运行——dev profile 默认激活，服务监听 8085。以 Debug 模式启动，即可在源码中打断点。

要点四：在调试配置中心开启转发 ​

进入平台 开发 › 服务管理 › 调试配置中心，为目标服务（如 元数据服务 meta）配置本地转发地址（如 http://localhost:8085）并打开开关。

开启后的完整链路：

前端 → 单机:8080 → 命中该服务路由 → 反代到 http://localhost:8085 → IDEA 命中断点

调试配置中心：逐个服务填写本地转发地址（如 http://localhost:8085）并打开开关；顶部提示需后端开启总开关并重新打包。

更多转发链路细节、配置文件格式与常见问题，见 dev-forward 断点调试。

待补 ​

• 各平台服务的默认端口对照表（meta / gateway / rbac / … 在 dev 下各自建议监听的端口）。
• 卫星实例运行参数的细节（run-mode=app 的完整启动参数与共享数据层注意事项）。

dev-forward 断点调试 ​

dev-forward（开发态服务转发）允许开发者在 IDEA 中以原生断点调试某个平台微服务（如 meta、gateway），同时单体实例继续正常服务其余所有接口，无需重打整包、无需重启主进程。

概念 ​

前端 → 单体主实例 :8080
          ↓ DevForwardFilter（最高优先级）
          ↓ URL 路由匹配（UrlRouterMatcher）
          ↓ 读取转发配置（config/dev-forward.json，启动时加载 / 调保存接口立即热加载）
          ├── 未命中或 debug=false → 主实例进程内 controller 处理
          └── 命中转发配置        → ReverseProxySupport（HTTP 流式反代）
                                       ↓
                                  卫星实例 :8090
                                  （源码断点 + IDEA Debug）

核心机制：单体在请求边缘按 URL 路由检测该 URL 所属微服务，然后查询 config/dev-forward.json 中的转发配置，决定是就地处理还是反代给本机卫星。卫星连接同一个内嵌 MariaDB（33306）和 Redis（61379），以 run-mode=app 运行，源码 Module 覆盖对应 jar 使断点生效。

总开关 ​

dev-forward 功能默认关闭，必须通过 JVM 参数显式启用：

-Djecloud.standalone.dev-forward.enabled=true

在 IDEA 的主实例 Run Configuration 的 VM options 中加入此参数，或在命令行启动时追加即可。不加此参数时 DevForwardFilter 不注册，对生产环境零开销。REST 接口（/je/dev-forward/*）也仅在此开关开启时注册。

5 步调试流程 ​

第 1 步：以转发模式启动主实例 ​

在主实例（StandaloneApplication，端口 8080）的 VM options 中加入：

-Djecloud.standalone.dev-forward.enabled=true

然后以 Debug 或 Run 模式启动主实例，等待控制台输出启动完成标志。

第 2 步：配置转发目标 ​

转发配置存储在发行包根目录下的 config/dev-forward.json 文件（与 application.yml 同级）。

方式 A — 直接编辑配置文件（需重启主实例生效）

在 dist 根目录的 config/dev-forward.json 中，将目标服务的 debug 设为 true、url 填入本机卫星地址。文件不存在时视为空列表（不转发任何请求）。

[
  {
    "pdCode": "meta",
    "pdName": "元数据服务",
    "debug": true,
    "url": "http://localhost:8090"
  }
]

方式 B — 调用 REST 接口（立即热加载，无需重启）

主实例启动后，可通过保存接口对单个服务的配置进行新增或更新，接口自动将变更写入 config/dev-forward.json 并立即重新加载转发缓存，无需重启主实例。

接口需要平台登录态（Bearer token），路径前缀为 /je/**，未登录返回 401。

查看当前配置：

curl -H "Authorization: <token>" http://localhost:8080/je/dev-forward/list

新增或更新某服务的转发配置：

curl -X POST http://localhost:8080/je/dev-forward/save \
  -H "Content-Type: application/json" \
  -H "Authorization: <token>" \
  -d '{"pdCode":"meta","pdName":"元数据服务","debug":true,"url":"http://localhost:8090"}'

• 请求体为单个服务对象，按 pdCode 做 upsert。
• 返回值为保存后的完整配置数组。
• pdCode 为空、或 debug=true 时 url 为空，返回 400。

第 3 步：以 Debug 模式启动卫星实例 ​

在 IDEA 顶部 Run Configuration 下拉中选择 "Satellite (run-mode=app)"（或自建的卫星配置），点击 Debug 按钮。

卫星会：

• 连接主实例已启动的内嵌 MariaDB（33306）和 Redis（61379）
• 以 run-mode=app 跳过内嵌库初始化和 Connector/XXL-Job 启动
• 在端口 8090 上就绪
• IDEA Debug 面板显示 Connected 状态

在待调试服务的源码中（如 meta 模块的某个 ServiceImpl）打上断点。

第 4 步：前端操作，触发断点 ​

用浏览器访问 http://localhost:8080，正常操作涉及目标服务（此处为 meta）的功能。

请求路径为：

前端 → 单体:8080 → 检测到 meta 路由 → 反代到 http://localhost:8090 → 卫星命中断点

IDEA Debug 面板中断点挂起，可正常查看调用栈、变量值、单步执行。

第 5 步：关闭转发 ​

调试完成后，将该服务的 debug 设为 false（记录保留，后续可快速重新开启）：

通过 REST 接口（立即生效，无需重启）：

curl -X POST http://localhost:8080/je/dev-forward/save \
  -H "Content-Type: application/json" \
  -H "Authorization: <token>" \
  -d '{"pdCode":"meta","pdName":"元数据服务","debug":false,"url":"http://localhost:8090"}'

或直接编辑 config/dev-forward.json 将 debug 改为 false，然后重启主实例生效。

配置项参考 ​

在 standalone-boot/src/main/resources/application.yml 中可调整以下参数：

jecloud:
  standalone:
    dev-forward:
      enabled: false                    # 总开关，false = Filter 不注册
      connect-timeout-ms: 5000         # 连接卫星超时（毫秒），默认 5000
      read-timeout-ms: 30000           # 等待卫星响应超时（毫秒），默认 30000
      exclude-paths:                   # 不转发的路径（Ant 通配符）
        - /je/dev-forward/**
        - /actuator/**

enabled 建议通过 JVM 参数覆盖（-Djecloud.standalone.dev-forward.enabled=true），不改 yml 文件，以免误提交到 git。

同时调试多个服务 ​

需要同时调试多个平台服务（如 meta + gateway）时，启动多个卫星实例，分别监听不同端口：

• 卫星 A（调试 meta）：端口 8090
• 卫星 B（调试 gateway）：端口 8091

在 config/dev-forward.json 中为每个服务配置一条记录，各自指向对应端口：

[
  {
    "pdCode": "meta",
    "pdName": "元数据服务",
    "debug": true,
    "url": "http://localhost:8090"
  },
  {
    "pdCode": "gateway",
    "pdName": "网关服务",
    "debug": true,
    "url": "http://localhost:8091"
  }
]

或通过保存接口逐条 upsert，效果相同。两个卫星均以 run-mode=app 运行，共享同一个内嵌数据库，互不干扰。

已知限制 ​

FAQ ​

Q1：卫星启动后连接数据库失败 ​

现象：Can't get a connection, pool error Timeout waiting for idle object

原因：主实例未启动，内嵌 MariaDB（33306）和 Redis（61379）不可用。

排查：

1. 确认主实例已启动且控制台出现启动完成标志。
2. 检查主实例日志是否含 EmbeddedMariaDB started 和 EmbeddedRedis started。
3. 用 MySQL 客户端验证：mysql -h localhost -P 33306 -u root -pbt5。

Q2：配置后请求仍然到主实例，没有转发 ​

排查：

1. 主实例 VM options 是否包含 -Djecloud.standalone.dev-forward.enabled=true。
2. 检查 config/dev-forward.json 是否存在且内容正确：
   • pdCode 是否与 urlRouter.xml 中对应路由的 microServiceName 完全一致（区分大小写）。
   • debug 字段是否为 true（布尔值，非字符串）。
   • url 字段是否填写正确（含协议，如 http://localhost:8090）。
3. 若直接编辑了文件，需重启主实例（或调用一次 POST /je/dev-forward/save 触发热加载）。
4. 在主实例日志中搜索 [dev-forward] 关键字查看转发决策日志。

Q3：卫星启动报错 "port 7010 in use" ​

原因：7010 端口已被主实例 Connector Netty 服务占用。

说明：run-mode=app 下卫星会自动跳过 Connector 初始化，正常情况不会绑定 7010。若仍报错，检查是否有第三方进程占用：

netstat -ano | findstr :7010

找到占用进程 PID 后，在任务管理器中结束该进程，或修改主实例 connector 端口。

Q4：收到 502 Bad Gateway ​

原因：卫星未启动或端口不匹配。

排查：

1. 确认卫星已启动：curl http://localhost:8090/actuator/health（期望返回 {"status":"UP"}）。
2. 确认 config/dev-forward.json 中对应服务的 url 端口与卫星启动端口一致。
3. 提升卫星日志级别辅助排查：
   yaml

   logging:
     level:
       com.je.standalone.dev.forward: DEBUG

Q5：修改了卫星源码，需要重启吗 ​

需要。卫星不支持热重载。修改源码后：

1. IDEA 自动编译（或 Build → Compile）。
2. 在 Debug 面板点击 Restart（或 Ctrl+F5 / Shift+F10）。

继续阅读 业务插件开发与打包 了解如何开发业务插件；或回到 IDEA 配置与运行 查看卫星 Run Configuration 详情。

平台基础组件与工具类 ​

本章目标 ​

读完本章，你应当能够：

• 知道灵象在二次开发中可复用的后端基础组件与工具类有哪些大类。
• 在动手写代码前，先判断「平台是否已经提供了对应能力」，避免重复实现。

要点提纲 ​

后端基础组件与工具类 ​

下面按能力大类列出常见的可复用方向（具体类名 / 方法签名以平台为准，见各小节「待补」）：

通用 CRUD ​

查询封装 ​

字典 / 用户 / 组织 / 文件工具 ​

使用建议 ​

• 先查后写：动手前先确认平台是否已有对应工具，优先复用。
• 遵守红线：复用平台组件不等于可以改平台源码，二次开发约束见代码开发总览的「三条红线」。
• 依赖范围：在业务插件里引用平台依赖时用 provided，原因见业务插件开发与打包。

待补 ​

• [ ] 补充后端通用 CRUD 的入口与最小示例。
• [ ] 补充查询封装对象的构造与分页 / 排序用法。
• [ ] 补充字典工具类名与常用方法。
• [ ] 补充用户 / 组织工具类名与常用方法（取当前用户、组织、权限）。
• [ ] 补充文件工具类名与上传 / 下载 / 读取示例。
• [ ] 补充其他通用工具（日期 / 字符串 / JSON / ID 生成等）清单。

前端内容请看这里 ​

前端通用组件、统一请求封装（Ajax 与接口调用）等前端二次开发内容已统一收口到前端组件与工具。

定时任务（XXL-Job） ​

架构概述 ​

JECloud AI 灵象采用调度/执行分离架构：调度中心（admin，端口 3060）与单体内的执行器（端口 9999）各自独立运行，共用内嵌 MariaDB（端口 33306）上的专用数据库 jecloud-job。

• 执行器：随单体进程启停，自动注册所有定时任务处理器（Handler）。
• 调度中心：job/jecloud-job-admin.jar 独立进程，提供任务配置与触发的 Web 界面；按照 cron 计划向执行器发起 HTTP 回调，触发实际业务逻辑。
• 专用数据库：jecloud-job 库与业务数据完全隔离，由启动脚本在单体就绪后自动创建。

启动与停止 ​

启动 ​

执行 scripts\start.bat（Windows）或 bash scripts/start.sh（Linux/macOS）。脚本会自动完成以下顺序：

1. 启动单体（Tomcat 8080 + 内嵌 MariaDB 33306 + 内嵌 Redis 61379）。
2. 单体启动过程中，SqlBootstrapRunner 在内嵌 MariaDB 上建立 jecloud-job 库。
3. 后台脚本每隔 5 秒轮询 http://localhost:8080/actuator/health，直到单体返回 "status":"UP"。
4. 单体就绪后，拉起调度中心 job/jecloud-job-admin.jar（端口 3060）。

单体与调度中心全部就绪后：

停止 ​

执行 scripts\stop.bat（Windows）或 bash scripts/stop.sh（Linux/macOS）。停止脚本会同时清理 8080 / 7010 / 33306 / 61379 / 3060 上的进程，调度中心随之停止。

详细的启停说明见 启停与健康检查。

登录调度中心 ​

1. 浏览器访问 http://127.0.0.1:3060。

2. 使用默认账号登录：

   字段	值
   用户名	admin
   密码	123456

新增 / 启停任务 ​

1. 在调度中心左侧菜单，进入任务管理，选择执行器分组。

2. 点击新增，填写以下关键字段：

   字段	说明
   执行器	选择 jecloud-standalone-executor
   JobHandler	填写单体内 @XxlJob("…") 注解括号里的名称，大小写须完全一致
   Cron	标准 cron 表达式，如 0 0 2 * * ? 表示每天凌晨 2 点

3. 保存后点击任务右侧的启动按钮，任务即按计划触发。

内置的 4 个平台 Handler ​

迁移生产任务配置 ​

如果已有生产 XXL-Job 任务配置（xxl_job_group、xxl_job_info 等），可以直接导入。

第一步：从生产数据库导出

mysqldump -u <用户名> -p <生产库名> xxl_job_group xxl_job_info > exported-jobs.sql

第二步：导入单体内嵌 MariaDB

mysql -h 127.0.0.1 -P 33306 -u root -pbt5 jecloud-job < exported-jobs.sql

第三步：修改执行器地址

生产环境可能有多个执行器节点，而灵象单体只有一个。在调度中心执行器管理页，将分组的"注册方式"改为手动录入，地址填：

http://127.0.0.1:9999/

也可以直接更新数据库：

UPDATE xxl_job_group
SET address_type = 1,
    address_list = 'http://127.0.0.1:9999/'
WHERE app_name IN ('jecloud-rbac-executor', 'jecloud-meta-executor');

关闭定时任务 ​

如果不需要定时任务功能，可以通过以下方式关闭执行器（调度中心仍独立运行，但不会触发任何业务逻辑）。

在 config/application.yml 中添加：

jecloud:
  standalone:
    xxl-job:
      enabled: false

关闭后，单体不再监听 9999 端口，调度中心的所有回调请求均会 Connection Refused。

常见问题 ​

Q1：调度中心显示执行器"离线" ​

排查步骤：

1. 确认单体已正常启动，日志中应出现 >>>>>>>>>>> xxl-job registry success。
2. 检查执行器端口 9999 是否被占用或被防火墙拦截：
   • Windows：netstat -ano | findstr :9999
   • Linux/macOS：lsof -i :9999
3. 进入调度中心执行器管理，确认分组的在线机器地址为 127.0.0.1:9999（含结尾斜杠）。
4. 检查 config/jecloud-job.properties 中的 xxl.job.accessToken 与 config/application.yml 中的 jecloud.standalone.xxl-job.access-token 是否一致（默认均为空，不配置即可）。

Q2：调度中心启动报 Unknown database 'jecloud-job' ​

原因：单体尚未完成启动，jecloud-job 数据库还未创建。

解决：使用 scripts\start.bat 统一启动，让脚本等待单体就绪后再拉起调度中心。

如果需要手动启动调度中心，先确认单体已完全就绪：

mysql -h 127.0.0.1 -P 33306 -u root -pbt5 -e "SHOW DATABASES;"

确认 jecloud-job 出现在列表中后，再运行：

java -Xms128m -Xmx512m -jar job/jecloud-job-admin.jar \
  --spring.config.additional-location=optional:file:./config/jecloud-job.properties

Q3：端口 3060 被占用，调度中心无法启动 ​

Windows：

netstat -ano | findstr :3060
taskkill /F /PID <pid>

Linux/macOS：

lsof -ti tcp:3060 | xargs kill -9

如需更换端口，修改 config/jecloud-job.properties 中的 server.port，同时修改 config/application.yml 中的 jecloud.standalone.xxl-job.admin-addresses，保持一致。

Q4：端口 9999 被占用，执行器无法启动 ​

在 config/application.yml 中更换执行器端口：

jecloud:
  standalone:
    xxl-job:
      executor-port: 9998

同步在调度中心执行器管理页将分组地址改为 http://127.0.0.1:9998/。

Q5：任务触发后无执行日志 / 无回调 ​

排查步骤：

1. 查看调度中心日志 logs/job-admin.out，确认是否有 Routing LocalFirst failed 等错误。
2. 确认单体日志中有 >>>>>>>>>>> xxl-job registry success。
3. 在调度中心执行器管理 → 对应分组 → 在线机器列表应显示 127.0.0.1:9999，若为空则执行器未注册成功，参考 Q1 排查。

配置参考 ​

执行器配置（config/application.yml） ​

jecloud:
  standalone:
    xxl-job:
      enabled: true                             # 总开关（默认 true）
      admin-addresses: http://127.0.0.1:3060    # 调度中心地址
      app-name: jecloud-standalone-executor     # 执行器分组 appname
      executor-port: 9999                       # 执行器监听端口
      log-path: ./logs/xxl-job                  # handler 执行日志目录
      log-retention-days: 30                    # 执行日志保留天数
      access-token:                             # 访问令牌（与 jecloud-job.properties 保持一致，默认空）

调度中心配置（config/jecloud-job.properties） ​

server.port=3060
spring.datasource.url=jdbc:mysql://127.0.0.1:33306/jecloud-job?useUnicode=true&characterEncoding=UTF-8&serverTimezone=Asia/Shanghai
spring.datasource.username=root
spring.datasource.password=bt5
xxl.job.accessToken=

相关链接 ​

• 启停与健康检查 — 脚本行为、健康检查命令
• 配置说明 — 端口修改、密码配置、功能开关
• 常见问题与排错 — 通用排错方法

数据库使用规则 ​

本章说明灵象的物理数据库布局、业务表路由机制、建表约束和 SQL 升级文件规范。

物理三库 ​

灵象运行时在同一个内嵌 MariaDB 实例（端口 33306）上维护三个互相隔离的 schema：

本章路由机制涉及平台库与业务库，调度库（jecloud-job）由调度中心独立管理，详见 定时任务（XXL-Job）。

两个业务相关 schema 均位于同一个内嵌 MariaDB 实例（端口 33306）上，物理上独立，无需开发者手动切换连接。

路由机制： MyBatis 拦截器 BusinessTableRoutingInterceptor 在 SQL 执行前检查涉及的表名。对于 BusinessTableRegistry 白名单中的业务表，拦截器自动在表名前加上 jecloud_business. 前缀，将 SQL 路由到业务库；平台表则保持默认，路由到平台库。这一切对业务代码透明——你写 SELECT * FROM CRM_CUSTOMER，框架自动改写为 SELECT * FROM jecloud_business.CRM_CUSTOMER。

归属判定 ​

一张表究竟属于业务库还是平台库，由以下规则确定：

归属判定 = je_core_resourcetable  ⋈  je_product_manage

具体逻辑：

建表注意 ​

全局表名唯一 ​

灵象单机运行时，所有产品的业务表共享同一个 jecloud_business schema。微服务版中每个产品可以有独立数据库（同名表不冲突），但在灵象里会直接报 ER_TABLE_EXISTS_ERROR。

命名约定： <产品代号大写>_<业务实体大写>

CRM_CUSTOMER      ✅  前缀清楚
CRM_ORDER         ✅
CUSTOMER          ❌  无前缀，来源不明，极易撞名

跨服务撞名案例： instant_push_news 同时出现在平台的消息服务（30-message.sql）和连接器服务（50-connector.sql），后导入的 DROP TABLE IF EXISTS 覆盖前者。业务表命名时须检查是否与平台已有表名重复。

系统列 ​

每张业务表必须包含平台标准系统列（SY_PRODUCT_ID、SY_PRODUCT_CODE、SY_TENANT_ID、SY_CREATEORGID、SY_CREATEUSERID、SY_CREATETIME 等审计列）。通过平台建表 UI 操作会自动补全；手写 SQL 时须手动添加。

字符集 ​

所有表必须使用 utf8mb4：

CREATE TABLE CRM_CUSTOMER (
    ID   VARCHAR(50)  NOT NULL,
    NAME VARCHAR(100) NOT NULL,
    ...
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;

不要使用 utf8（MySQL 历史遗留的 3 字节编码，无法存储 emoji）。

改 schema ​

使用 SQL 升级文件 ​

所有 schema 变更（加表、加列、加索引、数据迁移）必须通过升级文件完成，不得直接在生产库执行裸 SQL。

升级文件位于：

sql/upgrade/
├── 2026-05-08-standalone-defaults.sql
├── 2026-06-01-add-crm-tables.sql
└── 2026-06-15-add-status-column.sql

命名规范： <YYYY-MM-DD>-<英文短描述>.sql

• 日期前缀保证按文件名字典序执行的顺序正确
• 文件名必须全局唯一，发布后不可重命名或修改内容
• 内容发布后只能通过新增升级文件来修正，不能回头改老文件

幂等性 ​

每个升级文件只会执行一次，执行结果记录在 _jecloud_schema_version 表中。即使如此，升级文件本身也必须写成幂等的，以防历史记录丢失时重跑不出错：

-- 不幂等（重跑报错）
ALTER TABLE CRM_ORDER ADD COLUMN STATUS VARCHAR(20);

-- 幂等写法
ALTER TABLE CRM_ORDER ADD COLUMN IF NOT EXISTS STATUS VARCHAR(20);

-- 不幂等
INSERT INTO JE_CORE_DICTIONARY (DIC_CODE, DIC_NAME) VALUES ('CRM_STATUS_NEW', '新建');

-- 幂等写法
INSERT INTO JE_CORE_DICTIONARY (DIC_CODE, DIC_NAME)
SELECT 'CRM_STATUS_NEW', '新建' FROM DUAL
WHERE NOT EXISTS (
    SELECT 1 FROM JE_CORE_DICTIONARY WHERE DIC_CODE = 'CRM_STATUS_NEW'
);

不要在升级文件里 DROP 表或 DELETE 数据 ​

升级 / 回滚 / 灾难恢复时，数据丢失最常见的原因就是升级脚本里的 DROP TABLE 或 DELETE。需要废弃一张表时，先重命名：

RENAME TABLE old_table TO old_table_DEPRECATED_20260615;

等三个版本（约半年）确认无人使用再 DROP。

业务插件开发与打包 ​

本章面向需要在灵象底座上开发自定义 Java 业务逻辑的开发者，介绍插件目录结构、manifest 规范、安装方法和类加载顺序。

插件目录 ​

灵象发行包根目录下的 plugins/ 文件夹称为插件根目录，其中每个子目录是一个桶（bucket）：

plugins/
├── system/      ← 平台 8 个服务 jar（出厂随包，不要手动改动）
├── business/    ← 客户二开 jar（出厂为空，你的插件放这里）
└── <其他>/      ← 自定义桶，字母序加载（高级用法）

加载顺序（固定）：

1. plugins/system/ — 平台 8 个微服务，最先加载
2. plugins/business/ — 客户业务插件，次之
3. 其余子目录，按目录名字母序依次加载

打你的业务插件 ​

包名规则 ​

推荐使用自定义包名（如 com.example.crm），避免与平台代码命名空间冲突。

Manifest 文件 ​

每个业务 jar 的 META-INF/jecloud-plugin.yml 是插件的自描述清单，告诉 PluginPackageRegistrar 需要额外扫描哪些包。

最小 manifest 示例：

name: customer-crm
version: 1.0.0
type: business
description: 客户 CRM 模块

componentScan:
  - com.example.crm

字段说明：

pom.xml 依赖范围 ​

业务插件的 pom.xml 引用平台依赖时，一律使用 <scope>provided</scope>，因为这些依赖运行时已由主 jar 提供：

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
    <scope>provided</scope>
</dependency>

项目骨架 ​

使用 jecloud-service-archetype 起新仓（或参考文档站的示例工程），目录结构如下：

customer-crm/
├── pom.xml
└── src/main/
    ├── java/com/example/crm/
    │   ├── controller/CrmController.java
    │   ├── service/CrmService.java
    │   └── dao/CrmMapper.java
    └── resources/
        ├── META-INF/
        │   └── jecloud-plugin.yml     ← 插件 manifest
        └── mapper/CrmMapper.xml

构建：

mvn -DskipTests package
# → target/customer-crm-1.0.0.jar

安装 / 更新 ​

永远按以下三步操作，不存在例外：

第 1 步：停止灵象
  Windows:  scripts\stop.bat
  Linux:    ./scripts/stop.sh

第 2 步：复制 jar 到插件目录
  cp customer-crm-1.0.0.jar  <灵象根>/plugins/business/

第 3 步：启动灵象
  Windows:  scripts\start.bat
  Linux:    ./scripts/start.sh

更新插件时同样执行以上三步：先停再换 jar 再起。不要在运行中替换 jar——LaunchedURLClassLoader 已在启动期缓存 URL，替换文件对运行中的 JVM 无效，且会导致 ClassNotFoundException。

类加载顺序 ​

灵象使用 Spring Boot 的 LaunchedURLClassLoader，PluginLoader.prioritizePluginUrls() 在启动期完成 URL 重排，最终顺序如下：

1. BOOT-INF/classes/     ← 适配层 + FQN 复写（最高优先级）
2. plugins/**/*.jar      ← 你的业务 jar + 平台 8 个 service jar
3. BOOT-INF/lib/         ← SDK stub + 三方依赖（最低优先级）

为什么这个顺序是固定的：

• 第 1 层放在最前：保证适配层对平台类的 FQN 复写能覆盖 plugin jar 里的同名类。
• 第 2 层（plugin）在 SDK stub 之前：保证平台真正的实现类被加载，而不是 SDK 存根（stub）。
• 第 3 层放在最后：SDK stub 仅做编译期占位，运行期被前两层覆盖。

不要尝试改变这个顺序——颠倒任何一层都会导致 bean 注入拿到空 stub 或 FQN 复写失效。

微应用开发 ​

① 获取前端骨架 ​

微应用工程从官方前端骨架仓库脚手架而来，配合前端基础库一起使用：

• 骨架仓库：https://gitee.com/ketr/jecloud-pc-archetype
• 前端基础库：https://gitee.com/ketr/jecloud-pc-libs

运行环境（版本需严格对齐，避免依赖编译失败）：

npm config set registry http://verdaccio.jecloud.net/

工程结构：

├─.vscode   # vscode 配置
├─build     # webpack 与 git hooks
├─docs      # 文档
├─service   # 系统文件（不要修改）
├─public    # 静态资源
└─src       # 源码

② 安装依赖 ​

按是否需要调试基础库源码，分两种安装方式。

非源码用户（只用骨架，不改基础库）：

npm run setup:lib

源码 / 调试用户（需要本地联调 jecloud-pc-libs）：

先在基础库工程里发布本地包，再回到微应用工程安装：

# 1. 全局安装联调工具
npm i yalc lerna@^6.0.0 -g

# 2. 拉取并构建基础库，本地发布
git clone https://gitee.com/ketr/jecloud-pc-libs.git
npm run setup
npm run yalc:publish

# 3. 回到微应用工程安装依赖
npm run setup

③ 本地运行与打包 ​

下图是骨架自带的微应用示例（设备运营数据驾驶舱），执行 npm run dev 后即可在浏览器看到：

骨架自带的"设备运营数据驾驶舱"示例，npm run dev 启动后的本地预览效果。

④ 挂载到平台 ​

开发完成后，把 npm run build 的产物挂载到平台：在 开发 › 核心引擎 › 微应用管理 中添加该微应用并完成注册。

开发 › 核心引擎 › 微应用管理：注册并挂载自研微应用的入口界面。

平台功能事件 ​

脚本模板按适用组件分组列出全部功能事件，左侧选组件、右侧看事件清单与脚本编辑区。

一、事件脚本写法（方法体） ​

事件脚本写的是方法体：从全局 EventOptions 解构出当前事件的上下文对象，按事件语义处理逻辑或 return 渲染内容。下面是平台真实示例（list-row-renderer 列表行渲染事件）：

const {
    $func,  // 功能对象
    $grid,  // 功能列表对象
    row,    // 行对象，使用 row.字段编码 取字段值，也可赋值
} = EventOptions;

// 处理渲染内容
// return JE.h('div', { style: '' }, '展示内容');
return '';

要点：

• 事件方法体从 EventOptions 解构上下文，不同事件的可用字段不同——常见有 $func（功能对象）、$grid（列表对象）、row（行对象）等。
• 渲染类事件（如行渲染、列字段渲染）需要 return 渲染内容，可用 JE.h 创建 vnode（虚拟 DOM 节点）；JE 全局方法见前端组件与工具。
• 每个事件都标有适用范围：全部（电脑端与移动端均生效）/ 电脑端 / 移动端。

二、全部事件清单（按适用组件） ​

下面按适用组件逐个列出平台支持的全部功能事件。左侧在脚本模板中选定组件后，右侧即对应该组件下表中的事件清单。

表格（功能） ​

表格列 ​

表单 ​

字段表达式 ​

按钮 ​

action 列 ​

子功能集合 ​

代码编辑器 ​

颜色选择器 ​

关联选择 ​

树形选择 ​

人员选择 ​

图标选择器 ​

图片选择器 ​

附件 ​

多附件 ​

数据集合 ​

下拉框 ​

虚拟字段 ​

其他单事件组件 ​

下列组件各只有一个事件，合并列出：

前端组件与工具 ​

平台前台API 以树形列出全部全局方法，点开任一方法可查看说明与代码案例。

JE 全局静态类 ​

JE 是全局静态类，可在所有事件脚本里直接使用。下表列出其全部全局方法：

Vue 3 能力（通过 useVue 暴露） ​

通过 JE.useVue() 取得 Vue 3 的核心能力，事件脚本 / 前端微应用可基于这套能力按 Vue 3 组合式 API 的常规写法开发。按用途分组如下：

通用 ​

响应式：核心 ​

生命周期钩子 ​

ajax 数据请求 ​

JE.ajax(options) 是统一的请求封装，参数：url / params / headers / method（默认 POST） / timeout（默认 300000） / token（默认 true） / baseURL；返回 Promise。下面是平台真实示例：

// JE.ajax(options) 参数：url / params / headers / method(默认 POST) / timeout(默认 300000) / token(默认 true) / baseURL；返回 Promise
// 无参数
JE.ajax('/je/xxx').then((data) => {
  console.log(data);
});
// 对象参数
JE.ajax({ url: '/je/xxx', params: {}, headers: {} }).then((data) => {
  console.log(data);
});
// 多 ajax 同步等待
Promise.all([JE.ajax('/je/xxx'), JE.ajax('/je/yyy')]).then(([a, b]) => {
  // ...
});

其他类目 ​

平台前台API 树除 JE 外，还有三个类目：

• EventOptions：事件方法体里解构的上下文对象，例如 $func、$grid、row 等。它是功能事件脚本的入参，承载当前功能、表格、行数据等上下文，详见平台功能事件。
• 实例对象：表单、表格、按钮等运行时实例的可调用对象，提供取值、刷新、校验等实例级操作。
• 常用案例：按场景整理的可复制代码案例，覆盖事件脚本中的高频写法。

Windows 启动 ​

本页介绍在 Windows 10 / 11 上解压并启动 JECloud AI 灵象的完整流程。

第一步：解压 ​

将下载到的 -windows.zip 发行包解压到一个纯 ASCII、无空格、无符号链接的目录，例如：

D:\jecloud-linxiang

解压后目录结构如下：

D:\jecloud-linxiang\
├── jeapp-standalone.jar      主程序（薄启动器，依赖在 lib/，不能 java -jar）
├── plugins/
│   ├── system/               平台 8 个服务 jar（出厂自带，勿删）
│   └── business/             业务插件（自定义开发时放这里，出厂为空）
├── lib/                      第三方依赖库（运行时由脚本加入 -cp）
├── license/                  证书文件目录（放 jecloud.license）
├── data/
│   └── mysql/                MariaDB 数据目录（首次启动时自动创建）
├── config/
│   └── application.yml       外部配置（端口、DB/Redis 凭据等）
├── logs/                     运行日志（spring.log，按日期滚动）
├── web/                      前端静态资源
├── job/
│   └── jecloud-job-admin.jar 定时任务调度中心（独立进程）
└── scripts/
    ├── start.bat             全量启动
    ├── stop.bat              停止
    ├── start-mysql.bat       仅启动 MariaDB
    ├── start-redis.bat       仅启动 Redis
    ├── start-app.bat         仅启动应用（需 DB/Redis 已运行）
    └── start-debug.bat       调试模式启动（开启远程调试端口）

第二步：一键启动 ​

在命令提示符（cmd）或文件资源管理器中双击运行：

scripts\start.bat

start.bat 做的事 ​

1. 端口预检 — 检查 8080 / 7010 / 33306 / 61379 是否空闲；任一占用则立即报错退出
2. 清理残留端口 — 如有上次未正常退出的残留进程，强制清理
3. 启动内嵌 MariaDB（端口 33306）及 SQL bootstrap（建库/建表/写初始数据）
4. 启动内嵌 Redis（端口 61379）
5. 启动 Spring 应用（Tomcat 8080 + Netty WebSocket 7010）
6. 后台拉起 job-admin — 等待主程序 /actuator/health 返回 UP 后自动启动调度中心（3060）

Java 运行时选择顺序 ​

脚本按以下优先级选择 JVM，无需手动安装 Java（-full 包已内置）：

1. jdk\bin\java.exe（发行包内置 JDK，优先）
2. jre\bin\java.exe（发行包内置 JRE）
3. PATH 环境变量中的 java（系统已安装的 Java，须为 Java 8）

关键 JVM 参数 ​

主程序以 -cp（非 -jar）方式启动，classpath 顺序为：

jeapp-standalone.jar → plugins/system/* → plugins/business/* → lib/*

此顺序是架构约束，不能调整（见 产品内核 · 插件化架构）。

分量启动（按需） ​

开发或排查问题时，可单独启动各组件：

仅启动数据库 ​

scripts\start-mysql.bat

• 运行模式：run-mode=mysql
• 堆：-Xms64m -Xmx256m
• 该窗口即是数据库进程，关闭窗口等同于停止 MariaDB

仅启动 Redis ​

scripts\start-redis.bat

• 运行模式：run-mode=redis
• 堆：-Xms32m -Xmx128m

仅启动应用（需 DB / Redis 已运行） ​

scripts\start-app.bat

• 运行模式：run-mode=app
• 堆：-Xms2048m -Xmx4096m
• 适合只改了代码需重启应用的场景：DB/Redis 保持运行，仅重启应用进程，避免重新初始化数据库

调试模式（IDEA 远程调试） ​

scripts\start-debug.bat

与 start.bat 相同，额外追加：

-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005

默认调试端口 5005；可通过环境变量 DEBUG_PORT 覆盖：

set DEBUG_PORT=5006
scripts\start-debug.bat

在 IDEA 中新建 Remote JVM Debug 配置，Host localhost，Port 5005（或自定义端口），连接后即可设置断点。

停止 ​

scripts\stop.bat

停止流程：

1. POST /actuator/shutdown 优雅关闭应用
2. 等待 5 秒
3. 两轮端口清扫（pass2 使用 Stop-Process -Force）

清扫端口范围：8080（应用）、7010（WebSocket）、33306（MariaDB）、61379（Redis）、3060（job-admin）。端口值优先级：命令行参数 → config/application.yml → 内置默认值。

首次启动提示与登录 ​

首次启动时请参阅 安装与首次启动 · 总览 中的「首次启动若缺授权证书」和「启动完成后」两节，了解：

• LicenseGate 证书检查面板及处理步骤
• StartupBanner 启动完成信息框（访问地址、登录账号、数据库凭据）
• 健康检查地址 http://localhost:8080/actuator/health

配置项说明请参阅 配置说明。遇到启动失败、端口冲突等问题，请查阅 常见问题与排错。

Linux 启动 ​

本页介绍在 Linux（x86_64 与 aarch64/ARM64）上解压并启动 JECloud AI 灵象的完整流程。

第一步：解压 ​

根据机器架构选择对应发行包：

解压到一个纯 ASCII、无空格、无符号链接的目录，例如：

tar -xzf jecloud-linxiang-3.1.1-linux-x86_64.tar.gz -C /opt
cd /opt/jecloud-linxiang

第二步：赋予执行权限 ​

chmod +x scripts/*.sh

第三步：启动 ​

bash scripts/start.sh

首次启动的幂等前置步骤 ​

首次运行时，start.sh 会自动执行以下前置脚本（幂等，已安装则跳过）：

• scripts/install-jre-bundle.sh — 按平台解压内置 JRE 到 jre/ 目录（-full 包专有；-slim 包依赖外部 Java）
• scripts/install-mariadb-bundle.sh — macOS 及 aarch64 Linux 解压自包含 MariaDB 到 mariadb/ 目录（x86_64 使用 mariaDB4j 内嵌二进制，无需此步骤）

start.sh 做的事 ​

1. 运行幂等前置 — install-jre-bundle / install-mariadb-bundle
2. 端口预检 — 检查 8080 / 7010 / 33306 / 61379 是否空闲；任一占用则立即报错退出
3. 启动内嵌 MariaDB（端口 33306）及 SQL bootstrap（建库/建表/写初始数据）
4. 启动内嵌 Redis（端口 61379）
5. 启动 Spring 应用（Tomcat 8080 + Netty WebSocket 7010）
6. 后台拉起 job-admin — 等待主程序 /actuator/health 返回 UP 后自动启动调度中心（3060）

Java 运行时选择顺序 ​

脚本按以下优先级选择 JVM：

1. ./jdk/bin/java（发行包内置 JDK，优先）
2. ./jre/bin/java（发行包内置 JRE）
3. PATH 环境变量中的 java（系统已安装的 Java，须为 Java 8）

关键 JVM 参数 ​

Linux 控制台默认 UTF-8，无需 -DCONSOLE_LOG_CHARSET 参数（Windows 专用）。

主程序以 -cp（非 -jar）方式启动，classpath 顺序为：

jeapp-standalone.jar:plugins/system/*:plugins/business/*:lib/*

ARM64（aarch64）说明 ​

linux-arm64 发行包随包含自包含 MariaDB（因 mariaDB4j 2.5.0 无 aarch64 二进制）。首次启动时 install-mariadb-bundle.sh 会自动将 mariadb/linux-arm64.tar.gz 展开，后续启动直接使用，无需重复操作。

其他启动流程与 x86_64 完全相同。

停止 ​

bash scripts/stop.sh

停止流程：

1. curl -X POST http://localhost:8080/actuator/shutdown 优雅关闭应用
2. sleep 3 秒
3. 杀主进程 + job-admin 进程
4. lsof 清理残留端口（8080 / 7010 / 33306 / 61379 / 3060）

集群从节点（可选） ​

多节点部署时，从节点使用 start-node.sh 启动（仅运行应用，连接主节点的共享 DB/Redis）：

bash scripts/start-node.sh

默认主节点 IP 为 10.0.0.1（MAIN_HOST 变量），根据实际情况修改：

MAIN_HOST=192.168.1.100 bash scripts/start-node.sh

从节点特点：

• 运行模式：run-mode=app（不启动 DB/Redis，不存文件，不跑定时任务）
• 连接主节点共享 MariaDB（33306）与 Redis（61379）
• 本机仍启动 WebSocket（7010），支持推送
• 需在主节点 nginx 配置中加入从节点地址

详见 多节点集群与负载均衡。

首次启动提示与登录 ​

首次启动时请参阅 安装与首次启动 · 总览 中的「首次启动若缺授权证书」和「启动完成后」两节，了解：

• LicenseGate 证书检查面板及处理步骤
• StartupBanner 启动完成信息框（访问地址、登录账号、数据库凭据）
• 健康检查地址 http://localhost:8080/actuator/health

配置项说明请参阅 配置说明。遇到启动失败、端口冲突等问题，请查阅 常见问题与排错。

macOS 启动 ​

本页介绍在 macOS（Apple Silicon 与 Intel）上解压并启动 JECloud AI 灵象的完整流程。

本页内容参考随包附带的 macOS 跨机首次启动说明文档（docs/jecloud-macos-跨机首次启动说明.html）。

发行包选择 ​

第一步：解压 ​

将发行包解压到一个纯 ASCII、无空格、无符号链接的目录，例如：

mkdir -p ~/work
unzip jecloud-linxiang-3.1.1-macos-arm64.zip -d ~/work/jecloud-linxiang
cd ~/work/jecloud-linxiang

第二步：清除隔离标记（quarantine）— 必须执行 ​

从网络下载或跨机拷贝来的发行包，macOS 会自动添加 quarantine（隔离）标记。若直接双击运行，系统会对包内每个可执行文件逐一弹出"无法验证开发者"对话框，导致内置 mysqld 等原生库无法启动。

首次启动前，须在终端执行一次清除操作：

cd ~/work/jecloud-linxiang        # 进入解压目录
sudo xattr -cr .                  # 清除隔离标记（每份包仅需一次）
bash ./scripts/start.sh           # 或双击 start.command

清除后即可直接双击 start.command 启动，无需每次执行。

进阶修复（清理后仍失败时） ​

若执行 sudo xattr -cr . 后仍然报"损坏"或 mysqld 无法启动，请尝试重签名原生库并重置数据目录：

cd ~/work/jecloud-linxiang
sudo xattr -cr .
find mariadb/macos-arm64 -type f \( -perm -111 -o -name '*.dylib' \) -exec codesign --force --sign - {} \; 2>/dev/null
rm -rf data/mysql
bash ./scripts/start.sh

find mariadb/macos-x86_64 -type f \( -perm -111 -o -name '*.dylib' \) -exec codesign --force --sign - {} \; 2>/dev/null

第三步：启动 ​

bash scripts/start.sh

或在 Finder 中双击 start.command。

首次启动的幂等前置步骤 ​

首次运行时，start.sh 会自动执行以下前置脚本（幂等，已安装则跳过）：

• scripts/install-jre-bundle.sh — 按平台解压内置 JRE 到 jre/ 目录（-full 包专有）
• scripts/install-mariadb-bundle.sh — 解压自包含 MariaDB 到 mariadb/ 目录（macOS 随包含自包含 MariaDB，MariaDB.org 不提供 macOS 通用二进制）

start.sh 做的事 ​

1. 运行幂等前置 — install-jre-bundle / install-mariadb-bundle
2. 端口预检 — 检查 8080 / 7010 / 33306 / 61379 是否空闲；任一占用则立即报错退出
3. 启动内嵌 MariaDB（端口 33306）及 SQL bootstrap（建库/建表/写初始数据）
4. 启动内嵌 Redis（端口 61379）
5. 启动 Spring 应用（Tomcat 8080 + Netty WebSocket 7010）
6. 后台拉起 job-admin — 等待主程序 /actuator/health 返回 UP 后自动启动调度中心（3060）

平台共 8 个启动阶段，控制台会依次打印 [1/8]…[8/8] 进度提示。首次约需 60–90 秒。

Java 运行时选择顺序 ​

脚本按以下优先级选择 JVM：

1. ./jdk/bin/java（发行包内置 JDK，优先）
2. ./jre/bin/java（发行包内置 JRE）
3. PATH 环境变量中的 java（系统已安装的 Java，须为 Java 8）

关键 JVM 参数 ​

macOS 终端默认 UTF-8，无需 -DCONSOLE_LOG_CHARSET 参数（Windows 专用）。

停止 ​

bash scripts/stop.sh

停止流程：

1. curl -X POST http://localhost:8080/actuator/shutdown 优雅关闭应用
2. sleep 3 秒
3. 杀主进程 + job-admin 进程
4. lsof 清理残留端口（8080 / 7010 / 33306 / 61379 / 3060）

首次启动提示与登录 ​

首次启动时请参阅 安装与首次启动 · 总览 中的「首次启动若缺授权证书」和「启动完成后」两节，了解：

• LicenseGate 证书检查面板及处理步骤
• StartupBanner 启动完成信息框（访问地址、登录账号、数据库凭据）
• 健康检查地址 http://localhost:8080/actuator/health

配置项说明请参阅 配置说明。遇到启动失败、端口冲突等问题，请查阅 常见问题与排错。

配置说明 ​

配置在哪 ​

所有运行时配置只需修改一个文件：

<发行包根>/config/application.yml

发行包内置的默认值写在 jeapp-standalone.jar 里的 BOOT-INF/classes/application.yml，不要修改 jar 内的文件。启动时通过 -Dspring.config.additional-location=file:./config/ 加载外部配置，外部 yml 中的字段会覆盖 jar 内默认值。

三层优先级（从低到高）：

端口配置 ​

默认端口及联动关系：

DB / Redis 凭据 ​

所有数据库和缓存凭据统一在一处配置：config/application.yml。

默认值：

spring:
  datasource:
    username: root        # 内嵌 MariaDB 固定使用 root 账号
    password: bt5         # 数据库密码（默认 bt5）
  redis:
    password: 123456      # Redis 密码（默认 123456）

• 主节点：首次启动时程序用这份凭据初始化内嵌 MariaDB（创建 localhost / 127.0.0.1 / % 三个 host 的 root 账号并设置密码），同时设置 Redis requirepass，并灌入全量基础数据。运行时平台服务也使用同一份凭据连接。
• 从节点 / 外部库：在同一份 yml 设置 jecloud.standalone.shared-host 为主节点 IP，username / password 填目标库凭据，run-mode=app 不初始化库、直接连接。

内置的三个数据库 ​

standalone 用一个内嵌 MariaDB 进程（端口 33306，账号 root/bt5）承载三个互相隔离的数据库：

三个库均通过同一账号 root/bt5 连接同一个 MariaDB 进程（端口 33306），但在 schema 层面完全独立。

安全提示 ​

使用非默认密码时，请注意以下几点：

1. 凭据明文写入 Apollo 缓存：启动期程序会把 spring.datasource.*、spring.redis.* 等凭据以明文写入 apollo-cache/jecloud-standalone/config-cache/*.properties（平台服务通过该文件读取连接信息）。该目录权限等同本机文件，请确保 dist 安装目录只有受信任的用户可访问，并将该目录排除出备份/同步范围，避免明文外泄。

2. 灌库阶段密码短暂可见：SqlBootstrapRunner 调用 mysql 命令行客户端时，密码以 --password= 参数传入。在子进程存活的短暂窗口内，密码可被本机 ps 命令或任务管理器看到。单机本地部署可接受；多用户共享主机请注意。

3. 调度中心密码单独配置：调度中心（XXL-Job admin）是独立的 Java 进程，不读取 config/application.yml，其数据库连接在 config/jecloud-job.properties 中单独配置（spring.datasource.password，默认 bt5，连接同一台内嵌 MariaDB 的 jecloud-job 库）。如果修改了 DB 密码并重新初始化，必须同步修改 config/jecloud-job.properties 中的密码，否则调度中心启动后无法连接数据库。

功能开关速查 ​

相关链接 ​

• 启停与健康检查 — 脚本行为、健康检查命令
• 常见问题与排错 — 端口冲突、连接失败

多节点集群与负载均衡 ​

架构概述 ​

JECloud AI 灵象支持横向扩展为"1 主节点 + N 从节点 + nginx 轮询"架构，分摊高并发请求。

登录态无需会话粘滞：身份验证基于 token + 共享 Redis，任意节点都能验证，nginx 轮询不需要 sticky session。

部署步骤 ​

第一步：启动主节点 ​

在主节点机器上正常执行：

scripts\start.bat

主节点就绪后，放开防火墙，允许所有从节点访问：

• 端口 33306（MariaDB）
• 端口 61379（Redis）

第二步：配置并启动从节点 ​

在每台从节点机器上：

1. 解压同一份发行包。

2. Windows：用文本编辑器打开 scripts\start-node.bat，将顶部的 MAIN_HOST 改为主节点 IP：

   bat

   set "MAIN_HOST=<主节点IP>"

3. Linux/macOS：编辑 scripts/start-node.sh 顶部的 MAIN_HOST：

   bash

   MAIN_HOST=<主节点IP>

   或以环境变量方式传入：

   bash

   MAIN_HOST=<主节点IP> bash scripts/start-node.sh

4. 运行脚本：

   bat

   scripts\start-node.bat

   从节点不会初始化 data/mysql/，也不会监听 33306 / 61379。

第三步：配置并启动 nginx ​

准备 nginx 二进制：

• Windows：发行包已内置 nginx/nginx.exe，无需安装。
• Linux：sudo apt install nginx 或 sudo yum install nginx。
• macOS：brew install nginx。

脚本检测到 nginx/ 目录下有二进制时优先使用，否则使用系统 PATH 中的 nginx。

编辑 nginx/conf/nginx.conf，修改三个 upstream：

# 文件流量 —— 只填主节点
upstream jecloud_main {
    server <主节点IP>:8080;
}

# HTTP 业务流量 —— 填全部节点（主节点建议 weight=1，从节点 weight=3）
upstream jecloud_http {
    server <主节点IP>:8080  weight=1;
    server <从节点1IP>:8080 weight=3;
    server <从节点2IP>:8080 weight=3;
}

# WebSocket —— 填全部节点
upstream jecloud_ws {
    server <主节点IP>:7010;
    server <从节点1IP>:7010;
    server <从节点2IP>:7010;
}

启动 nginx：

scripts\start-nginx.bat

Linux/macOS：

bash scripts/start-nginx.sh

启动后，浏览器通过 nginx 80 端口访问平台。

停止 nginx：

scripts\stop-nginx.bat

验证 ​

部署完成后，执行以下检查确认集群正常工作：

1. 轮询不掉线：反复刷新页面或在不同标签页操作，登录态始终稳定，不出现需要重新登录的情况。
2. 跨节点推送：在一个节点发起操作（如审批、消息），目标用户无论连接到哪个节点都能收到实时推送（待办/通知）。
3. 文件上传下载：从任意节点上传文件，通过任意节点均可正常下载/预览（document 服务流量恒落主节点）。
4. 定时任务只跑一份：确认定时任务仅在主节点执行（从节点 jecloud.standalone.xxl-job.enabled=false），不重复触发。

已知限制 ​

1. 文件吞吐瓶颈：所有文件存储在主节点磁盘。文件上传下载量较大时，主节点磁盘 I/O 和带宽是瓶颈。如有需要，可后续接入共享存储或对象存储。

2. 主节点负载偏重：主节点同时承担数据层（MariaDB / Redis）、文件存储和定时任务。通过 nginx 将大部分 HTTP 流量引到从节点（weight=3）可以减轻主节点的应用层压力。

3. 从节点本地临时文件：少数导出/预览功能可能在处理请求的节点本地生成临时文件；若该节点不是主节点，跨节点拉取时可能找不到该文件（边缘场景）。

4. 主节点单点：主节点宕机则整个集群不可用（本版本不提供主节点高可用，HA 列入后续路线图）。

5. 安全：主节点的 33306 / 61379 端口需对从节点子网开放，务必置于可信内网并配合防火墙隔离，切勿暴露到公网。

相关链接 ​

• 配置说明 — DB / Redis 凭据修改、shared-host 配置项说明
• 启停与健康检查 — 单节点启停脚本说明
• 定时任务（XXL-Job） — 集群中定时任务只在主节点运行

备份与恢复 ​

定期备份可以在磁盘损坏、误操作或升级失败后快速恢复现场。本文说明需要备份哪些目录、如何执行冷备份与热备份，以及如何完整恢复。

要备份什么 ​

冷备份流程（推荐） ​

冷备份在停服状态下进行，数据一致性最强，是推荐方案。

步骤 ​

1. 停服（确保 MariaDB 数据文件完整落盘）：

   bat

   scripts\stop.bat

2. 复制关键目录到备份位置。

   Windows（xcopy）：

   bat

   xcopy /E /I /Y data   backup\data
   xcopy /E /I /Y files  backup\files
   xcopy /E /I /Y license backup\license
   xcopy /E /I /Y config  backup\config

   Linux / macOS（tar）：

   bash

   tar czf backup-$(date +%Y%m%d%H%M%S).tgz data files license config

3. 重新启动：

   bat

   scripts\start.bat

恢复流程 ​

1. 停服：

   bat

   scripts\stop.bat

2. 用备份覆盖对应目录（整体替换，不要合并）：

   Windows：

   bat

   rmdir /S /Q data\mysql
   xcopy /E /I /Y backup\data\mysql data\mysql
   xcopy /E /I /Y backup\files files
   xcopy /E /I /Y backup\license license
   xcopy /E /I /Y backup\config  config

   Linux / macOS：

   bash

   rm -rf data/mysql
   tar xzf backup-20240601120000.tgz

3. 启动：

   bat

   scripts\start.bat

不停机热备（进阶） ​

如果业务不能中断，可以用 mysqldump 对运行中的内嵌 MariaDB 做逻辑热备。热备的一致性弱于冷备（备份期间仍有写入时，多表间可能存在短暂不一致），适合作为冷备的补充。

mysqldump -h 127.0.0.1 -P 33306 -u root -p<密码> \
  --single-transaction \
  --routines --triggers \
  jecloud > backup-jecloud-$(date +%Y%m%d%H%M%S).sql

把 `<密码>` 替换为实际密码（默认 bt5；-p 与密码之间不加空格）。

恢复时：

mysql -h 127.0.0.1 -P 33306 -u root -p<密码> jecloud < backup-jecloud-20240601.sql

相关链接 ​

• 数据清理与方案卸载 — 需要彻底重来时的清库/卸载操作
• 版本升级 — 每次升级前请先完成备份

数据清理与方案整理 ​

清理方案有两种方式：直接在平台界面点按钮（界面操作，推荐日常使用），或调用本机 REST 端点（命令行方式，适合脚本化/批量）。两者最终落到同一套后端逻辑。

界面操作 ​

入口 ​

进入 开发 › 服务管理 › 方案类服务管理，点击 business（业务服务）这条数据进入其表单，表单顶部工具栏有两个红色按钮：

开发 › 服务管理 › 方案类服务管理：进入 business 后，表单顶部工具栏的两个红色清理按钮。

两个按钮的含义 ​

命令行方式（脚本化） ​

JECloud AI 灵象同时提供两个本机管理端点，用于清理方案数据或清空方案业务内容。两个端点均只绑 127.0.0.1，只能从安装了灵象的本机调用。集群/反代部署时，dist 自带 nginx 模板已禁止 /je/standalone/ 路径；自定义反代配置务必同样封堵，否则远端用户可绕过本机限制。

两个端点 ​

使用前提：

• 仅允许方案类服务（产品管理中 PRODUCT_TYPE='1'）；meta / rbac / workflow 等平台服务会被拒绝，返回错误提示。
• 同一时刻只允许一个清理请求执行（并发调用返回"另一个清理操作正在执行，请稍后重试"）。

用法 ​

# 1. 只预览将清理的内容（confirm=true，不动数据）
curl -X POST "http://127.0.0.1:8080/je/standalone/cleanup/data?productCode=demo&confirm=true"

# 2. 真执行（缺省即真删，无需任何额外参数）
curl -X POST "http://127.0.0.1:8080/je/standalone/cleanup/data?productCode=demo"

同理，design 端点：

# 预览将清空的业务内容（保留骨架；confirm=true 仅预览）
curl -X POST "http://127.0.0.1:8080/je/standalone/cleanup/design?productCode=demo&confirm=true"

# 真执行（表 DROP 不可逆！建议先备份 data/；缺省即真执行）
curl -X POST "http://127.0.0.1:8080/je/standalone/cleanup/design?productCode=demo"

confirm 参数解析规则：true、1、yes、on（大小写不敏感）均视为仅预览；缺省或 false 为真执行；非法值（如 ture、ok）返回 HTTP 400 且不会执行任何操作。

返回结构 ​

两个端点均返回统一 JSON 格式，data.steps[] 逐步列出统计与执行结果：

{
  "code": "1000",
  "success": true,
  "message": "操作成功",
  "data": {
    "productCode": "demo",
    "productName": "第一个服务",
    "dryRun": true,
    "steps": [
      { "step": "workflow-instances", "instances": 12, "status": "ok" },
      { "step": "business-tables",
        "tables": [{ "name": "HR_QJSQ", "type": "PT", "rows": 2 }],
        "status": "ok" }
    ],
    "hasFailures": false,
    "executed": false
  }
}

真执行（缺省，不带 confirm）时每个表条目追加实际删除行数，TREE 类型表追加 rootPreserved（true = 已保留 ROOT 根节点），executed 为 true。执行过程的逐步进度通过控制台 log.info 实时输出（含"共 N 张表、当前第 i/N 张"）；接口同步返回，响应体不含逐步日志，仍返回完整 steps[]。

每步 status 取值：

脚本判定失败的三层契约 ​

推荐 bash + jq 判定写法（以真执行为例）：

# 真执行 = 缺省、不带 confirm（带 confirm=true 只会预览不动数据）
resp=$(curl -s -w '\n%{http_code}' -X POST \
  "http://127.0.0.1:8080/je/standalone/cleanup/data?productCode=demo")
body=$(echo "$resp" | head -n -1)
http=$(echo "$resp" | tail -n 1)

[ "$http" = "200" ] || { echo "HTTP $http"; exit 1; }
[ "$(echo "$body" | jq -r .success)" = "true" ] || { echo "$body" | jq -r .message; exit 1; }
[ "$(echo "$body" | jq -r .data.hasFailures)" = "false" ] || { echo "$body" | jq '.data.steps'; exit 1; }
echo "清理完成"

完整调用示例 ​

# 1. 预览将清理的业务数据（confirm=true，无副作用）
curl -X POST "http://127.0.0.1:8080/je/standalone/cleanup/data?productCode=demo&confirm=true"

# 2. 核对无误后真执行（缺省即真删，不带 confirm）
curl -X POST "http://127.0.0.1:8080/je/standalone/cleanup/data?productCode=demo"

# 3. 预览清空业务内容（保留骨架；confirm=true，无副作用）
curl -X POST "http://127.0.0.1:8080/je/standalone/cleanup/design?productCode=demo&confirm=true"

# 4. 核对无误后真执行（表 DROP 不可逆！建议先备份 data/）
curl -X POST "http://127.0.0.1:8080/je/standalone/cleanup/design?productCode=demo"

安全 ​

design 端点执行前务必备份 ​

常见问题 ​

"仅允许清理方案类服务"
productCode 指向的是平台服务（如 meta、rbac、workflow）或产品类型不是 '1'。请在产品管理界面确认该方案的 PRODUCT_TYPE 为 '1'。

design 会删掉方案本身吗？
不会。design 现在是"清空业务内容、保留骨架"：保留根菜单（SY_PARENT='ROOT'）与方案记录本体（JE_PRODUCT_MANAGE）；流程实例/定义、资源表（PT/TREE/VIEW 三类按产品库 DROP）、功能（含子系统全部删除）、子菜单、字典都清。因此不再需要先移除开发者角色，可直接调用 design 端点。

树形表清完为什么还剩一行？
data 清理对树形（TREE）表会保留主键值为 ROOT 的根节点（业务树需要根节点占位）。主键列由 INFORMATION_SCHEMA 实时解析；万一无法识别唯一主键列，会回退全表清空并在日志/rootPreserved=false 中标注。design 端点是整表 DROP，不涉及此项。

执行时怎么看进度？
清理为同步执行（无后台任务），过程逐步打到控制台日志（log.info），含"共 N 张表、当前第 i/N 张表"等进度；接口同步返回完整 steps[]，失败原因在 steps[].error 一并回前端。

workflow 步骤显示 warning
工作流清理为附加能力（best-effort）：先调引擎接口删（byEngine），删不掉的转 SQL 兜底（bySql）。引擎不可用或删除异常时，该步骤标记为 warning 并跳过，不影响其余清理步骤，hasFailures 不受影响。如需彻底清理流程，修复原因后重新调用同一端点即可续删（操作幂等）。

resource-tables 步骤报"互引环或子表不在本方案内"
错误信息会列出每张卡住表的 children（引用它的子表）详情。按提示在低代码建模工具中解开相互引用关系后，重新调用端点重试。

删视图报 Unknown table 'jecloud_platform.v_xxx'？
已修复。现按产品类型判定所属库（平台层→jecloud_platform，方案类→jecloud_business），带库前缀显式 DROP，PT/TREE/VIEW 三类一致。若仍出现此错误，说明您使用的是旧版本，建议升级。

想彻底重来、清空所有数据
停止应用，删除 data/mysql/ 目录，重启后系统会从零重建全新数据库（包含基线数据）。注意：此操作同时清空所有方案及平台数据，不可恢复。

相关链接 ​

• 备份与恢复 — 执行不可逆操作前的冷备份步骤
• 版本升级 — 升级时请勿同时执行清理操作
• 启停与健康检查 — 清理前的停止与重启流程

增强组件（增强套件） ​

增强组件是 JECloud 平台核心之外、可按需选装的能力包。底座保持精简，需要门户大屏、移动端、升级运维、信创安全等进阶能力时，再以套件形式选装即可。

本页整理自 JECloud 官方商城 jecloud.net/shop 的「增强组件」目录，列出全部官方增强组件及其说明，方便你按业务需要选型。

一、流程与业务编排 ​

二、端与展现 ​

三、开发与运维 ​

四、文档与办公集成 ​

五、安全合规（信创 / 等保） ​

六、通信与存储 ​

重点组件详解 ​

部分常用组件已在本手册单独成页，含官方完整介绍：

• 展示套件 —— 图表引擎 + 报表引擎 + 门户引擎
• 升级套件 —— 跨环境功能级打包迁移升级

流程管理套件 ​

JECloud 的流程管理套件通过梳理和优化业务流程，减少冗余步骤，精确识别流程中的关键环节，确保每个环节都能高效运转。它包含七大核心功能：

1. 流程监控：实时跟踪流程执行情况，保障业务流程顺畅流转与持续优化。
2. 运行时流程：含【流程调拨】和【前后跳转】，可灵活调整业务流程与步骤执行顺序，实现资源高效配置与任务动态分配。
3. 运行时规划：已发起的流程不满足当前业务需求时，可在不影响其他规划的前提下，单独对该流程做出规划调整。
4. 历史流程：记录与分析过去操作为优化决策提供依据，并可将已结束流程重新启动。
5. 异常流程：流程提交或执行发生异常时，管理员能清晰定位异常数据并调整。
6. 运行时流程交接：人员工作变动时，可将其待办一键交给他人，实现责任动态转移。
7. 未来处理人交接：人员变动时统一调整流程规划中的处理人，避免手动逐条修改的遗漏。

业务全流程套件 ​

业务流是一个公司的流程链——一项业务的几个流程的顺序，用于描述各部门、各人员之间的业务关系、作业顺序，以及整个业务的流程与走向。通过业务流，公司可对整体业务的推进进度、处理过程、时间节点及时把控，并及时发现并调整不合理的流向，保证效率。业务流图形样式支持自定义，可通过左侧元素库拖拽组合快速搭建流程，并对图形进行样式、状态、颜色等编辑。

手机套件 ​

作为专业的企业级移动应用开发平台，JEAPP 提供各种在线的 App 开发工具，可快速开发出适配多平台（iOS、Android、H5、微信小程序）的移动应用，服务领域覆盖互联网、能源、电商、教育、金融、医疗、旅游等行业。典型场景：移动审批方便快捷、外出办公随时查看工作数据。

官方特殊说明：手机套件提供 2 次免费打包服务（支持安卓、iOS 打包）；超过 2 次后按 1500 元/次收取打包服务费用。

运维套件 ​

用于自动化运维基于 JECloud 平台开发出的软件项目，一键发布前后端代码包。

装载方式概述 ​

增强组件通常有两种装法（具体以各组件交付说明为准）：

• 插件桶装载：把组件 jar 放到发行包 plugins/ 下对应的桶目录，再按 stop → 放入 → start 重启加载。插件桶的概念、加载顺序与「不支持热插拔」的约束见 业务插件开发与打包。
• 随升级包下发：部分组件（如升级套件）作为版本升级的一部分下发，配合 版本升级 流程一并安装。

展示套件 ​

官方定价：¥14000（标价仅供参考，以官方报价为准）。一句话：支持图表配置开发与综合门户设计。

套件介绍（官方） ​

JECloud 的展示套件包含三个关键引擎：

1. 图表引擎——软件运行中产生的业务数据常需图形化分析展示，工程师可通过点选配置的方式开发出柱形图、条形图、饼图、线图、面积图、雷达图等常用图表。
2. 报表引擎——可完成普通报表、交叉报表、查询报表等常见报表功能。
3. 门户引擎——图表与报表开发完毕后，用门户引擎进行页面排版规划；门户除了可引入图表，还可嵌入功能数据、标准日历、超级链接、图片轮播等常用组件。当现有组件不足以支撑业务需求时，门户还提供插件机制，充分发挥工程师的创造力。

本章目标 ​

读完本章，你应当能够：

• 了解展示套件提供的能力——图表引擎 / 报表引擎 / 门户引擎三大展示类能力。
• 知道如何获取、部署和验证展示套件。

安装与部署步骤（提纲） ​