简介：《0 代码，搭应用——宜搭开发手册》是一份面向业务人员、信息化负责人及低代码入门者的 PDF 实操手册，聚焦企业在应用搭建中遇到的开发成本高、系统流程脱节、信息孤岛与智能化程度不足等问题。全书围绕阿里巴巴宜搭平台展开，既介绍产品定位、页面设计、业务规则定义与数据收集分析等核心能力，也收录杭州市一医院、老板电器、居然之家、海纳威等落地案例，帮助读者理解零代码搭建的适用边界。教程部分从核心要素与快速入门讲起，并给出“T 恤尺码收集”“设备报修”“企业进销存”“报表分析”“定时消息通知”“企业报销流程”等实践范例，便于按场景对照配置思路。资源包共 1 个 PDF 文件，大小约 22.76MB，目录完整、查阅方便；目前已有 6793 人学习，适合希望以拖拽配置方式快速搭建业务应用、降低开发与沟通成本的读者参考。

1. 开篇：一份把“拖拽”讲成工程流程的手册

业务同事抱着一个 Excel 表来找你，说要个“设备报修登记”，最好还能看哪个车间报得多。你心里估了一下：列表、表单、统计三块，排期两周。这类需求每个季度都会冒出来一批，做完就沉底，后面还得有人维护。这份《0代码，搭应用——宜搭开发手册》讲的就是另一条路：这类东西交给业务侧自己拖拽配出来，开发只负责兜底和系统打通。宜搭是面向企业应用的 0 代码搭建平台，手册从产品定位讲到核心要素、快速入门、进阶教程，再落到 T 恤尺码收集、设备报修、进销存、报表分析、定时消息通知、企业报销流程六个实践案例，最后是注册入口。它适合两类人：想自己把部门系统搭起来的业务同学，和被零散需求磨得快没脾气的开发。

2. 平台骨架：页面、表单、流程、报表四件套怎么拼成一个应用

拿到一份 100 多页的产品手册，最容易犯的错是从第一页顺着读。读到“客户案例”那一章，满眼都是某三甲医院半个月做完内控升级、某家电制造企业把品质管理搬上线、某家居连锁企业改造 OA、某箱包代工厂覆盖上千个生产工站，读着很爽，合上手册还是不知道怎么下手。真正该先建立的是对象模型——你得知道自己在配的每一样东西，在系统里属于哪一层，改它会影响谁。

2.1 三大核心能力落到四层对象模型

手册把平台能力归纳成三条：页面设计、业务规则定义、数据收集与分析。这个说法站在产品视角没问题，但落到配置动作上，它其实是四层对象在互相咬合。

这四层里，数据层是根。表单一旦发布并被写入数据，字段的类型和标识就不好随便动了——报表数据集、流程条件表达式、消息模板变量全都挂在字段标识上。我见过太多人先画页面再想数据结构，画到一半发现“申请人”应该是个人员字段而不是文本框，回头一改，前面配的审批人规则全部要重选。常见做法是先在纸上把实体和字段列清楚：谁是主表、谁是从表、哪些字段是流程判断依据、哪些要进报表。这几件事定完，页面画起来很快。

平台还有几个不显眼但很吃重的特性，手册在“产品优势”里提过：一次搭建双端适配、权限独立设置、定制消息提醒、海量数据存储。前两个决定上线后能不能用，后两个决定用起来顺不顺。双端适配的意思是同一张表单在 PC 和移动端渲染两套布局，你不用写响应式，但得知道移动端列宽有限，一行塞四个字段在手机上必然挤成一坨。权限独立设置是另一件事——它跟流程里的审批人权限完全是两套东西，第 5 章会专门说这个坑。

2.2 手册的编排顺序，其实是一条能力依赖链

把目录摊开看，手册的结构很清楚：先讲平台定位和客户案例建立信任，再讲核心要素和快速入门，然后进阶教程，最后是六个实践。很多人以为实践部分是“例子”，其实它是能力递进——每一个案例都在补前一个案例没覆盖的能力。

# 手册结构拆解（按能力依赖排序，非页码顺序） 0-code-guide/ ├── intro/ # 平台定位：解决无系统支撑、信息孤岛、开发成本高 ├── tutorial/ │ ├── core-elements/ # 核心要素：表单、流程、页面、数据 │ ├── quick-start/ # 快速入门：建应用 → 建表单 → 发布 │ └── advanced/ # 进阶教程：公式、校验、联动、权限 ├── practice/ │ ├── 01-tshirt-size/ # 单表单 + 子表单 + 简单汇总 │ ├── 02-repair-ticket/ # 表单 + 单线流程 │ ├── 03-inventory/ # 多表单关联 + 出入库联动 │ ├── 04-report/ # 数据集 + 维度度量 + 图表 │ ├── 05-scheduled-msg/ # 定时触发器 + 消息模板 │ └── 06-reimburse/ # 多节点审批 + 条件分支 + 金额判断 └── signup/ # 注册入口与账号绑定

这个梯度不是随便排的。T 恤尺码收集解决“一张表怎么收数据”，一个人报多件就得用子表单；设备报修在表单上加了一层状态流转，让“待处理—处理中—已完成”有痕迹；企业进销存开始涉及多张表的关联和数量增减，这一步是很多人第一次翻车的地方——入库单和库存表之间没有自动扣减，得靠业务规则去串；报表分析把前面产生的数据变成图表，考验的是数据集怎么定义；定时消息通知引入了时间维度，让系统主动去找人；企业报销流程则把前面所有东西合起来，金额不同走不同分支，还要跟外部财务系统对接。

顺着这个顺序读，每读一个案例就问自己一句：这个案例新引入了哪个对象。答得出来，说明你在建模型，而不是在记操作步骤。

2.3 权限、消息、数据集：藏在案例背后的三个底座

手册的案例章节讲得最多的是“怎么配”，对权限、消息、数据集往往一笔带过。但真上线之后，问题大多出在这三块。

权限要分两个维度看。一个是功能权限，谁能打开哪个页面、谁能看到哪个菜单，这个在应用和页面设置里配。另一个是数据权限，同一条单据，发起人看到自己的，部门主管看到本部门的，财务看到全部。手册在“产品优势”里提到“权限独立设置”，说的就是这两套可以分开配。很多人只配了功能权限就发布，结果一线员工打开列表能看到全公司的报销单，这在真实场景里是事故。

消息这块，手册只在报销和报修案例里零星提到“审批通过后通知”，实际配置要细到：触发时机（提交时、节点到达时、流程结束时、定时）、接收对象（指定人员、表单里的人员字段、角色、部门主管）、通道（站内、企业协同办公套件、邮件）、模板变量（单据编号、申请人、金额、当前节点）。变量写错一个，通知发出去就是一串undefined，比不发还糟。

数据集是报表的地基。手册的报表分析案例里，图表是结果，数据集才是过程。数据集本质上是“对哪张表单、按什么条件筛、按什么维度分组、算什么指标”的一段定义。它跟你写 SQL 的思路一致，只是用界面拖出来。不理解数据集，报表就只能照抄案例，换个业务场景就懵。

3. 第一遍跑通：把“T恤尺码收集”从空白应用做到可提交

理论说完，动手跑一遍。选 T 恤尺码收集当第一个练习是对的——它只有一张主表加一个子表，没有流程，但把“字段类型怎么选、子表单怎么用、发布后怎么验证”这三件事全走了一遍。跑通这个，后面加流程只是往上叠。

3.1 建应用、选页面类型：先定结构再画界面

进入工作台新建应用，输入应用名，选归属组织。这一步有个细节：应用归属一旦确定，成员范围就跟着组织走，后面想换归属，得重建。所以别拿正式组织当试验田，新开一个测试用的组织或部门空间，用完删掉。

建完应用，第一个要做的决定是页面类型。

• 表单页：一张表单加一个列表，适合纯数据收集，比如尺码登记、问卷、报名。
• 流程页：表单加审批流，单据会带状态，适合报修、报销、采购申请。
• 自定义页：自由布局，可以放图表、卡片、跳转按钮，适合做门户首页或数据看板。

T 恤尺码收集用表单页就够了。判断标准很简单：这份数据需不需要“被审批”。不需要，就用表单页；需要有人点头才能往下走，就用流程页。手册的核心要素章节讲的其实就是这个判断，只是它没把话说到这么直白。

页面建好后，先别急着拖字段。打开表单设计器，把字段清单在脑子里过一遍：

# T恤尺码收集的字段清单（先想清楚再拖控件） 主表 ├── 姓名 人员字段（不要用文本框，人员字段能带出部门和工号） ├── 工号 单行文本，可设为自动带出 ├── 所属部门 部门字段 ├── 联系电话 单行文本 + 手机号正则校验 ├── 是否需要邮寄 单选（是/否） └── 邮寄地址 多行文本，仅在"需要邮寄=是"时显示 子表单（一人可报多件） ├── 款式 单选（圆领/翻领/V领） ├── 尺码 单选（S/M/L/XL/XXL） ├── 数量 数字，最小 1，最大 5 └── 备注 单行文本，非必填

这张清单里有三个决定值得说。“姓名”用人员字段而不是文本框，是因为人员字段自带组织信息，后面按部门统计的时候能直接用，不用再让用户手填一遍部门。“邮寄地址”要配显示联动，选“否”的时候藏起来，否则表单上一堆用不上的空框，填的人会烦。“数量”设上限 5，是业务约束，不设的话有人一次报 200 件，汇总数据直接失真。

3.2 表单设计器：字段类型、校验与子表单的选择

字段类型选错是最常见的返工原因。手册在快速入门里列了字段类型，但没讲什么场景该选哪个，这里补一张对照。

表单的底层配置大致是这么个结构，理解它有助于你知道改哪里：

{ "formId": "tshirt_collect", "title": "T恤尺码收集", "fields": [ { "key": "applicant", "label": "姓名", "type": "employee", "required": true, "props": { "showDept": true } }, { "key": "needMail", "label": "是否需要邮寄", "type": "radio", "options": [ { "label": "是", "value": "Y" }, { "label": "否", "value": "N" } ], "defaultValue": "N" }, { "key": "address", "label": "邮寄地址", "type": "textarea", "required": true, "visibleRule": { "field": "needMail", "operator": "eq", "value": "Y" } }, { "key": "items", "label": "申领明细", "type": "subform", "minRows": 1, "maxRows": 5, "children": [ { "key": "style", "label": "款式", "type": "select", "required": true }, { "key": "size", "label": "尺码", "type": "select", "required": true }, { "key": "qty", "label": "数量", "type": "number", "min": 1, "max": 5, "required": true } ] } ] }

几个参数值得单独拎出来说。visibleRule是显示联动，这里配的是“需要邮寄等于 Y 时地址才可见且必填”，注意必填和可见要一起配，只配可见不配必填，用户跳过地址也能提交。minRows和maxRows限制子表单行数，配合业务约束用，但别设太死，临时加一件就得改配置。type: "employee"和type: "text"的区别前面说过，能选结构化类型就别选文本。

子表单和关联表单是最容易搞混的两个东西。子表单是“附属于当前单据的明细行”，数据跟着主单一起存，删主单子表也没了；关联表单是“引用另一张独立表单的数据”，比如报销单关联发票台账。T 恤案例里一人报多件，用子表单；如果是要从物料库里选已有物料，才用关联表单。

校验规则除了必填和范围，还能写公式。比如“同一人同一款式同一尺码不允许重复行”，用子表单的去重校验；再比如“总数量不超过 5 件”，得写个汇总校验：

// 子表单汇总校验：所有明细行的数量之和不得超过 5 // 挂在子表单的 onChange 上，返回值非空即为错误提示 export function validateItems({ items }) { if (!Array.isArray(items) || items.length === 0) { return '请至少填写一条申领明细'; } const total = items.reduce((sum, row) => { // 数量可能为空串，先转数字，NaN 按 0 处理 const qty = Number(row.qty) || 0; return sum + qty; }, 0); if (total > 5) { return `申领总数量 ${total} 件，已超过上限 5 件`; } // 同一款式 + 尺码组合不允许重复 const seen = new Set(); for (const row of items) { const key = `${row.style}_${row.size}`; if (seen.has(key)) { return `款式「${row.style}」尺码「${row.size}」重复填写，请合并数量`; } seen.add(key); } return ''; }

这段逻辑有两个作用：一是兜住总量，二是拦重复行。Number(row.qty) || 0这个写法是为了兼容空值，因为用户点了新增行但没填数量时，qty是空串，直接相加会得到字符串拼接的结果，比如"12"，这是 JS 里血泪的经验，数字字段的原始值不一定是 number。返回空串表示校验通过，返回非空字符串会作为错误提示挂在字段上，具体行为以平台当前版本为准。

3.3 发布、双端适配与提交验证

配完表单别急着发出去，先在设计器里预览一遍 PC 和移动端。移动端要看的就三件事：字段是不是一列排下来的、子表单能不能横向滚动、长文本会不会把按钮顶出屏幕。表单的列宽在 PC 上设成三列很清爽，到手机上会自动折成一列，但如果某个字段设了固定宽度，手机上就会溢出，出现横向滚动条，这个是自定义页更容易犯的毛病。

发布的路径一般是：保存 → 预览 → 设置权限 → 发布。权限那一步通常有两个选项，一个是“组织内可见”，一个是“指定成员可见”。内部收集类应用选组织内可见就够，但记得把“是否允许匿名提交”关掉，除非你确实要做问卷。

发布完之后必须自己走一遍提交，用两条测试数据：一条只填主表，一条填满主表和子表单。然后打开列表页看看数据是不是都落进去了，特别是子表单的行，很多人配完发现列表里只看到主表字段，以为子表没存进去，其实是列表视图只显示了主表列，点开详情才看得到明细。

顺带说一句，表单发布后再改结构要谨慎。加字段随便加，改字段类型要看历史数据能不能转，删字段更要想清楚——删掉的字段如果被报表数据集或流程条件引用，那边会静默失效，不报错，只是条件永远不成立。这个坑第 5 章细说。

4. 流程与数据：报销、报修、定时通知三条链路的配置细节

单表单跑通之后，真正的复杂度才开始。手册后半段三个案例——进销存、报表分析、定时通知、报销流程——分别对应数据处理、数据呈现、自动化触发、多节点审批四类能力。这一章挑三个最容易配错的说透。

4.1 流程设计器：节点类型、审批人规则与条件分支

设备报修和报销流程都是流程页，差别在复杂度。报修是单线：发起 → 维修组接单 → 处理完成 → 发起人确认。报销是多节点带分支：金额小于 5000 走部门主管，5000 到 20000 加一级财务，超过 20000 再加分管领导。

流程里能放的节点就那么几类，但组合方式很多：

审批人来源是配流程时最容易含糊的地方，常见有五种：指定成员、指定角色、发起人所在部门的主管、表单里的某个人员字段、发起人自选。指定成员最省事也最脆，人员一调岗流程就卡死；用角色相对稳，但要保证角色里始终有人；用部门主管要确认组织架构是准的；用表单里的人员字段适合“由申请人指定证明人”这类场景；发起人自选最灵活，但也最容易选错人。

条件分支的配置长这样：

{ "nodeType": "condition", "branches": [ { "name": "小额报销", "priority": 3, "conditions": [ { "field": "totalAmount", "operator": "lt", "value": 5000 } ], "target": "deptManagerApprove" }, { "name": "中等金额", "priority": 2, "conditions": [ { "field": "totalAmount", "operator": "gte", "value": 5000 }, { "field": "totalAmount", "operator": "lt", "value": 20000 } ], "target": "financeApprove" }, { "name": "大额报销", "priority": 1, "conditions": [ { "field": "totalAmount", "operator": "gte", "value": 20000 } ], "target": "leaderApprove" } ], "defaultTarget": "deptManagerApprove" }

这里最需要留意的是priority和defaultTarget。多分支是按优先级从高到低匹配的，命中一个就走，所以互相排斥的条件最好把区间写全，别指望默认分支兜底——默认分支兜底意味着所有没匹配上的都走同一条路，一旦条件写漏，单据会静默走到错误节点，而且不报错。金额字段还要确认类型是数字而不是文本，文本比较时"9000" < "5000"在字典序下是成立的，这种问题排查起来非常费劲。

流程里还有几个实用开关值得开：超时自动提醒（节点停留超过 N 小时催办）、允许加签和转交（审批人休假时用）、撤回与撤销（发起人发现填错时用）。这些在手册的进阶教程里有提到，但没说什么时候该开。我的习惯是默认全开，除了“超时自动通过”——自动通过等于把风险放行，除非是那种纯粹的知会型节点。

4.2 报表分析：数据集、维度度量与图表选型

报表的前提是有数据，而且数据得规整。手册的报表分析案例里，图表是结果，真正要理解的是数据集。

数据集的定义三要素：数据来源（哪张表单或哪几张关联表）、筛选条件（时间范围、状态、部门）、分组与聚合（按什么维度分，算什么指标）。以设备报修为例子：

-- 报修统计数据集：按部门和故障类型统计工单量与平均处理时长 -- 实际配置时用界面拖拽生成，这里用 SQL 表达同一层逻辑 SELECT dept_name AS 部门, fault_type AS 故障类型, COUNT(ticket_id) AS 工单量, SUM(CASE WHEN status = 'done' THEN 1 ELSE 0 END) AS 已完成量, AVG(TIMESTAMPDIFF(HOUR, created_at, finished_at)) AS 平均处理小时 FROM repair_ticket WHERE created_at >= ${startDate} AND created_at < ${endDate} AND status <> 'draft' GROUP BY dept_name, fault_type ORDER BY 工单量 DESC;

${startDate}和${endDate}是报表上的时间筛选器传进来的变量，配数据集的时候要把它跟页面上的筛选组件绑定，否则用户改了日期图表不动。“已完成量”用的是条件聚合，比单独拉一个数据集再合并省事。AVG那行要注意，finished_at为空的单据会让平均值失真，严谨一点应该加WHERE finished_at IS NOT NULL或者用CASE WHEN包一层。

图表选型有讲究。看趋势用折线，看构成用饼图或环形，看排名用横向柱状，看分布用散点或直方。手册里那个进销存案例的库存预警，其实更适合用带阈值的条形图加颜色条件格式，一眼能看出谁快断货。别看什么图好看用什么，报表是给人做决定的，不是给汇报做封面的。

一个数据集可以喂多张图表，但别反过来——一张图表背后挂三个数据集，维护起来就是灾难。维度也不要贪多，部门和故障类型两个维度交叉已经够看，再加时间维度就得考虑用筛选器切换，全堆在一个图上，柱子会细得看不清。

4.3 定时消息通知：触发器、模板变量与幂等

定时通知是手册里篇幅最小但实际用得最多的功能，报销催办、库存预警、日报推送都靠它。配置分三块：什么时候发、发给谁、发什么。

{ "trigger": { "type": "cron", "expression": "0 0 9 * * 1-5", "timezone": "Asia/Shanghai", "description": "工作日每天 9:00 触发" }, "dataSource": { "formId": "repair_ticket", "filter": { "status": "pending", "createdAt": { "lt": "now-48h" } } }, "recipients": [ { "type": "field", "field": "assignee" }, { "type": "deptManager", "field": "dept" } ], "template": { "title": "有 ${count} 张报修单已超 48 小时未处理", "content": "工单 ${ticketNo}（${faultType}）由 ${applicant} 于 ${createdAt} 提交，当前处理人 ${assignee}，请尽快处理。", "channels": ["im", "email"] }, "dedup": { "key": "${ticketNo}_${date}", "window": "24h" } }

expression是标准的 cron，五个字段分别是分、时、日、月、周。1-5表示周一到周五，别写成1-7，那样周末也会发。timezone一定要显式指定，多人协作时如果配置环境是别的时区，早上九点会变成凌晨两点。

recipients里的type: "field"表示取单据上的处理人字段，deptManager取部门主管。这里有个隐含前提：字段值不能为空。处理人离职或未分配，这条通知就发不出去，而且不会报错。所以生产环境里最好再加一个固定的兜底接收人。

dedup是我自己加的，很多平台的定时通知不内置幂等。如果触发器周期和数据筛选窗口重叠——比如每小时跑一次、筛过去 48 小时未处理的单——同一张单会被重复推送 48 次。要么把筛选窗口设成和触发周期一样长，要么用去重键挡住。这个坑我在一个巡检提醒上踩过，当时群里连着刷了两天同样的消息，后来被同事提醒才发现。

模板变量是最容易出错的地方。${}里的字段标识必须和数据源字段完全对上，写错一个字母不会报错，通知照发，只是那一段显示为空。上线前务必用真实数据发一条测试消息给自己看。

5. 避坑与排查：配置保存成功、业务却跑不通的五种现场

平台的配置界面很少报错，大部分问题都是“保存成功但行为不对”。这类问题最难查，因为没有任何提示。下面这五条是这类项目里出现频率最高的。

5.1 数据与表单层的三个坑

现象一：报表上某个指标突然全是 0，之前一直是正常的。

原因基本可以锁定在字段被改动上。报表数据集里引用的字段标识，在表单里被改名或删除后不会同步，数据集仍然按旧标识去取数，取不到就返回空，聚合出来自然全是 0。更麻烦的是有些平台只改显示名不改标识，这时候报表还是好的，但流程条件里引用的显示名对不上，反过来又是一处失效。

解决方式是把字段标识当数据库列名对待：显示名随便改，标识一旦上线就不动。真要改，先全局搜一遍哪些数据集、流程条件、消息模板引用了它，改完再发布，然后拿一条历史数据验证报表和流程都还正常。我现在养成一个习惯，应用发布前把字段标识导出成一张清单存着，后面排查至少有个对照。

现象二：数字字段明明填的是 9000，流程条件大于 5000却不成立。

原因是字段类型和值的类型不匹配。有些场景下数字会被当成字符串存，字符串比较走的是字典序，"9000"和"5000"逐位比，第一位 9 大于 5，看起来还成立；但如果是"12000"和"5000"比，第一位 1 小于 5，条件就判成不成立了。金额、数量、评分这类参与判断和聚合的字段，建表时一定要选数字类型，别图省事用单行文本。

解决方式是改字段类型，但要注意历史数据的转换。平台一般会在改类型时提示能否兼容，不能兼容的会置空或保留原值，改完必须抽查几条历史单据，确认数值没被截断。小数位也要在建模时定好，事后从 0 位改成 2 位，历史数据不会自动补零。

现象三：移动端打开自定义页面，右边被裁掉一块，或者出现横向滚动条。

原因是自定义页用了固定像素宽度的容器。PC 上屏幕宽，看不出来；手机上宽度只有 375 左右，固定 1200 像素的容器直接溢出。

解决方式是把容器宽度改成百分比或弹性布局，卡片间距用相对单位。表格类的展示在移动端改成卡片列表，别硬塞。改完之后一定要在真机上验，设计器里的手机预览和真机渲染偶尔有差异，尤其是字体和输入框高度。

5.2 流程与消息层的两个坑

现象四：流程配了条件分支，但所有单据都走了同一个节点。

先看条件优先级。多数流程引擎的分支是从低优先级往高优先级匹配，或者反过来，不同平台不一样，手册里未必写清楚。如果两条分支条件有重叠，比如一条是“金额大于等于 5000”，另一条是“金额大于 20000”，而前者优先级更高，那大额单据永远走不到第二条。

再看字段是否为空。条件里引用的字段如果是子表单里的汇总值，而汇总公式没配或者算出来是空，比较结果就是 false，直接落到默认分支。这种情况单据不会报错，只会安静地走错路。

解决方式是给每条分支的条件写完整区间，互相排斥，然后拿三条边界数据测试：4999、5000、20000。走完看流程轨迹里每个单据停在哪，一眼就知道分支有没有命中。

现象五：审批人明明有权限，打开单据却提示无权查看。

这个坑的根源是两套权限体系没打通。功能权限管的是“能不能进这个应用和页面”，数据权限管的是“能不能看这条数据”。流程节点的审批权限是第三套东西，它决定“这条单到你这儿了，你能不能处理”。三者是独立的。

常见配置是数据权限设成“仅本人可见”，结果审批人打开单据一片空白。正确做法是把数据权限规则写成“本人或本流程当前处理人可见”，或者直接给审批角色开全量可见。更稳妥的方式是用平台提供的“流程参与人”这类内置规则，它会自动把发起人、经手人、抄送人放进去。

排查顺序建议固定下来：先确认现象发生在哪一层（数据没存进去、还是存了但查不到、还是查到了但显示不对），再看字段标识有没有被改，然后看权限规则，最后看流程轨迹。按这个顺序走，绝大多数问题三五分钟能定位，比东一榔头西一棒子强。

6. 二次开发：把宜搭当数据源，别当黑匣子

配到一定程度一定会碰到边界：财务要求报销数据自动进账、HR 要求组织变动自动同步、BI 团队要求把数据抽到数仓。手册在客户案例里提过这类打通——某家居连锁企业把审批流程和财务系统、支付系统对接，审批完自动记账付款；某箱包代工厂把生产现场的数据采上来做计件分析。这些场景的共同点是：宜搭负责采集和流转，专业系统负责核算，中间靠接口和同步连起来。

集成方式大致三种，选哪种取决于实时性要求：

不管走哪条路，落地时我都守三条规矩。第一，给每条业务数据定一个唯一业务主键，比如“单据类型 + 年月 + 流水号”，外部系统认这个键，别用平台内部 ID，迁移或重建时会变。第二，同步一律单向，主数据以源系统为准，宜搭只读不写回，双向同步的冲突处理能拖垮一个项目。第三，回调必须幂等，同一个单据号收到两次要能识别出来。

下面这段是流程结束时回调下游的典型写法：

// 流程结束回调：把审批通过的报销单推到财务系统 // 平台侧配置为"流程结束"事件触发，body 里带单据数据 export async function onProcessEnd(ctx) { const { formData, processInstanceId } = ctx; // 业务主键：单据号，下游系统按它做幂等 const bizNo = formData.reimburseNo; if (!bizNo) { throw new Error('单据号为空，拒绝推送'); // 宁可失败也不要推脏数据 } const payload = { bizNo, applicant: formData.applicant, // 人员字段通常返回对象，取需要的部分 deptCode: formData.dept && formData.dept.code, amount: Number(formData.totalAmount), // 统一转数字，避免下游收到字符串 currency: 'CNY', approvedAt: new Date().toISOString(), instanceId: processInstanceId, items: (formData.items || []).map(row => ({ subject: row.subject, amount: Number(row.amount) })) }; const resp = await fetch('https://finance.example.internal/api/reimburse', { method: 'POST', headers: { 'Content-Type': 'application/json', 'X-Idempotency-Key': bizNo // 幂等键，下游据此去重 }, body: JSON.stringify(payload), timeout: 10000 // 必须设超时，别让回调挂死流程 }); if (!resp.ok) { // 失败不要吞掉，抛出去让平台记录重试；本地也留痕便于排查 const text = await resp.text(); throw new Error(`推送财务系统失败: ${resp.status} ${text}`); } }

几个参数值得说明。bizNo是整套集成的主线，没有它就别往下写。Number(formData.totalAmount)是防御性的，表单里数字字段在某些取值路径下可能是字符串，直接传给下游会让对方的分账逻辑出错。X-Idempotency-Key头是关键，下游系统看到同一个键的重复请求直接返回上次结果，这样即使平台重试三次也不会重复记账。timeout一定要设，回调不设超时，下游一卡，流程结束事件就堆着，最后拖慢整个流程引擎。

验证方法很简单也很有效：造三条数据，一条正常走完，一条把下游接口故意关掉，一条重复提交同一个单据号。第一条看数据对不对，第二条看重试和报错记录，第三条看幂等有没有生效。三条都过，这套集成才算能上线。

从那以后我每次做这类平台对接，都强制先写一页纸的字段映射表和主键约定，双方签字确认了再动手配，再也没出现过上线后发现金额字段类型对不上的事。这份手册给的是配置方法，真正让项目跑稳的是这些配置之外的习惯。希望帮到你。

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