企业官网建设流程全解析

简介：面向JNPF软件开发平台开发者、实施人员与系统管理员的V3.4.2版操作手册PDF，围绕低代码平台的在线开发、门户与大屏设计、代码生成及系统管理展开，适合需要快速上手项目搭建、功能配置与后台运维的初中级用户查阅。压缩包内共1个PDF文件，大小约40.01MB，内容以图文步骤和功能目录组织，便于按模块检索。手册系统梳理功能设计中的表单、列表、流程与结果展示，门户新建与展示，大屏管理、地图、分类与数据源管理，以及报表设计、功能表单和流程表单的代码生成路径；系统管理部分覆盖基础设置、安全设置、第三方设置、超级管理员、系统公告、消息中心、系统调度、缓存、日志、监控、图标与菜单权限等内容，可帮助读者理解平台能力边界并对照完成配置。目前已有1343人学习下载，适合作为平台实施与日常运维的案头参考。

1. 一份两百多页的操作手册，抵得上半个实施顾问

接手一套低代码开发平台，最先卡住人的往往不是代码，而是不知道某个开关藏在第几层菜单里。这份 V3.4.2 的操作手册按 1.1.1、3.10.2 这样的编号一路排到第六级，把在线开发、代码生成、系统管理、系统权限、工作流程、扩展应用六块讲到底——表单设计拖哪个控件、流程设计挂哪个节点、数据权限勾到哪一层，都能按图索骥。

它不教 Java 语法，讲的是"配什么"和"配在哪"。适合两类人：一类是两周内要交付一套内部管理系统的开发者，照着目录抄作业就能跑通主流程；另一类是已经拿到平台环境、准备二次开发但摸不清配置与代码边界的熟手，更需要看懂点下去的每个开关最终落到哪张表、哪个接口。下面按骨架、在线开发、代码生成与数据应用、踩坑、改造五段拆。

2. 平台骨架：从手册目录反推分层与数据落点

2.1 六个一级章节对应六层能力

手册的目录结构基本就是这套平台的架构图，只是它用功能名而不是技术名写的。把六个一级章节翻译一下：

这六层里，1 和 2 是"生产"，3 和 4 是"底座"，5 是"流转"，6 是"示例与插件"。理解了这层分工，遇到问题时定位会快很多：表单渲染不对往第 1 章翻，登录进不去往第 3 章翻，流程卡住往第 5 章翻，别看错章节浪费半天。

有个容易被忽略的点：手册把"数据应用"（3.10）放在系统管理里，而不是放在在线开发里。这说明平台把数据连接、数据建模、数据字典、数据接口当成基础设施，而不是表单的附属品。二次开发时这条线索很重要——先有数据建模，再有表单绑定，顺序反了会一路别扭。

2.2 一张表单到底落在哪张表

在线开发最核心的一句话藏在 1.1.1 里：未设置数据连接时，流程新建完成后会自动建表，主表以mt+功能ID命名，子表以ct+雪花ID命名。这句决定了后面所有排查的起点。

常见做法是每张业务表带一套平台字段：主键、创建人、创建时间、更新时间、租户或组织标识，开了并发锁定再加一个版本号。所以自动建出来的表大概长这样：

-- 平台按表单定义自动生成的主表结构（字段名由控件字段推导） CREATE TABLE `mt_10086` ( `id` varchar(32) NOT NULL COMMENT '主键，按表单属性里的主键策略生成', `bill_no` varchar(64) DEFAULT NULL COMMENT '单据编号，单行输入控件', `apply_amount` decimal(18,2) DEFAULT NULL COMMENT '申请金额，数字控件', `apply_reason` varchar(500) DEFAULT NULL COMMENT '申请事由，多行文本', `create_user` varchar(32) DEFAULT NULL COMMENT '创建人', `create_time` datetime DEFAULT NULL COMMENT '创建时间', `version` int DEFAULT 0 COMMENT '并发锁定开启后启用，乐观锁版本号', PRIMARY KEY (`id`), KEY `idx_bill_no` (`bill_no`) ) COMMENT='费用申请主表';

几个参数值得单独说。主键策略在表单属性里选，雪花 ID 或自增长 ID，手册明确写了"流程保存后不可修改"——这条不是随口一提，因为主键策略一变，已生成的表和历史数据全对不上，平台索性锁死。并发锁定对应version字段，开了之后并发提交走乐观锁，两个人同时点保存，后提交的那个会拿到版本冲突提示而不是静默覆盖。做审批类业务时我一般默认打开，代价只是多一个字段。

子表的命名用雪花 ID 而不是功能 ID，是为了支持一张表单挂多张子表——两个子表如果都叫ct_功能ID就撞名了。这也解释了为什么手册里说子表要"在基础设置中添加"之后才能在表单设计里关联：表是先建好的，设计器只是把控件绑到已存在的列上。

2.3 权限的五道闸门

第 4 章加上 3.8 的菜单权限，实际构成了五层控制，很多人只配了第一层就以为完事：

菜单权限决定左侧导航看不看得见；列表权限决定进页面后哪些列出现在表格里；表单权限决定打开详情时哪些字段可读可写；按钮权限决定新建、删除、导出这些动作按钮存不存在；数据权限决定同一个列表里能查到谁的数据（本部门、本部门及下级、自定义、仅本人）。再加上 4.1 的分级管理，多组织场景下每一级管理员只能管自己那一摊。

这五层是叠加关系，不是替代关系。只配菜单不配按钮，用户能进页面但点不动；只配按钮不配数据，能点但查出来是空列表；只配数据不配表单，能查出记录但字段全是灰的。配置顺序我习惯从下往上：先数据权限定型，再列表和表单，最后菜单和按钮，这样每加一层都能立刻验证。

3. 在线开发：表单、列表、流程三条主线怎么串起来

3.1 表单设计：控件、字段、副表与子表的绑定关系

手册 1.1.1 把表单设计拆成"基础设置 → 表单设计"两步，这个顺序不能颠倒。基础设置阶段定的是数据落点——用自动建表还是绑已有表，用单表还是多表。绑已有表时从数据建模里选，多表场景要配子表外键和主键的关联关系，这一步配错，后面子表数据永远填不进去。

进入设计器后，左中右三栏：左侧控件区（基础控件、高级控件、系统控件），中间画布，右侧属性区。每个控件要绑一个"控件字段"，这个字段就是数据库列名。字段下拉里支持快捷新建，新建时会弹字段设置窗口，已有字段灰掉不可改，只能新增空白行补定义。

副表和子表的区别新手经常搞混。副表是"另一张主表"，一对一或一对多但结构上平级，选中普通控件后在右侧数据库表里关联副表即可；子表是"表格形态的从表"，必须先拖一个"设计子表"控件，在属性里关联基础设置里添加的子表，然后才能往里拖其他控件。顺序错了会发现控件拖不进去——不是 bug，是设计器在拦你。

组件样式里有个"多端显示"，桌面端和移动端各勾一次。默认全选，取消勾选就在那一端不渲染。这个开关比想象中实用：PC 上有地方放 20 个字段，手机上塞不下，直接在样式里砍掉次要字段，比拼响应式布局省事。

3.2 子表合计与动作设置：两个被低估的能力

子表属性里有两个开关，手册写得简略，实际很能省事。

"合计设置"开启后，使用时会子表下方出现合计栏，可选多个字段求和，字段来源限定在单行输入、数字输入、计算公式三种类型。别小看这个限制——文本字段求和无意义，日期字段求和更无意义，平台直接不给你选，反而避免了配错。

"动作设置"是子表传递，配置链路是：先配表单，弹窗标题、弹窗类型（居中/右侧）、弹窗宽度；再选远端数据联动，从数据接口里挑一个；接口带回来的参数会自动列到参数设置区，把它们映射到主表字段当前值，作为查询条件传过去；然后在设置列表字段里定义弹窗展示哪些列，在设置关联字段里定义选中后回填到子表的映射规则，来源支持接口字段和固定值。

这套机制本质是"带条件的选单 + 回填"，常见用途是选商品、选人员、选科目。踩过的坑是接口参数映射反了：把子表字段映射成接口入参，结果永远查不到数据。记住方向——主表字段是输入（筛选条件），接口字段是输出（候选列表），子表字段是落点（回填目标）。

3.3 列表设计：桌面端和移动端分开配

新建功能时选"列表"类型，会比纯表单多一步列表设计，基础设置和表单设计部分完全复用。

列表设计里三块要重点配：列表字段（表格显示哪些列、列宽、排序、是否支持行内编辑）、查询字段（顶部筛选区放哪些条件）、高级查询（多条件组合）。V3.4.2 新增的行内编辑和高级查询就是补这块短板——以前改一个字段要打开详情页，现在列表上直接改，适合批量维护场景。

桌面端和移动端是两个独立的 Tab，配完 PC 要切到移动端再配一遍。这点和表单的多端显示不同：表单是同一个定义控制显示与否，列表是两套配置。所以列表字段增减时别只改一边，我见过上线后移动端列表还挂着七八个用不上的列，横向滚动条拉半天。

3.4 流程设计：节点、事件与超时兜底

第 5 章的流程设计是整份手册最厚的一块，1.1.3 和 5.1.3 两处都在讲。流程设计表单分三块：基础信息（流程名称、所属分类、绑定表单）、表单设计（流程专用的表单，和功能表单可以不同）、流程设计（画布）。

画布上能配的东西按手册的更新记录看，V3.4.2 这一年补了不少应急能力：

"流程复活"这个功能争议最大，但从运维角度看很必要——流程走完了才发现数据填错，没有复活就只能删单据重来，历史记录全丢。开这个功能同时要在流程监控里限权，不然就是给所有人开了后悔药。

3.5 脚本事件：不改后端也能塞逻辑

这是在线开发里最像"写代码"的部分。手册给了两类事件：控件事件（发生变化时触发、失去焦点时触发）和表单事件（加载触发、提交前置触发、提交后置触发），都支持 JavaScript。

控件事件的典型用法是按选中值驱动其他控件。手册里的例子是下拉选 a 就把 a 字段赋值 1，选 c 就隐藏 c 控件，选 d 就置为必填。写法大致是这样：

// 下拉选择控件的 change 事件：按选中值驱动同表单内其他控件 // 平台内置 jQuery，$ 可直接使用；控件以字段名作为选择器标识 // 不同小版本的 API 名可能略有差异，以实际环境为准 var val = this.value; switch (val) { case 'a': $('#aField').val(1); // 直接赋值 break; case 'b': $('#bField').val(2); break; case 'c': $('#cField').hide(); // 隐藏，但值仍会随表单提交 break; case 'd': $('#dField').attr('data-required', true); // 置为必填，触发前端校验 break; default: $('#aField').val(''); // 兜底清空，避免上一次的选择残留 break; }

这段的关键不在语法，在最后那个 default 分支。切换选项时如果不主动清理，上一次赋值会一直挂在字段上，提交上去就是脏数据，排查时看日志完全看不出问题——这就是典型的玄学 bug，加个 default 就没了。

表单事件更适合做提交前校验。提交前置触发里可以拦下不合规的数据：

// 表单提交前置事件：金额超过阈值必须填事由 var amount = parseFloat($('#applyAmount').val() || 0); var reason = $('#applyReason').val(); if (amount > 50000 && (!reason || reason.trim().length < 10)) { // 返回 false 阻断提交，平台会弹出提示 alert('金额超过 5 万时，申请事由不少于 10 个字'); return false; } return true;

参数说明：applyAmount、applyReason是控件字段名，必须和表单设计里绑定的字段完全一致，大小写敏感；返回值false阻断提交，true放行。这类校验放在前置事件里比放在流程节点里合适——数据在入库前就被拦住，不会留下半截单据。

4. 代码生成与数据应用：把拖拽出来的东西变成可维护资产

4.1 代码生成：功能表单和流程表单差在哪

第 2 章的代码生成分成"功能表单"和"流程表单"两个入口，走完表单、列表、流程、结果展示四步。区别在于生成物：

功能表单生成的是标准 CRUD——列表页、新增页、编辑页、详情页，加后端 Controller/Service/Mapper/Entity。流程表单生成的是带审批流的版本，会额外产出流程相关的方法和页面（提交、审批、撤回、查看审批记录）。

生成的代码类型映射大致是这样，实际项目里我一般会先看一眼生成的 Entity 再动业务逻辑：

// 代码生成器按表单定义输出的实体（常见做法是 MyBatis-Plus 风格） // 字段名与控件字段一一对应，类型按控件类型推导 @Data @TableName("mt_10086") public class ApplyFormEntity { @TableId(value = "id", type = IdType.ASSIGN_ID) // 雪花ID，对应主键策略配置 private String id; @TableField("apply_amount") private BigDecimal applyAmount; // 数字控件 → BigDecimal @TableField("apply_reason") private String applyReason; // 多行文本 → String @Version // 仅当开启并发锁定时生成 private Integer version; }

注意@Version这一行是条件生成的——表单属性里不勾并发锁定，生成器就不会加。这也是为什么改完表单配置要重新生成或手动同步，配置和代码之间是快照关系，不是实时映射。手册在 V3.4.1 的修订记录里提到"同步菜单"，说的就是这个同步动作。

生成的代码别急着大改。我的习惯是：生成完先跑一遍，把列表、新增、编辑、详情四条路径走通，确认字段映射和时间字段格式都对，再在 Service 层加业务方法。直接上手改 Controller 的人，后面表单字段一调整就全乱。

4.2 数据建模与数据字典：先把字段口径钉死

3.10 这一节被很多人跳过，其实它是整个平台的底座。四个组件的关系是：

数据连接管"连哪个库"，配置好之后表单才能绑已有表而不是自动建表；数据建模管"表长什么样"，可以从已有表反向导入，也可以正向定义，建完之后在表单基础设置里能选到；数据字典管"枚举值是什么"，性别、状态、类型这些固定选项统一在这里维护，表单里的下拉、单选绑字典而不是手填；数据接口管"怎么把数据吐出去"，给子表弹窗、大屏、外部系统用。

字典这层最值得先做。同一个"状态"字段，A 表单手填 0/1/2，B 表单绑字典，后面做报表统计时前者要写 case when，后者直接 group by。一百张表单里只要有二十张手填枚举，数据治理就废了。

4.3 数据接口与接口认证：对外开放的那道门

3.10.4 的数据接口负责定义出参入参，3.10.5 的接口认证负责发凭证。这两个要一起配，只配接口不配认证等于裸奔。

常见做法是给调用方发一对 appKey/appSecret，请求时带时间戳和签名，服务端按同样规则算一遍比对。写个 Python 调用脚本方便联调：

import time, hashlib, hmac, requests APP_KEY = "your_app_key" APP_SECRET = "your_app_secret" BASE_URL = "http://127.0.0.1:8080/api/data/orderList" def build_sign(params: dict) -> str: """按参数名升序拼接后做 HMAC-SHA256，避免参数顺序不同导致签名不一致""" raw = "&".join(f"{k}={params[k]}" for k in sorted(params)) return hmac.new(APP_SECRET.encode(), raw.encode(), hashlib.sha256).hexdigest() params = { "appKey": APP_KEY, "timestamp": int(time.time() * 1000), # 毫秒，服务端一般允许 5 分钟偏差 "pageNo": 1, "pageSize": 50, } params["sign"] = build_sign(params) resp = requests.get(BASE_URL, params=params, timeout=10) print(resp.status_code, resp.json())

参数上三个细节：timestamp用毫秒且服务端要校验时间窗，防重放；sign计算时要把 sign 自己排除在外，否则永远对不上；sorted排序是为了让两端拼接顺序一致，这一步错了症状是"本地算得对，对方验不过"，很费时间。接口认证这块手册里还有 token 有效期和调用频次限制，联调阶段可以先放宽，上线前收回来。

4.4 数据同步与系统调度：定时任务落在哪

3.10.6 的数据同步负责表到表、库到库的搬运，3.3 的系统调度负责定时触发。两者组合起来就是一套轻量 ETL：调度按 cron 拉起同步任务，任务按配置的映射关系抽数、转换、写入。

系统调度里有个"内部方法类型"，指的是不走 HTTP 而直接调平台内的 Bean 方法。这个设计对性能友好——百万数据（6.8 有专门示例）批量处理时，走接口一层层序列化开销太大，直接调内部方法快得多。

调度任务上线前一定要在测试环境跑一次全量，再跑一次增量。我见过只测了增量、上线首日全量把库压垮的。

5. 避坑与排查：五条上线前必须过的检查

手册是按功能点写的，缺点是不会告诉你"这么配会出事"。这一章是纯经验，五条都踩过。

5.1 现象：流程改了节点，线上还是老样子

原因：流程定义有版本概念，设计器保存的是新版本，但已发起的流程实例仍绑定旧版本。手册在流程设计里提到"保存草稿""节点变更"，但没把版本这条讲透。

解决：先在流程监控里确认实例绑定的版本号；新建流程测试是否生效；如果只是个别实例要改，用节点变更而不是改定义；确实要全量生效，得让在途流程走完或由管理员做流程迁移。这条血泪经验的结论就一句——改流程定义前先看有没有在途实例。

5.2 现象：子表数据保存了，详情页打开是空的

原因：三种可能，按概率排——子表外键字段没绑对；主表主键策略是自增长但子表关联用的是雪花 ID；表单设计里子表控件的关联在基础设置改过之后失效了。

解决：直接连库看两张表的数据，主表有记录而子表没有，说明是保存时就没写进去，回基础设置查外键配置；两张表都有数据但页面空，说明是查询时关联字段对不上。手册里"选择多表时需配置子表的外键字段和关联主键"这句话看着简单，实际操作中改过一次表结构就要重配一次，别忘了。

5.3 现象：移动端打开功能页面一片空白

原因：列表设计和表单设计都是桌面端、移动端分别配的。桌面端配完了没切 Tab 配移动端，移动端拿到的就是空配置。另一个可能是控件样式里的"多端显示"把关键控件取消了勾选。

解决：先把列表设计切到移动端 Tab，检查字段和查询条件是否为空；再挨个看关键控件的多端显示。手册 1.1.1 的第 5 点写得很清楚，默认全选，取消即不展示，但配的时候人在桌面端 Tab，很容易忘记。

5.4 现象：调数据接口一直 401 或签名失败

原因：签名串拼接顺序不一致；时间戳单位搞错（秒 vs 毫秒）；Secret 末尾有空格；或者接口认证里配的 IP 白名单没加调用方。

解决：让服务端把收到的原始串和本地算的串打日志对比，一眼就能看出差在哪；时间戳统一用毫秒并在服务端放宽到 5 分钟；Secret 复制后 trim 一次。这条排查顺序别反，先看原始串再看密钥，八成的签名问题在拼接。

5.5 现象：数据权限明明配了"仅本人"，还是能看到别人的单据

原因：数据权限和列表权限是两套东西，前者管数据范围，后者管列显示。配了列表权限不等于限制了数据。另一种情况是分级管理没配对，上级组织的管理员天然能看下级数据。

解决：在角色的权限配置里逐项核对数据权限规则，别只看菜单树打了几个勾；用不同组织的账号实际登录验一遍，配置界面看着对不代表运行时对。手册把权限拆成菜单、按钮、列表、表单、数据五处，就是为了让人分开配，但分开配的代价就是容易漏。

6. 二次开发：从"照着手册配"到"按业务改"

配得再顺，最后总要落到改代码。我的改造路径一般是三步，顺序别乱。

第一步，先用在线开发把业务流程跑通，哪怕字段不全、样式很丑。目的是让表单定义、数据表、流程定义这些元数据先落到库里，生成器有东西可生成。空库直接改代码是本末倒置。

第二步，生成代码后只动 Service 层。Controller 负责参数接收和返回封装，Mapper 是生成的 SQL，这两层改动越少，后续表单字段调整时返工越小。业务校验、跨表取数、状态机推进，全塞 Service。下面这张表是我一般遵循的边界：

第三步，把高频配置沉淀成模板。同一类单据（申请、审批、归档）字段结构大同小异，与其每次从零拖控件，不如在系统模板（3.9）里先做好打印模板、单据模板、消息模板，新建时直接套。V3.4.2 新增的子系统、分级管理这些，本质也是让不同业务线复用同一套底座。

验证方法说一个具体的：每改完一轮，拿三个账号跑一遍——普通员工提交一单、部门主管审批一单、超管在流程监控里查一遍这条流程的完整轨迹。三个角色都通，说明表单权限、流程节点、数据权限没打架。只用一个管理员账号测，永远测不出权限问题。

以前我图快，改完 Service 直接在管理员账号上点两下就发版，结果上线第一天业务方反馈"审批按钮看不见"。查了半天是按钮权限配在角色上，而那个角色的成员里没有实际提交人。从那以后我每次发版前都强制走一遍三角色验证，多花十分钟，省掉一晚上的回滚。希望帮到你。

本文还有配套的精品资源，点击获取