简介：《JNPF产品功能使用手册_v3.4.2.pdf》面向JNPF低代码平台的使用者、实施人员与二次开发人员，系统梳理V3.4.2版本的功能操作与配置方法，可用于快速上手、功能对照和项目交付前自查。包内为1个PDF文件，大小约40.01MB，按在线开发、代码生成、系统管理三大板块组织，目录层级清晰，便于按表单、列表、流程、门户、大屏等模块检索。正文除表单设计、列表设计、流程设计与结果展示外，还覆盖门户新建、大屏管理、地图管理、分类管理、数据源管理及报表设计，并说明功能表单、流程表单的代码生成路径；系统管理部分延伸到基础设置、安全设置、第三方设置、超级管理员、系统公告、消息中心、系统调度、缓存、日志、监控、图标与菜单权限等内容。已有1343人学习，适合查阅完整功能说明和权限配置细节的读者。
1. 一份两百多页的低代码平台 V3.4.2 功能手册，能省掉多少试错
低代码平台 V3.4.2 功能手册这类文档，最大的价值是先让读者少犯错误。两百多页，从在线开发一路排到扩展应用，六个大章、几十个二级节点，通读一遍要一个下午。我第一次带队接这套平台的时候也这样，纸面流程背得挺熟，真到配子表传递还是卡住半天——手册里那个「动作设置」的弹窗，光看图是看不明白的。这份手册的价值不在“读”，在“查”：它把表单、列表、流程、门户、大屏、报表、代码生成、系统管理、系统权限、工作流程、扩展应用拆成了能照着点的界面步骤，每个参数落在屏幕上哪一格都标了图号。适合两类人：被安排接手平台、一两周内要交出第一个可用应用的人；以及已经用过一两个模块，想搞清楚自动建表命名规则和权限模型边界的熟手。版本从 V3.2 一路叠到 V3.4.2，流程侧的超时提醒、异常处理、流程复活、子表传递，都是这个版本才补齐的，老教程照抄会漏。
2. 在线开发第一课：从拖控件到子表传递，三条硬规则
2.1 新建之前先想清楚表从哪来
在线开发下的【功能设计】是整份手册的第一站，页面顶部有查询、重置、刷新、导入、新建表单五个动作，真正决定后面所有工作量的，是点开新建表单之后那一步——选类型。手册给了三个选项：表单、列表、流程。表单只有数据录入和结果展示；列表是表单叠一个列表页，带查询字段；流程在表单基础上挂审批流。很多人图省事一律选流程，结果一个纯记录型的字典表也跑出了审批链，后面想拆都拆不掉。
选完类型进基础设置页，这里只有一栏需要停下来想：数据连接。留空，平台会在流程新建完成后自动建表，主表命名是mt+功能ID，子表是ct+雪花ID；填了，就下拉选一个已有数据库，再点“新增一行”进数据选择页绑定表，来源是系统管理 → 数据应用 → 数据建模里建好的模型。两种路径的差别，落到运维上是完全不同的两件事：
| 维度 | 不选数据连接（自动建表） | 选数据连接（绑定已有表） |
|---|---|---|
| 表名规则 | 主表mt+功能ID，子表ct+雪花ID | 沿用已有表名，不动原库结构 |
| 字段维护 | 控件字段下拉里可快捷新建字段 | 已有字段只读，只能在字段设置窗口新增行 |
| 表结构变更 | 平台托管，改字段走控件配置 | 受原库约束，改字段要先动数据建模 |
| 典型场景 | 全新业务、原型验证、独立小系统 | 对接存量库、多系统共库、已有报表依赖 |
我一般的判断是：这张表将来会不会有第二个系统来读。会，就走已有表；不会，就让平台托管，省下来的时间够把流程节点配两遍。这里没有后悔药——自动建表之后想把mt前缀改成业务名，只能重建功能，前面的表单设计全部作废。
绑定多表时还有一步容易漏：选完表要点确定回到基础信息页，下方会列出已选表，如果选了两张以上，必须配子表的外键字段和关联主键，把主表和子表挂上。单表不需要这步，所以很多人第一次配多表时以为选完就完事了，结果发起流程数据只进了主表。
2.2 主表、副表、子表：控件字段映射的固定顺序
表单设计页是左中右三栏：左边控件区，中间画布，右边属性区。拖一个控件到画布，右侧第一件事不是调样式，是下拉“控件字段”选它对应的表字段。有表设计的前提下，控件不绑字段，这条数据就没有落库的地方。
副表和子表的挂法不一样，顺序错了会白忙。副表是“先选控件、再在右侧数据库表里选关联副表、最后关联控件字段”，三步都在同一个控件的属性面板里完成。子表则是“先拖设计子表控件 → 在右侧关联子表 → 才能把普通控件拖进子表区域 → 每个控件再各自关联子表字段”。手册里明确写了“方能拖拽控件到设计子表控件区域中”，这几个字是血泪经验——没关联子表的空壳容器，你把输入框拖上去，它要么弹回去，要么挂到了主表字段上，保存之后子表里空空如也。
字段不够用的时候不用退出去改表。下拉控件字段列表底部有个添加按钮，点开是字段设置窗口：上半部分列出当前表已有字段，只读，改不了；点“新建字段”会插一行空白行，自己填字段名、类型、长度。这个入口在副表和子表里都有，是手册里少数几个能一边设计界面一边扩表结构的地方。我的习惯是先把主表字段一次性建全，再动子表，避免在子表控件里反复开关字段设置窗口。
一个功能里能挂几张表，手册给的上限组合是：副表加子表、两个副表、两个子表。超出的需求，说明这个功能该拆成两个了。
2.3 子表合计与动作设置：子表传递怎么跑通
子表控件右侧有两个开关，是这套平台里最容易被低估的功能。
合计设置打开后，选合计字段，来源限定为子表内的单行输入、数字输入、计算公式这三类字段，可以多选。流程使用时子表框下方会多出一行合计栏。选不到字段，八成是那个字段的类型不在三类里——日期、下拉、附件这些都不参与合计。
动作设置是子表传递的入口。打开后点“配置表单”，弹窗里能自定义标题、弹窗类型（居中或右侧）、弹窗宽度。然后是“远端数据联动”，从数据接口弹窗里选一个接口（来源是数据应用 → 数据接口），选完接口自带的参数会自动铺到参数设置区，每个参数下拉选一个主表字段作为筛选条件。这一步的本质是：子表点“添加数据”时，平台拿主表字段的值当入参去调这个接口，接口返回什么，弹窗里就展示什么。
接口返回的数据要落进子表，还得配两段映射：
- 设置列表字段：决定弹窗里展示哪几列，一行一个，列名对应接口返回的字段。
- 设置关联字段：决定选中一行之后，接口字段怎么填进子表的表单字段。映射来源支持两种，接口字段或者固定值。
举个例子，接口返回长这样：
{ "code": 0, "data": [ { "skuCode": "A-1001", "skuName": "标准件", "unitPrice": 12.5, "unit": "件" }, { "skuCode": "A-1002", "skuName": "非标件", "unitPrice": 30.0, "unit": "件" } ] }那列表字段就配三行：skuCode→ 编码、skuName→ 名称、unitPrice→ 单价。关联字段配四行：skuCode → 子表.物料编码、skuName → 子表.物料名称、unitPrice → 子表.单价、unit → 子表.单位，最后一行如果想统一成“件”，映射来源选固定值填件也行。
这里有个隐性依赖：接口的参数名必须和主表字段能对上，否则筛选条件永远为空，弹窗拉全量数据。接口是别人写的，参数名叫deptId还是department_id只能去对，对不上就在数据接口里加一层参数映射，别指望平台猜。
2.4 两类事件脚本和两个保命开关
控件级事件有两个触发点：发生变化时触发、失去焦点时触发。表单级事件有三个：表单加载触发、提交前置触发、提交后置触发。都是点开事件在代码区写 JavaScript，手册没限定具体 API，实际写法要按平台暴露的控件取值/赋值方法来。结构上大致是这种形态：
// 下拉选择控件：发生变化时触发 // v 为当前控件的选中值，取值与赋值方法按平台控件 API 调整 if (v === 'a') { setValue('fieldA', 1); // 选中 a，给 A 控件赋 1 } else if (v === 'b') { setValue('fieldB', 2); // 选中 b，给 B 控件赋 2 } else if (v === 'c') { hide('fieldC'); // 选中 c，隐藏 C 控件 } else if (v === 'd') { setRequired('fieldD', true); // 选中 d，把 D 控件设为必填 }这段逻辑适合放在“发生变化时触发”里，因为隐藏和必填是即时反馈；如果放在“失去焦点时触发”，用户点了下拉但没离开输入框，规则不会生效，看起来就像配置没保存。反过来，需要等用户把一整段内容填完再算的场景（比如根据身份证号算出生日期），就适合放失焦触发，避免每敲一个字符算一次。
表单属性里有两个开关值得单独拎出来：
- 主键策略：雪花 ID 或自增长 ID。流程保存后不可修改，这句话是硬约束，选之前想清楚。雪花 ID 适合多实例部署或者将来要合库的场景，自增长读起来顺眼、排序直观，但并库时容易撞。
- 并发锁定：打开后，并发提交表单会加乐观锁，保证数据提交的准确性。多人同时编辑同一张单据的场景，不开这个开关，后提交的会覆盖先提交的，而且日志里看不出来谁覆盖了谁。
组件样式里还有“多端显示”，桌面端和移动端各一个勾选框。默认都勾上，不勾的那一端这个控件就不渲染。移动端表单字段多的时候，把内部备注、审批意见这类字段在移动端关掉，是成本最低的减负手段。
3. 流程、权限与运维：V3.4.2 新增能力的落地姿势
3.1 流程设计三段式与 V3.4.2 补上的六个能力
工作流程下的流程设计分成三段：基础信息、表单设计、流程设计。前两段跟在线开发里的表单配置几乎一样，区别在于基础信息里多了流程归属和发起权限相关的项；真正拉开差距的是第三段流程图。
从修订记录能看出来，这个产品的迭代重心一直在流程侧：V3.3.1 加了审批设置候选人、保存草稿、节点事件、子表合计、审批汇总、流程评论、子流程同步/异步，V3.3.3 加了流程批量审批、弹窗选择属性、必填设置，到 V3.4.2 又是六个新能力。按落地价值排一下：
| 能力 | 解决什么问题 | 配置位置 |
|---|---|---|
| 超时提醒 | 节点卡住没人处理，靠人去催 | 节点属性里的超时规则 |
| 异常处理 | 节点报错导致整条流程停摆 | 节点事件或异常分支 |
| 自动同意 | 免审节点（如金额低于阈值）不必人工点 | 节点审批策略 |
| 节点变更 | 流程跑到一半，审批人离职或换岗 | 流程监控里的节点变更 |
| 流程复活 | 流程被误终止或异常中断，需要捞回来 | 流程监控 |
| 子表传递 | 子表数据要带到下一个节点或子流程 | 节点与表单的字段传递配置 |
自动同意是这里面最容易被滥用的一个。把阈值配得太宽，等于把审批环节架空，出了事没人担责；配得太窄又没意义。我的经验是只给“金额低于某个确定阈值”和“同一部门内部流转”这两类场景开自动同意，其余一律走人工，宁可多一次点击。
节点变更和流程复活是运维视角的功能，不在流程设计页，在流程监控里。这两个能力上线前一定要摸清楚入口在哪，因为出事的时候通常是业务方直接找到你，说某条单据卡了三天，你再去翻手册就晚了。
子流程还分同步和异步。同步子流程挂起等结果，父流程的状态依赖子流程；异步子流程发出去就往下走。单据量大、子流程里又有外部接口调用的，走异步，否则接口一抖动，父流程全堵在那儿。
3.2 权限的四层：从分级管理到数据权限
系统权限这一章有八个小节，看着杂，其实是一个四层结构：
第一层是组织维度。分级管理（新建、编辑、删除）、组织管理、岗位管理、分组管理，配合用户管理里的新建、重置密码、解除锁定、导入导出，把人先归好位。多组织的场景，分级管理决定了哪些管理员能管哪些组织，这层没配好，后面角色配得再细也没用。
第二层是角色。角色管理建角色，角色成员挂人，角色权限挂菜单。这里常见的误解是把角色当组织用，一个部门建一个角色，人一调岗就全乱。
第三层是菜单权限，系统菜单里拆得很细：按钮权限、列表权限、表单权限，加上导入导出。按钮权限决定看得见哪些操作，列表权限决定列表里显示哪些列、能查哪些字段，表单权限决定表单里哪些字段可见可编辑。这三层是逐级收窄的关系，按钮给了但列表权限没给，进去就是空页面。
第四层是数据权限，也是唯一涉及“看到哪些行”的一层。子表字段权限要单独配，表单权限配了主表字段不代表子表字段跟着走。V3.4.1 的修订里专门提了“子表字段权限配置”，说明这块早期是缺失的，用老版本升级上来的人要重新过一遍。
系统菜单里还有“子系统”的概念，一个平台跑多套业务入口时用。菜单配了但用户看不到，先查三处：角色权限挂没挂、子系统归属对不对、按钮权限和列表权限是不是只给了一半。
3.3 系统配置与调度：上线前必改的那几项
系统配置分四块：基础设置、安全设置、第三方设置、超级管理员。
安全设置是上线前必须动的，图形验证、登录方式、锁定账户策略都在这里。锁定账户不配，等于给撞库留门；登录方式不收敛，测试账号能一路带到生产。第三方设置用于对接外部服务，短信、消息通道一般从这里进。
系统调度管定时任务，V3.3.3 补了“内部方法类型”，意味着任务来源不只有外部接口，还能直接调平台内部方法。调度的排查依赖系统日志，日志里 V3.3.3 之后增加了操作日志，谁在什么时候改了什么配置能追。
系统缓存、系统监控、系统图标是三个低频但救命的入口。缓存用于清配置类脏数据，监控看运行状态，图标库决定菜单和按钮的视觉一致性——图标这事看着小，几十个菜单图标风格不统一，交付给业务方时观感很差。
3.4 流程监控与日志：出事之后从哪查
工作流程下的六个日常入口：我发起的、待办事宜、已办事宜、抄送事宜、流程委托、流程监控。前四个是使用者视角，流程委托解决请假期间的审批断档，流程监控是管理员视角。
排查一条卡住的流程，顺序建议是：流程监控里按单号搜，看当前停在哪个节点、审批人是谁、节点状态是什么；节点有超时提醒配置的，看提醒有没有发出去；发不出去就往消息模板和系统调度查；调度正常但日志没记录，再看接口认证和第三方配置。
系统日志和系统监控要配合着看。日志给的是“发生了什么”，监控给的是“当时系统什么状态”。一条流程在凌晨两点卡住，日志显示节点事件执行失败，监控显示那个时间点内存飙高，两下一对，结论就是事件脚本里有个全表查询。这种串查习惯，比记住每个菜单在哪有用得多。
4. 数据应用到大屏：数据连接、接口认证、数据源三件套
4.1 数据连接与数据建模：先有模型再有界面
数据应用下有七个子项：数据连接、数据建模、数据字典、数据接口、接口认证、数据同步、行政区划。前三个是地基。
数据连接管的是连哪个库；数据建模管的是在这个库上建哪些表、字段怎么定义；数据字典管的是枚举值——性别、状态、类型这类固定选项，统一放字典里，表单里的下拉控件直接引，别在每个表单里手工敲一遍。手工敲的下场是同一个“状态”字段，A 表单写“已审核”，B 表单写“审核通过”，报表一汇总就变成四类。
建表顺序上有讲究：先在数据建模里把表建好、字段类型定好，再回到在线开发里绑定。反过来做，自动建表建出来的结构不受数据建模管控，后面做报表取数时字段类型对不上，算出来的合计带小数点错位。
数据字典还有一个隐性用途：数据权限里按字典值做行级过滤。字典不统一，数据权限就配不出一致的规则。
4.2 数据接口与接口认证：给外部系统留的那扇门
数据接口负责把平台内的数据以接口形式暴露出去，接口认证负责给这扇门加锁。两个是配套的，只配接口不配认证，等于把数据库挂在公网上。
接口认证的常见做法是 appId + appSecret 换取令牌，请求时带在 header 里。下面这段是结构示意，参数名按实际配置替换：
# 1. 取令牌：appId / appSecret 来自「接口认证」里创建的应用 curl -X POST 'https://<platform-host>/api/auth/token' \ -H 'Content-Type: application/json' \ -d '{"appId":"your-app-id","appSecret":"your-app-secret"}' # 2. 调业务接口：把上一步返回的 token 放进 header curl -X GET 'https://<platform-host>/api/data/order/list?pageNo=1&pageSize=50' \ -H 'Authorization: Bearer <token>' \ -H 'Content-Type: application/json'第一段是换令牌，appId和appSecret在接口认证页面生成，生成后 secret 通常只显示一次，要立刻存进配置中心。第二段是带令牌调接口，pageNo、pageSize这类分页参数按接口定义传，返回值结构跟 4.2 节里数据接口的返回体一致，code、data两层。
坑集中在两点：一是令牌有效期，长连接批处理任务跑到一半令牌过期，报 401，日志里看不出是过期还是权限不足，得靠返回体里的错误码区分；二是接口权限和数据权限是两套，接口认证过了不代表能取到全部数据，取数范围还受接口绑定用户的角色权限约束。
数据同步用于表级或库级的数据搬运，行政区划是内置的省市区数据源，做地址选择控件时直接引用，不要自己维护一张地区表。
4.3 大屏的四个管理对象
大屏设计拆成四块：大屏管理、地图管理、分类管理、数据源管理。
数据源管理是大屏的地基，决定大屏上每个图表的数据从哪来——可以是数据接口、可以是数据建模里的表、也可以是数据同步过来的结果集。分类管理负责大屏的分组，几十张屏不分分类，找起来就是灾难。地图管理单独拎出来是因为地图类组件的数据结构跟普通图表不一样，需要有对应的地理层级配置。大屏管理是新建和编排入口。
做第一张大屏的顺序建议是：数据源 → 分类 → 大屏 → 地图。数据源没通就拉组件，最后全是假数据，改起来要一个个组件重配。
4.4 门户、报表与扩展示例：拿来当参照物
门户设计只有新建和结果展示两节，配置本身不复杂，难的是门户的权限归属——门户挂哪些菜单、给哪些角色看，最终还是要回到系统菜单和角色权限里配。
报表设计在手册里占了独立一章，核心是把数据建模里的表和数据接口的返回结果做成可查询、可导出的表格。报表的性能问题基本都出在数据源侧，百万级数据在扩展应用里有专门的示例（6.8 百万数据），做报表前先去看那一节，能省掉很多“为什么查一页要十秒”的困惑。
扩展应用那一章是最容易被跳过、实际最该先翻的部分。功能示例、门户示例、报表示例、大屏示例、图表示例、表格示例、表单示例，全是现成的参照物；导入导出、电子签名、电子签章、日程安排、邮件收发、知识管理、文档预览、条码示例、打印示例、地图示例、订单示例、订单管理、项目管理，覆盖了大部分通用业务场景。接手项目第一周，我会把这二十几个示例挨个点一遍，比通读前面两百页快得多——因为你看到的是跑起来的样子，而不是配置项的名字。
5. 踩坑与排查：九个翻车现场和对应的解法
5.1 表单与数据层的五个坑
坑一：自动建表之后想改表名。现象是功能已经上线，业务方要求表名带业务前缀方便 DBA 管理。原因是数据连接留空时，表名由平台按mt+功能ID、ct+雪花ID生成，不受人工控制。解决只有一条路：在数据建模里建目标表，新建一个功能绑定这张表，把原表单的控件重新映射一遍，老数据用数据同步搬过去。所以建功能前先问一句“这表将来归谁管”。
坑二：主键策略选错。现象是单据列表按创建时间排序正常，按单号排序乱跳。原因是选了雪花 ID，单号是长整型字符串，字典序和生成顺序不一致。手册写得很明确，主键策略流程保存后不可修改，改不了就只能重建。自增长适合单库单实例，雪花适合多实例和将来合库，选之前把部署形态定下来。
坑三：子表控件拖不进内容。现象是把输入框往子表区域拖，松手后控件跑到主表位置或者直接消失。原因是没有先在右侧属性里关联子表，空容器不接收控件。正确顺序是拖设计子表控件 → 关联子表 → 再拖内部控件 → 每个控件关联子表字段，四步一步都不能跳。
坑四：多表设计数据只进主表。现象是流程发起成功，主表有数据，子表是空的。原因是基础设置里选了两张以上表，但没有配子表的外键字段和关联主键。单表不需要这步，多表必须配，而且外键字段要真实存在于子表结构里。
坑五：并发提交出现重复单据。现象是两个用户同时点提交，生成两条一模一样的记录，日志里看不出异常。原因是表单属性里的并发锁定没开。这个开关默认不开，多人协作的单据类表单建议一律打开，代价是冲突时会提示重试，比产生脏数据好处理。
5.2 流程与权限层的四个坑
坑六：菜单配好了，用户进去是空白。现象是管理员账号能看到全部菜单，业务账号只看到框架。原因通常是三处之一：角色权限没挂这个菜单、子系统归属没选、列表权限和按钮权限只配了一半。排查顺序按这三条走，先看角色权限页签里菜单树勾没勾，再看菜单本身属于哪个子系统，最后进列表权限确认字段可见。
坑七：数据权限配了还是串数据。现象是 A 部门的人能看到 B 部门的单据。原因是数据权限和分级管理是两套作用域，分级管理决定管理员能管哪些组织，数据权限决定普通用户能看到哪些行，只配后者不配前者，或者配了数据权限但子表字段权限没同步配，都会漏。子表字段权限要单独进表单权限里过一遍。
坑八：流程改完节点，在途单据全卡住。现象是流程设计里删了一个审批节点，之前跑到这个节点的单据全部停在原地。原因是流程图变更不会自动迁移在途实例。解法是用流程监控里的节点变更把在途单据指向新节点，异常中断的用流程复活捞回来。所以流程图变更尽量安排在业务低峰，变更前先在监控里筛一遍在途单据量。
坑九：定时任务静默失败。现象是每天的汇总数据没生成，页面上没有任何提示。原因是系统调度里的任务失败不弹窗，只写日志。排查路径是系统调度看任务状态 → 系统日志筛操作日志和异常日志 → 系统监控看执行时段的资源曲线。V3.3.3 之后调度支持内部方法类型，方法名写错也会静默失败，配完任务手动执行一次是必须动作。
6. 上线自检：三张清单加一条校验 SQL
交付前我会固定跑一遍自检，不跳步。第一张是结构清单：数据建模里的表和功能设计里绑定的表是否一一对应，多表功能的外键和关联主键是否都配了，子表合计字段的类型是否落在单行输入、数字输入、计算公式这三类里。第二张是权限清单：分级管理 → 组织岗位 → 角色成员 → 菜单权限（按钮、列表、表单、子表字段）→ 数据权限，五层逐层用一个测试账号走一遍，只配不看等于没配。第三张是流程清单：自动同意的阈值复核一遍，超时提醒的接收人确认不是离职账号，流程委托在节假日前提早设置，节点变更和流程复活的入口位置写进交接文档。
结构这块，一条 SQL 能把大部分低级问题筛出来——检查子表里有没有孤儿数据：
-- 检查子表孤儿记录：子表存在但主表已不存在 -- mt_xxx / ct_xxx 按实际表名替换，fk_main_id 为配置的外键字段 SELECT c.* FROM ct_xxxxxx c LEFT JOIN mt_xxxxxx m ON c.fk_main_id = m.id WHERE m.id IS NULL LIMIT 100;返回非空就说明外键关联配错了，或者流程中途改过表结构。这条 SQL 我一般在上线前和生产发布后各跑一次，比等业务方反馈“数据对不上”快得多。参数上只改两个表名和一个外键字段名，LIMIT 100是防止大表全扫，确认有问题再去掉。
还有一个小技巧：移动端和桌面端的控件显隐是分开勾的，自检时拿手机真机过一遍表单，比在浏览器里缩窗口靠谱。曾经有个单据在桌面端正常，移动端因为某个必填字段被隐藏了，提交按钮一直是灰的，测试环境谁都没发现——因为大家都是用电脑点的。从那以后我每次发版前都强制走一遍真机自检，桌面端、移动端、大屏三端各点一遍，再急也不省这一步。希望帮到你。
本文还有配套的精品资源，点击获取
