简介面向JNPF平台开发、实施与运维人员的一份完整操作手册由福建引迈信息技术有限公司发布系统梳理V3.4.2版本的功能体系。手册以模块化方式组织在线开发部分重点讲解表单设计、列表设计、流程设计与结果展示的操作步骤门户设计与大屏设计部分则覆盖新建门户、大屏管理、地图管理、分类管理及数据源管理代码生成部分介绍功能表单、流程表单的生成方法系统管理部分深入说明系统配置、公告发布、调度、缓存、日志、监控及菜单权限等。整份手册共1个PDF文件约40.01MB目录层级完整便于按图索骥。目前已有1339人学习下载适合需要快速掌握JNPF低代码开发平台或进行项目交付的读者。通过阅读可了解从业务建模、界面搭建到权限配置、系统运维的完整链路减少摸索时间。1. 低代码的真实面目拖拽不是生成页面是生成一份元数据很多人第一次打开 JNPF 这类低代码平台都会默认它做的是“拖拽生代码”把几个控件拖进画布平台在背后翻译出前端文件保存就等于把代码写好。实际上正好相反。保存表单时真正入库的是一份元数据——控件的类型、绑定字段、事件脚本全在里面等用户访问这个功能运行时引擎再当场把元数据解析成活页面。设计态的一小块配置决定了运行态的表结构、权限粒度、流程走向。搞懂这份元数据怎么设计、怎么被消费你才能解释为什么数据权限能精确到行、为什么主表叫 mt 开头、为什么改了主键策略就跑不起来。2. 表单设计器控件字段绑定、主键策略与并发锁定背后的数据模型2.1 控件字段绑定设计器里那一下“下拉”到底做了什么在功能设计里新建表单流程是先做基础设置进入表单设计从左侧拖控件到画布然后在右侧属性里把“控件字段”选成数据表的某个字段。这个下拉是最容易被忽略却最关键的配置。它做的不是存一个字符串而是把 UI 树上的控件节点和数据模型里的字段节点连成一条边。拖拽控件时画布上多了一个组件节点数据表来自基础设置里选中的数据连接和数据表没有特别绑定就自动建表。控件字段下拉选择字段本质是建立“控件节点→表字段”的映射。运行时引擎拿到的是类似下面的结构{ formName: 报销申请, mainTable: mt_112233, controls: [ { widgetId: c_001, type: input, label: 报销人, table: mt_112233, field: apply_user, required: true }, { widgetId: c_002, type: subtable, table: ct_998877665544332211, foreignKey: main_id, children: [ { type: input, field: item_name } ] } ] }运行时引擎根据 type 实例化对应的控件组件把表单值统一放到 formData[field] 里提交时按每个控件声明的 table 和 field 拆开写库主表控件写主表子表控件遍历 children 逐行写子表。手动改动元数据比在界面上拖拽更容易翻车就是因为字段名、事件脚本、表名任何一处对不上引擎要么解析失败要么把值写进错误列。还有一类控件不需要绑业务字段——按钮、分割线、说明文字它们只存 widgetId 和 type运行时不参与写库。所以设计器里有些控件没有“控件字段”下拉保存后数据表里也没有对应列这不是 bug是它们本来就不是数据控件。理解了这层映射很多现象就说得通了。基础设置里选了多表就要配置子表的外键字段和关联主键否则引擎不知道子表每一行挂在主表的哪一行上控件字段下拉里能“快捷新建字段”本质是打开数据建模的生命周期在字段字典里先追加一列再把控件节点挂上去。字段集和控件集不是同一棵树但永远通过字段名对齐。2.2 主表“mt功能ID”、子表“ct雪花ID”表名里的分布式设计手册里有一句不起眼的规则未设置数据连接时流程新建完成后自动建表主表以“mt功能ID”命名子表以“ct雪花ID”命名。这个命名规则不是排版习惯而是为多库、多组织的自动建表设计的。主表名带功能 ID是为了让表名可以直接反查功能定义看到 mt_112233 就知道这是功能 ID 为 112233 的表。代码生成、流程引擎、权限引擎都要在元数据库与业务库之间来回切换一个能双向推导的命名规则省去了维护“表名-功能”映射表的成本。子表用雪花 ID 则有两层考虑一是子表没有业务主键可借用二是如果子表用数据库自增在多数据源、多组织写并发以及跨库导入导出时容易主键撞车。雪花 ID 生成一个 64 位整数由符号位、41 位毫秒时间戳、10 位机器 ID、12 位序列号组成单机单位毫秒可生成约 40 万个 ID不依赖中心发号器也能保证全局唯一。表单属性里的“主键策略”支持雪花 ID 和自增长 ID并且保存后不可修改。这个限制不是平台故意刁难主键策略在建表 DDL 里已经写死自增长依赖数据库 auto_increment 或序列雪花主键依赖应用侧生成器两者的 ORM 插入逻辑和物理表结构都不一样运行时改策略必然导致新旧数据主键语义分裂。“并发锁定”对应的是乐观锁机制开启后更新语句会变成这样UPDATE mt_112233 SET apply_user :newValue, version version 1 WHERE id :id AND version :oldVersion;如果 update 影响行数为 0说明记录在打开期间已被别人改过引擎会抛并发冲突而不是让后提交的人静默覆盖。这也是办公表单的标准选择编辑页打开时间可能很长悲观锁会把一行数据锁到提交并发稍高就出现锁等待乐观锁只在提交瞬间做版本比对冲突率低的场景几乎无感。代价是冲突时用户要重新拉数据再提交一次这个体验上的取舍平台选择了乐观。2.3 组件事件与表单脚本JavaScript 钩子如何在运行时生效手册里组件属性支持“发生变化时触发”“失去焦点时触发”表单属性支持“表单加载触发”“提交前置触发”“提交后置触发”给的入口是直接写 JavaScript。这里有个理解误区脚本不是绑在原生 DOM 事件上而是由表单引擎实例管理。用户操作控件引擎先把新值写入内部表单数据模型再广播“字段 X 发生变化”事件此时引擎检查该控件在元数据里是否配置了 change 脚本如果有就用一个注入好上下文对象的沙箱执行。脚本里的 this 指向表单实例常见调用包括 setValue、setVisible、setRequired。手册给的例子正好覆盖四种典型联动选 a 时给字段 a 赋值为 1选 b 时给字段 b 赋值为 2选 c 时隐藏控件 c选 d 时设置控件 d 为必填。// 下拉控件 change 事件根据选中值驱动其他控件 if (this.value a) { this.setValue(field_a, 1); } if (this.value b) { this.setValue(field_b, 2); } if (this.value c) { this.setVisible(field_c, false); } if (this.value d) { this.setRequired(field_d, true); }注意脚本里引用的是控件字段名不是控件标题。标题是给人看的字段名才是引擎内部识别的键。写错字段名不会立刻报错而是联动静默失效这是“页面能用但互动全没反应”的最常见原因。表单加载、提交前置、提交后置三个钩子的执行时机分别在数据模型初始化完成后、校验通过准备落库前、事务提交后。前置脚本通常做跨字段校验或拼装提交值脚本抛异常会中断提交并回显错误给了设计者一个不用改后端代码的校验通道。组件样式里还藏着一个容易忽略的能力多端显示。桌面端和移动端可以分别配置某个控件显不显示本质上是在元数据里为每个控件保存了两份端显示策略。同一份表单元数据桌面端和移动端渲染出不同的控件集合这比维护两套表单高明的多——数据模型只有一个两端只是从不同角度消费它。3. 数据应用数据连接、数据建模与接口认证的安全设计3.1 数据连接与数据建模一个功能一张主子表表单基础设置里的“数据连接”下拉是整个数据链路的起点。数据连接指向不同的数据库实例表单选择了某个连接自动建表时就落到那个库。这意味着一个平台可以同时管理多套业务库订单库、人事库、档案库各在一处功能设计通过数据连接把它们组装进同一个操作界面。多租户或多组织场景下这个设计直接决定了数据物理隔离能力。数据建模承担两种职责一是可视化创建表和字段录入表名、字段名、类型、长度、是否必填二是给表单设计器提供字段来源。控件字段下拉里看到的字段本质上来自数据建模的字段字典在控件字段下拉里点“新增字段”操作的也是同一个字典。字段字典的增删改会影响引用它的每一个表单控件设计器会重新渲染字段列表。数据建模定义了主表子表关系后表单基础设置才能选择多表并配置子表外键字段和关联主键。这样一组配置下来的结构大致是对象命名示例作用主表mt_112233存表单主记录一功能对应一主表子表ct_雪花ID存明细记录通过外键关联主表外键字段main_id子表里指向主表主键的列关联主键id主表主键与外键字段配对表单控件绑定字段、子表设计时关联子表全部围绕这套表结构展开。字段没绑定表运行时提交就不知道往哪写子表控件没关联子表拖再多控件也不会生成明细数据。这个“先有表结构、再谈控件绑定”的顺序也是早期无表模式被去掉的根本原因——无表模式起步快可一旦进入表单、流程、报表交叉引用阶段没有物理表结构支撑数据无法做聚合、同步和权限行过滤最后还是得补建模这一步。3.2 数据接口与接口认证签名机制如何挡住重放攻击子表控件的“动作设置”里有一个容易忽略的入口配置弹窗、选择数据接口接口返回数据填充子表手册里叫远端数据联动。它的运行流程是用户点“添加子表数据”→ 弹窗打开 → 前端带参数调用数据接口 → 接口返回若干行候选数据 → 用户勾选后按“关联字段”映射规则回填子表单。参数设置区展示接口参数再下拉表单字段作为筛选条件就是在定义调用接口前的过滤表达式。这个能力一旦开放给前端认证就不能只靠登录态。数据接口可能被第三方系统直接调用也可能在用户会话外被表单引擎触发所以数据应用里专门提供“接口认证”。常见的实现思路是 AppKey/AppSecret 签名import hashlib import time import requests def make_sign(params: dict, secret: str) - str: # 参数名按ASCII升序排列拼成 a1b2 形式 items sorted(params.items()) raw .join(f{k}{v} for k, v in items) # 追加密钥后做摘要 raw raw key secret return hashlib.md5(raw.encode()).hexdigest().upper() params { appId: 10001, timestamp: str(int(time.time() * 1000)), nonce: c29f8a3e, pageSize: 20 } params[sign] make_sign(params, your-secret) resp requests.get(/api/form/data-query, paramsparams)签名里必须带 timestamp 和 nonce。timestamp 让服务端拒绝超过时间窗口的请求nonce 是一次性随机值服务端记录已消费的 nonce从而挡住重放攻击AppSecret 不直接出现在请求里只参与签名计算所以抓包拿到请求也伪造不出合法签名。把 body 内容纳入签名还能防参数篡改接口有分页或排序参数时签名必须覆盖这些参数否则有人可以悄悄改 pageSize 把全量数据拉走。这套机制最容易出的问题是两端签名规则不一致参数没排序、时间戳用秒级但服务端校验毫秒级、空值字段到底拼不拼各地实现五花八门。验签失败时优先对比两端日志里 raw 字符串长什么样比对着文档硬想快得多。3.3 数据字典与数据同步枚举外置和跨库搬运数据字典解决枚举值的管理问题。表单里的下拉、单选、多选控件选项来源可以指向数据字典库里只存字典项标识页面展示时再翻译成文本。改选项不用动表结构、不用发版字典项调整后所有引用它的控件同步变化。行政区划复用同一套模型内置标准行政区划数据组织管理里选地区时直接拉树。数据同步则是跨库搬运机制。多数据源把数据拆在不同库报表、大屏、汇总统计需要把多个库聚到一起。同步一般分全量和增量两种模式增量靠源表的时间戳或版本号实现每次同步记录一个“水位线”下次只拉水位线之后的数据。这类任务挂在系统调度里定时执行、失败重试、运行日志在系统日志和系统监控里都能追溯。4. 工作流引擎节点状态机、超时提醒与流程复活的实现路径4.1 流程设计的三层装配表单、节点和条件各管一段工作流程模块里流程设计分为基础信息、表单设计、流程设计三部分。拆成三步不是操作步骤的巧合而是流程本质被拆成了三个独立领域表单负责“数据长什么样”流程负责“数据怎么流转”基础信息负责“两者怎么绑定”。流程设计器里的节点一般包括开始、审批、条件分支、抄送、子流程、结束审批节点配置审批人、审批规则、通知方式条件分支配置表单字段的判定表达式。以常见的报销流程为例开始节点之后第一个审批节点处理部门审批审批人按角色或岗位解析通过后进入条件分支金额小于 1000 走轻量审批大于等于 1000 走多级审批。表单字段在这里被当作条件表达式的变量流程引擎根据提交的数据做路由判断。所以字段类型很重要数字字段才能做金额比较日期字段才能做时限判断把金额存在文本字段里条件表达式写起来会非常别扭。表单设计和流程设计分离还有一个工程价值同一个表单能挂到多个流程上。比如“请假申请”表单可以同时用于员工请假流程和调休申请流程表单引擎只负责把提交数据落库流程引擎决定这条数据接下来去哪两边通过流程实例 ID 和表单主键关联而不是把流程逻辑写死在表单组件里。4.2 状态机驱动的流转审批人解析、超时提醒与自动同意每个流程实例在任意时刻都处在某个节点、某个状态本质上是一个状态机。节点状态大致有等待中、处理中、已通过、已驳回、已撤回流转动作是提交、同意、驳回、转交、撤回。引擎内部维护一张任务表每条待办记录关联流程实例、当前节点、处理人和进入时间。审批人配置支持指定成员、指定角色、指定岗位、发起人所在部门负责人、表单字段值等方式。引擎在流程到达节点时执行“审批人解析”根据配置规则查询组织和用户数据生成具体处理人列表。解析结果为空时节点会挂起并触发异常处理或通知管理员这就是“流程卡住了”的常见来源——不是节点坏了是候选人规则查不到人。超时提醒是节点上的一组时间配置。调度器定时扫描任务表找出“当前节点进入时间 超时时长 当前时间”且状态为等待中的任务执行节点配置的超时动作通常分提醒、自动同意、自动转交三档。// 每5分钟扫描一次超时任务 for (Task task : taskDao.findTimeoutTasks()) { // 1. 发提醒走站内信 / 短信模板 / 消息模板 notifyService.send(task.getAssignee(), task.getRemindTemplateId()); // 2. 超时动作自动同意则模拟“系统”完成当前节点 if (task.getTimeoutAction() TimeoutAction.AUTO_AGREE) { workflowEngine.complete(task.getId(), system, 超时自动同意); } // 3. 超时动作自动转交则把待办转给下一个处理人 if (task.getTimeoutAction() TimeoutAction.AUTO_TRANSFER) { workflowEngine.transfer(task.getId(), task.getTimeoutAssignee()); } }任务扫描必须考虑幂等扫描和发提醒之间任务可能刚被用户处理掉所以每次执行都要先以“状态等待中”为条件尝试更新任务状态更新成功才继续发提醒或执行动作避免同一任务被扫描线程重复处理。自动同意也不是无脑通过节点上还能配条件表达式只有满足条件才自动同意比如“金额小于 1000 且 8 小时内未处理”。节点事件和异常处理则是状态机的两个钩子。节点事件允许在节点进入、节点完成时执行脚本做数据联动或通知异常处理用于节点引擎本身抛异常时按预设策略处理——通知管理员、跳到指定节点、或终止流程实例。这些配置全部放在节点上是为了让每条流程的异常处理策略跟着流程定义走而不是改一行全局代码影响所有流程。4.3 待办、委托、子流程与流程复活工程上的几个硬骨头用户侧的“我发起的、待办事宜、已办事宜、抄送事宜”其实都在查同一套任务表区别在过滤条件待办查处理人工号等于当前用户且状态为等待中已办查处理人是当前用户且已完成我发起的查流程实例的发起人等于当前用户。抄送事宜是节点上配置了抄送人流程到达时给抄送人生成一条只读通知记录。流程委托解决人不在场的问题用户可以设置把某段时间内分配给自己的待办自动转给别人。实现上通常不真改任务表中的处理人而是在委托生效区间内将待办查询和处理权限映射成“处理人或受托人”操作记录留痕。委托结束后原有待办和已办历史不会错乱。子流程的同步异步是流程设计器里影响运行行为的配置。同步模式下主流程推进到子流程节点时挂起等待子流程结束把结果带回主流程再继续后续节点异步模式下主流程不等子流程两边并行推进适合“通知式”的子流程。子表传递解决主流程表单里的明细数据如何复制给子流程表单内部实现是读取主子表行数据按子流程表单的字段映射规则重新组装一份数据写入子流程实例表。流程复活则是给死流程一个后悔药。当流程实例被终止或作废业务表里的主记录还在系统通过特定入口把实例状态改回运行中把当前节点重置为指定节点并重新生成待办。已经归档的实例要重新打开填过的字段值不能丢与外部系统同步过的数据要重新触发回调。平台把它做成显式动作而不是自动恢复目的就是让复活成为一个需要人来确认的运维事件避免数据被不自觉来回改写。5. 权限体系与常见排查四级权限如何拼出一条SQL5.1 用户-角色-组织权限不是绑在人身上是绑在角色上系统权限模块包括分级管理、组织管理、岗位管理、用户管理、分组管理、角色管理、权限管理和在线用户。核心逻辑是用户不直接拥有权限用户挂在组织下组织下设置岗位角色承载权限集合再把角色授予用户或分组。分级管理决定谁能管理哪一层组织的数据在线用户用于查看当前会话和强制下线。为什么低代码平台要把权限拆这么细因为一个功能页面上同时存在菜单可见性、按钮可用性、列表列显示、表单字段编辑、数据行范围五种正交的权限。如果不抽象出角色-权限模型直接在用户表挂开关权限组合会变成指数级的维护灾难。把权限定义为“资源操作”的授权项角色只是授权项的集合用户-角色关系建立后新增用户自动带上该角色全部权限调整权限只需改角色这是这套模型能支撑几千人组织的根本原因。角色权限配置里菜单权限、按钮权限、列表权限、表单权限、数据权限五个维度同时存在。菜单权限控制用户能进哪个模块按钮权限控制工具栏上哪些按钮可见列表权限控制查询结果列出哪些列表单权限控制字段是否可见可编辑数据权限控制能查哪些行。单独配某一项而不顾其他项就会出现“菜单进去了、按钮不见”“字段可编辑、列表却没开放修改”这类互斥现象。5.2 按钮、列表、表单、数据四级权限的逐层过滤四个维度的实现层次不一样。按钮权限在前端过滤页面加载时权限引擎下发当前用户在该页面拥有的按钮编码集合前端渲染按钮时逐个判断编码是否存在按钮隐藏后页面源码里也找不到这个按钮的 HTML。列表权限在查询层过滤服务端返回列表数据前按字段白名单裁剪 SELECT 语句没有权限的列直接不进结果集而不是返回后前端隐藏避免数据已经在网络包里走了一圈。表单权限在表单引擎运行时过滤渲染表单元数据时引擎根据登录用户对当前功能的表单字段权限覆盖字段的可见性和可编辑性。即使设计器里字段设为必填、只读运行时仍以“设计配置用户权限”的交集为准。最容易踩坑的是设计器里改完字段属性线上的老权限数据还是旧配置需要同步菜单权限后才生效。数据权限是唯一做行过滤的一层一般不在业务代码里写死条件而是由权限引擎根据当前用户上下文动态拼接 SQL。几种典型规则对应不同 SQL 形态-- 规则一仅本人数据 WHERE create_by :currentUserId -- 规则二本部门及下级部门数据 WHERE dept_id IN ( SELECT id FROM sys_org WHERE path LIKE :deptPath || % ) -- 规则三按角色可见组织范围 WHERE org_id IN ( SELECT org_id FROM role_org_mapping WHERE role_id :currentRoleId )参数由权限引擎从会话上下文注入字段名由功能对应主表的元数据决定。收益是新增一个功能表单时只要表结构里有 create_by、dept_id、org_id 这几个约定字段行级权限自动生效业务代码不需要任何改动。代价是历史数据如果没填这些字段行过滤会把脏数据过滤掉表现为“明明库里刚插入的数据列表里看不见”处理方式是检查插入逻辑是否完整写入这几个字段而不是调整权限规则。提示数据权限的条件字段必须在数据建模时预留否则列表引擎拼不出行过滤条件。5.3 排查权限配置里最常见的五个翻车点现象一按钮权限配置正确但刷新页面按钮依然显示或不显示。原因是按钮权限和菜单权限没有同步或者系统缓存了旧的权限集。解决在系统菜单里重新保存该功能菜单让权限数据重新生成再清理系统缓存后重新登录验证不要把按钮权限单独改了就当完成。现象二数据权限选了“仅本人”用户还是能看到全表。原因是该用户挂了多个角色其中一个角色的数据权限范围是“全部”权限引擎按并集计算时把范围放大。解决统一角色授权规范把数据权限收敛到单一角色上或按业务约定选择取交集规则后再验证。现象三表单字段可编辑提交后值却丢了。原因是列表的编辑权限与表单权限不一致列表页编辑弹窗里没开放该字段的写权限。解决同时核对按钮权限、列表权限字段集合、表单权限字段集合三处字段白名单必须一致。现象四接口认证反复校验失败。原因是签名时参数排序或时间戳格式与平台端不一致。解决打开请求日志对比两端拼接的 raw 字符串统一编码、统一排序规则、校准系统时间再检查 nonce 有没有被复用。现象五某个子系统用户看到了另一个子系统的菜单。原因是菜单没有绑定到具体子系统属于跨应用数据交叉。解决在系统菜单里把菜单归属到对应子系统导入导出菜单时确认子系统编码有没有带过去。这类问题一般不是权限公式错了而是元数据归属关系没配干净排查时先看菜单表里的子系统编码再看角色的菜单授权。6. 代码生成与百万数据低代码平台的边界与取舍6.1 为什么保留代码生成代码生成模块包含功能表单和流程表单两种入口。选择功能表单后系统把设计好的元数据映射成一套可运行的工程代码实体类对应数据表字段持久层代码对应增删改查控制器暴露接口前端页面还原表单和列表。这套代码不是摆设而是低代码平台给开发者的后悔药——拖拽配置的运行态引擎胜在改配置即时生效但排障和深度定制终究有限生成可读代码开发者能脱离平台跑通链路、断点调试、替换某个组件实现甚至把代码拿走二次维护。这背后的取舍是平台不能假设所有需求都能被表单引擎解释执行表达报表、大屏、复杂交互、高性能接口往往需要在生成代码的基座上再手写一段。保留代码生成本质上是承认低代码的边界同时给越界者一个逃生通道。6.2 百万数据示例教会我的事扩展应用里专门有一个“百万数据”示例用来演示列表引擎在数据量上来之后的处理方式。常见的实现思路是服务端分页加前端虚拟滚动列表查询只请求当前页SQL 带 LIMIT 和 OFFSET数据总量单独 COUNT 统计前端列表组件只渲染可视区域的几十行而不是把结果全量塞进 DOM。查询条件尽量下推到数据库在列表查询字段上建索引而不是拉到内存里过滤。V3.4.2 手册把在线开发、代码生成、系统管理每一步都写到了按钮级读它的时候别满足于“会点”而是边点边问“这一步在元数据里改了什么”收获会完全不同。从那以后我每次设计一个新的功能表单都强制自己先回答三个问题主键策略选雪花还是自增数据权限挂在哪个角色上这个列表未来会不会接近百万行。这三个问题想清楚后面表单设计、权限配置、查询字段的顺序才不会被推翻重来。希望帮到你。本文还有配套的精品资源点击获取