简介：《0 代码，搭应用——宜搭开发手册》是一份面向企业业务人员、信息化管理者及低代码入门学习者的 PDF 手册，围绕阿里巴巴宜搭零代码平台展开，回应业务缺少系统支撑、流程脱节、信息孤岛与开发运维成本高等常见问题。手册从产品定位、核心能力与产品优势讲起，结合杭州市一医院、老板电器、居然之家、海纳威等客户案例，说明宜搭在合同管理、品质管理、OA 改造和生产数字化等场景中的落地方式。教程部分覆盖核心要素、快速入门与进阶操作，并给出“T恤尺码收集”“设备报修”“企业进销存”“报表分析”“定时消息通知”“企业报销流程”等搭建实践，便于读者按案例理解表单、流程、权限与数据分析的配置思路。压缩包仅含 1 个 PDF 文件，大小约 22.76MB，目录清晰，适合系统通读或按模块查阅。已有 6793 人学习，可作为了解零代码应用搭建与企业数字化实践的参考材料。
1. 一份 108 页的 PDF，先翻目录再翻案例才是正确打开方式
拿到《0代码，搭应用——宜搭开发手册》这份 PDF，我先看的不是开篇那套“降本增效”的论述，而是目录的页码分布：平台简介加四个企业改造案例占了前 18 页，剩下 90 页全是能上手的东西——核心要素、快速入门、进阶教程，再往后是六个实践案例，T 恤尺码收集、设备报修、企业进销存、报表分析、定时消息通知、企业报销，一个比一个贴近真实办公场景。这个比例本身就说明它不是宣传册，是一本带练手题的配置手册，0 代码搭建的完整链路在里头是走通了的。
它适合两类人。一类是手上正跑着一堆 Excel 和邮件、又排不上研发排期的业务侧同学，照着案例改一改就能出个能用的东西；另一类是被拉去“帮忙搭个小系统”的开发，需要快速判断这个平台的能力边界在哪、哪些需求该拦回去。不适合的人也很明确：要做复杂事务逻辑、高并发写入、深度定制的，别在这上面耗时间。
2. 拆开手册的骨架：18 页认知、26 页基础和 64 页案例
这份材料的价值不在于它讲了多少功能，而在于它的组织方式恰好对应了学习一个 0 代码平台的三个阶段。我按页码把它切成三段，每段的读法完全不同，混着读很容易在前 20 页就失去耐心。
2.1 三段式结构决定了你该跳着读还是顺着读
| 页码区间 | 内容 | 建议读法 |
|---|---|---|
| 1–18 页 | 平台定位、产品优势、四个企业改造过程 | 扫读，只记“原来他们卡在哪” |
| 19–44 页 | 核心要素、快速入门、进阶教程 | 精读，边读边在平台上点一遍 |
| 45–107 页 | 六个实践案例，从尺码收集到报销流程 | 挑一个改造成自己的场景，剩下的当参考 |
| 108 页 | 注册入口与沟通渠道 | 用到再看 |
第一段最容易被误读成广告。四个案例讲的分别是某三甲医院的内控与合同管理、某厨电制造企业的品质数据采集、某家居连锁企业的办公流程改造、某箱包代工企业的生产计件。它们真正有价值的信息不是“效率提升多少”，而是每一段开头那句“原来是怎么干的”——纸质审批没有统一标准、大系统之间的缝隙没人覆盖、组织架构变动频繁导致老 OA 跟不上、生产现场千厂千面没法买现成软件。这四句话基本就是 0 代码平台的存在理由，也是你判断自己手上这个需求该不该用它的时候，最该对照的一张清单。
第二段是全篇密度最高的部分。核心要素、快速入门、进阶教程三层递进，从“新建一个应用”讲到“页面级自定义”和“业务规则表达式”。很多人卡在这里，是因为把它当产品说明书读，逐条看功能列表。正确做法是打开一个空白应用，读到哪一步就点哪一步，读完一节就有一个能跑的东西，读不下去说明这一步你当前的场景用不上，直接跳。
第三段才是这本手册真正的差异化。六个案例覆盖了表单收集、流程审批、主子表数据管理、聚合报表、定时触发、多级审批六种典型形态，几乎是中小企业内部系统的全部骨架。我的建议是只精读一个，把它从字段到流程全部复现一遍，剩下的五个当作“遇到类似需求时回来翻一翻”的索引，不要一次全做，做多了记不住，还容易把不同案例的配置方式串在一起。
2.2 核心要素其实只有三样：页面、规则、数据
手册把平台能力归纳成页面设计、业务规则定义、数据收集与分析三块，这个划分不是随便起的，它对应的是任何一个内部管理系统的三段生命周期：长什么样、按什么逻辑走、数据存在哪怎么查。理解这三者的边界，比记住任何一个按钮的位置都重要。
页面设计解决的是“人看到什么、填什么”。拖拽出来的表单项、分组、栅格布局都属于这一层。它的能力上限基本就是“把一张纸质表单搬到屏幕上，并且比纸质表更清楚哪里必填、哪里填错了”。
业务规则定义解决的是“填完之后发生什么”。这里包含流程节点、审批人、条件分支、字段联动、提交后的动作。手册在进阶教程里给了不少表达式和条件配置的例子，这部分是 0 代码平台真正拉开差距的地方——一个只能收集数据的表单是问卷，加上规则才叫应用。
数据收集与分析解决的是“数据进来之后怎么用”。明细列表、筛选视图、聚合图表、导出，都属于这一层。手册里的报表分析案例专门讲了这个，后面几章我会展开。
三者的耦合关系值得提前说清楚：页面上的字段是数据的列，规则里的条件判断读的是字段值，报表聚合的也是字段值。所以字段设计一旦定错，后面流程和报表全要返工。我一般会在动手拖控件之前，先在纸上把字段名、类型、是否必填、谁能看见这四件事列完，再上平台。这一步花二十分钟，能省掉后面两小时的改配置。
2.3 企业案例要看的不是成绩，是“原来的系统为什么不够”
这部分我想多说两句，因为它是很多人读完就忘、但实际上最该记住的内容。
某三甲医院的例子，原来的痛点写得很具体：内控流程走线下纸质，没有统一标准，后续管理不便。注意这里的关键词是“没有统一标准”——它要解决的从来不是技术问题，而是把散落在各部门的做法收敛成一套固定流程。宜搭在这类场景里的作用，本质是给业务侧一个不用等研发就能把流程固化成系统的工具，半个月完成升级这个数字背后，是省掉了需求评审、开发排期、测试上线这一整条链路。
某厨电制造企业的例子更典型：ERP、CRM、SRM、OA、PLM 一堆大系统都在跑，但系统与系统之间的业务覆盖不到，成了信息化的“薄弱环节”。这句话说透了 0 代码平台的定位——它不去替代核心系统，它填缝。关键物料检验记录、成品终检结果、供应商现场质量数据，这些数据量不大、变化快、要的是一线人员拿手机就能填，塞进 ERP 反而重了。我见过太多团队试图用 0 代码平台去做本该由专业系统承担的事，最后卡在性能和权限上，翻车翻得很彻底。
某家居连锁企业的例子讲的是另一层：组织架构层级多、人员岗位变动频繁，老 OA 匹配不上。这类需求的本质是“结构会变”，所以配置化、可重组的能力比功能丰富度更重要。手册里提到的接口打通、主数据单向同步、定时任务同步，都是在解决“平台之间数据对不上”的问题，这部分对熟手来说信息量最大，值得逐条看。
某箱包代工企业的例子则把边界推到了生产现场：上千个工站、几十个质检点、上百人实时协作，靠的是平板加摄像头采集计件数据。这个案例能成，前提是生产管理本身有清晰的规则，平台只是把规则数字化。反过来说，如果你的现场管理还是一团乱麻，指望上一套系统就理顺，那注定要失望。
3. 跟着手册走一遍最小闭环：从空白表单到双端可用
这一章把手册里快速入门和进阶教程的路径压缩成一条最短的可执行线。目标是做完之后你手上有一个能提交、能审批、能看数据、手机能打开的应用，而不是一堆半成品。
3.1 建应用之前先定三件事，少一件都会返工
打开平台第一步不是新建表单，是想清楚三件事。
第一，这个应用服务谁。是全员填写的收集类，还是只有某个部门能发起的申请类，还是给管理层看的报表类。这三类在权限配置上的差异极大，收集类要求可见范围宽、填写门槛低，申请类要求发起权限收窄、审批链路清晰，报表类要求数据可见但不可改。
第二，数据往哪去。是留在平台里做统计，还是要同步到别的系统。手册里某家居连锁企业的做法是通过接口和定时任务做主数据同步，这类需求必须在搭之前就想好，因为字段命名和编码规则要为后续对接留位置。等表单搭完再改字段名，报表和流程全要重新绑定。
第三，谁维护。0 代码平台最大的风险不是搭不出来，是搭出来没人管。业务侧自己搭的应用，一旦搭建人调岗，配置逻辑就成了黑匣子。我一般会要求每个应用在描述里写清楚：业务负责人、搭建人、字段含义备注、流程变更记录。平台通常有应用描述或者备注区，别嫌麻烦，这是唯一的后悔药。
三件事想清楚，再进平台新建应用。命名建议带上部门前缀和用途，比如“行政-固定资产登记”，因为后面应用一多，纯靠记忆找会非常痛苦。
3.2 表单字段：类型、校验和联动，错一个后面全歪
新建表单之后，拖控件之前，先把字段清单列成表。字段类型的选择有几条硬规则，都是踩过才知道的。
| 业务含义 | 推荐字段类型 | 常见误用 |
|---|---|---|
| 金额 | 数字（保留两位小数） | 用单行文本，导致无法求和 |
| 日期 | 日期选择器 | 用文本，无法做时间范围筛选 |
| 部门/人员 | 组织架构选择 | 手动输入文本，统计时对不上人 |
| 状态 | 单选（固定选项） | 用文本，出现“已完成/完成/已完”三种写法 |
| 附件 | 附件上传 | 让人贴网盘链接，半年后链接全失效 |
| 关联另一张表 | 关联查询/子表单 | 手动复制粘贴，数据永远不同步 |
这张表里最容易被忽略的是“状态”和“人员”两行。状态字段用文本，看起来自由，实际上报表分组的时候会裂成七八个组；人员字段手动输入，重名和错字会让后续的权限判断直接失效。手册在进阶教程里对字段校验有说明，必填、正则、数值范围这些配置，能拦住相当一部分脏数据。
字段联动是进阶能力。典型场景是选了“报销类型”为差旅，才显示“出差地点”和“起止日期”；选了“设备类型”为特种设备，才要求上传检测报告。这类配置在平台的表单设计器里一般叫“显示条件”或者“联动规则”，配置的时候注意条件的判断顺序，多个条件叠加时，从最外层往里写，别一次性堆五六条，出问题很难定位是哪一条没生效。
子表单是另一个高频点。进销存案例里的“一张订单多个商品”就是典型主子表结构：主表存订单头信息，子表单存明细行。子表单的字段不能直接拿去和其他表做关联查询，需要先通过主表关联，这个限制很多人第一次碰会愣住，配置前要心里有数。
3.3 流程配置：节点、审批人和条件分支的三层结构
表单搭完，加流程。流程配置我习惯分三层看。
第一层是节点顺序。发起、审批、抄送、结束，这是骨架。节点不宜过多，五个以内最好，超过七个的流程基本可以判定为管理冗余，先建议业务侧砍流程再上系统。
第二层是每个节点的审批人怎么定。常见的有四种：指定人员、按组织架构找上级、按表单字段里选的人、按角色。按字段选人是灵活性最高也最容易出事的一种——发起人自己填审批人，等于自己指定谁来审自己，必须配合权限限制，让这个字段不可改或者可选范围受限。
第三层是条件分支。金额大于某个数走总经理，小于走部门经理，这类按字段值分流是标准用法。配置时的坑在于条件的完整覆盖：只写了“大于 5000 走 A”，没写“小于等于 5000 走 B”，流程会在中间卡住。我一般要求每个分支条件写成互斥且穷尽，最后兜一条默认路径。
流程节点上还能配消息通知。手册里单独有一个定时消息通知的案例，说明这块用得很多。即时通知挂在节点提交、审批通过这些事件上，定时通知则按固定时间扫描数据，比如每天早上把逾期未审批的单据推给负责人。两者的区别要分清：事件触发是“事情发生就通知”，定时触发是“到点检查一遍再通知”，前者及时，后者适合催办类场景。
3.4 数据管理与报表：从明细到聚合的两步走
数据这一层，先有明细再有聚合，顺序不能反。
明细就是列表视图。配置的时候重点是筛选条件和显示列。筛选条件决定了不同角色看到的数据范围，比如部门经理只看本部门，财务看全部。显示列决定信息密度，把十几个字段全铺上去的列表没人看得下去，通常留五到七个关键字段就够，其余放到详情页。
聚合是报表。手册的报表分析案例里，核心操作是按某个维度分组、按某个指标汇总。设备报修按月份和设备类型统计数量，品质数据按供应商统计合格率，都是这个套路。配置报表时最容易出错的是“统计口径”：数量是算记录条数还是算某个字段的求和，合格率的分子分母分别取哪个状态的数据，这些在配置界面上是几个下拉框的差别，结果能差出一倍。
提示：报表配完之后，拿三条已知结果的数据手工核对一遍。这一步花五分钟，能发现绝大多数口径错误。
3.5 发布、权限与双端适配：最后一公里
应用搭完要发布。发布前检查三件事。
一是权限。平台一般把权限分成应用级、页面级、数据级三层。应用级控制谁能进来，页面级控制谁能看到哪个页面，数据级控制谁能看到哪些行。三层都要设，只设第一层是最常见的疏漏——人能进应用，但能看到全公司的数据。
二是双端。手册开篇就强调“一次搭建双端适配”，移动端打开的效果要单独验证。表单项在手机上会被压缩，原来一行三个字段的布局可能要改成一行一个；子表单在手机上操作体验普遍一般，明细行超过五条建议改成分批提交或者改用其他方式录入。
三是消息触达。审批类的应用必须验证通知能不能到达，尤其是移动端的推送。这个环节在很多环境里带点玄学，配置看起来没问题但就是收不到，第八章会讲排查思路。
4. 六个实践案例怎么用：挑一个改造成自己的场景
手册后半部分的六个案例，价值不在于照抄，而在于它们各自代表了一种系统形态。我按上手难度和复用价值重新排了个序，从最容易的开始。
4.1 T 恤尺码收集：最适合第一个动手的题
这是六个案例里最简单的，也是最该先做的。它的结构就是一张表单加一个统计视图：姓名、部门、尺码、数量，提交后按尺码分组看总数。
为什么推荐拿它练手？因为它没有流程，没有权限分层，没有跨表关联，你只需要专注在一件事上——把字段设计对。尺码字段用单选而不是文本，部门字段用组织架构选择而不是手动输入，这两点做对，统计视图直接就能出结果；做错，你会发现分组结果里有“XL”“xl”“X-L”三个组。
改造思路也很直接：把尺码换成任何你要收集的枚举值。工作服型号、午餐口味、培训场次意向、团建日期选择，结构完全一样。这类“收集加统计”的需求在任何组织里都占相当比例，搭一次之后就是模板。
我一般会在这个练习里额外加两个东西：一是提交后的确认提示，写清楚“提交后不可修改，如需变更联系谁”；二是截止时间，到了自动关闭表单。这两个细节决定了收集类应用是能用还是好用。
4.2 设备报修：把状态机画清楚再拉流程
设备报修案例的结构是：报修提交、维修接单、处理完成、验收确认，中间可能还有转派和驳回。这是典型的流程类应用，也是把 0 代码平台能力用足的一个案例。
动手之前，先在纸上把状态图画出来。待接单、处理中、待验收、已完成、已关闭，五个状态，每个状态之间谁能触发流转，写清楚。这张图如果画不出来，说明业务规则本身没想明白，这时候去配流程只会配出一团乱麻。
画完之后对应到平台：状态字段用单选，流转动作配在流程节点上，每个节点限定可操作的角色。有一个细节值得注意：报修单被驳回之后回到哪个状态。很多人配成驳回到发起人，实际上应该是驳回到上一个处理节点，因为报修人往往没法修改维修方案。这类“回退到哪”的问题，是流程配置里最容易配错、最难在测试阶段发现的地方。
设备报修还有一个天然的数据分析点：按设备类型统计故障频次，按维修人统计平均处理时长。这两个报表配出来，这个案例就从“能用”变成“有用”了，因为它开始支撑决策——哪台设备该换了，谁的工单积压了。
4.3 企业进销存：主子表与关联查询的取舍
进销存是六个案例里结构最复杂的一个，涉及商品、库存、订单、供应商多个对象。它在手册里的价值，主要是演示主子表和关联查询怎么用。
主子表的典型是采购订单：主表存单号、供应商、下单日期、总金额，子表单存商品明细，一行一个商品，含名称、规格、数量、单价。总金额可以用子表单的求和自动算，也可以用公式字段。这里有个取舍：用公式自动算省事但改不了，用手工填灵活但容易错。我一般选自动算，因为金额算错带来的麻烦远大于省下的那点灵活性。
关联查询用于跨表取数，比如下单时选商品，自动带出规格和单价。这类配置在平台里通常叫“数据联动”或者“关联表单”，配置时要注意联动过去的字段是只读的，如果需要允许改价，得单独开一个可编辑字段，不要让联动字段直接可改，否则数据源一变动，历史订单的价格全跟着变。
库存这块要提前想清楚扣减时机。是下单就扣，还是发货才扣，还是验收才扣，三种做法对应三种业务规则，也和财务口径直接相关。手册里没有展开这一层，但实际落地绕不开，建议在做这个案例时至少把规则写进应用描述。
4.4 报表分析与定时消息通知：让数据自己找人
这两个案例单独看都很薄，合起来看才有意思。
报表分析案例讲的是把已有数据做成聚合视图。设备报修按类型统计、按月份统计、按处理人统计，这类配置的核心是选对分组维度和汇总方式。手册里的示例偏基础，实际使用中还需要注意时间维度的处理——按月统计要保证日期字段是标准日期类型，用文本存的日期做不了月度分组。
定时消息通知案例则是把报表的结果主动推出去。典型的配置是：每天早上扫描一次数据，把超过三天未处理的工单汇总成一条消息推给负责人。这个能力的意义在于，它把“人找数据”变成了“数据找人”，一个没人看的报表等于不存在。
配置时的关键是触发频率和数据范围。频率太高会变成骚扰，消息被无视之后就彻底失效了；数据范围要写准，宁可多推几个人也不要漏推，漏一次可能就是一个逾期一个月的合同。
4.5 企业报销：权限矩阵最容易翻车的地方
报销流程几乎是每个组织都要的东西，也是手册里最能体现“权限配置重要性”的案例。
它的结构是典型的金额分流加多级审批：金额小于某个数走部门经理，再往上加财务审核，再往上加分管领导。金额字段的取值直接决定走哪条分支，所以这个字段必须是数字类型且必填，不能用文本。
权限矩阵是这个案例的核心。谁能发起、谁能审、谁能看全部数据、谁能导出，这四个问题要分别回答。我见过最常见的翻车是“能看全部数据”这一条没设，结果所有审批人互相能看到彼此的报销明细，包括薪资相关的补贴项，这在很多组织里是红线。
另一个容易忽略的点是附件权限。发票照片上传之后，谁能下载？默认可能是所有能看到这条记录的人。如果报销单里含敏感信息，附件权限要单独确认。
5. 避坑与排查：六个在配置现场真实发生过的坑
这一章按“现象 → 原因 → 解决”写，每条都是我或者身边人实际遇到的，不是理论推演。
5.1 报表数字对不上，明细加起来和汇总差一截
现象：明细列表里数出来 47 条记录，报表汇总显示 52 条，或者金额求和差了十几块。
原因通常有三个。一是筛选条件不一致，明细列表用了一个筛选视图，报表配置用了另一套条件，两边的数据范围本来就不同。二是数据里有空值，求和时被跳过或者被当成零，条数却照样算。三是关联查询带出来的字段在多条明细中被重复计数，尤其是一对多关联时，主表记录被算了多次。
解决：先统一筛选口径，把明细视图的条件原样搬到报表配置里；再检查求和字段是否存在空值，用“非空”条件先过滤一遍看数字是否吻合；最后确认统计的是记录条数还是去重后的主体数量，报表里一般有“计数”和“去重计数”两个选项。这三步走完，九成对不上的问题能定位。
5.2 流程卡在中间，没人收到待办
现象：单据提交成功，状态显示“审批中”，但审批人那边什么都没收到，单据一直挂着。
原因：审批人配置用了“按表单字段选择”，而那个字段是发起人自己填的，填的时候选了一个没有审批权限的账号，或者选了一个已离职人员。平台的流程引擎找不到有效审批人，就静默挂起。
解决：短期靠管理员在后台做转办或者改派，把卡住的单子放下去。长期改配置，把审批人从“表单字段”改成“按组织架构取上级”或者“按角色取人”，角色里的人员变动由管理员统一维护。同时给流程加一条超时提醒，超过设定时长未处理自动通知管理员，不要让它无声无息地挂着。
5.3 手机上打开一片空白或者布局错乱
现象：电脑上配好的表单，手机端打开后字段挤成一团，或者干脆白屏。
原因：布局用了固定宽度的多列结构，移动端屏幕宽度不够，元素被挤出可视区域。白屏则多半是页面里引用了不兼容的组件或者自定义代码。
解决：表单项改成单列纵向排列，需要并排的字段用分组而不是栅格强行拼；子表单在移动端的行数控制在五条以内，超出部分拆成多次提交。白屏问题逐个组件排查，把自定义代码块先注释掉，能恢复就说明是那一段的问题。每次改完配置，养成用手机打开看一眼的习惯，别等到上线才发现。
5.4 改了字段名，流程和报表明明没动却全失效
现象：把“申请人部门”改成“所属部门”，结果流程走不通了，报表也空了。
原因：流程的条件分支和报表的统计配置里绑定的是字段的唯一标识，改显示名称本身通常不影响，但如果删除后重建了字段，标识就变了，所有引用它的地方全部断链。
解决：字段的显示名可以改，字段本身不要删了重建。必须重建时，先在流程和报表里把引用关系梳理出来，重建后逐条重新绑定。这也是为什么我在 3.1 里强调动手前列字段清单——字段一旦进生产环境，改动成本远高于前期多想十分钟。
5.5 消息通知发出去了，但没人点开
现象：审批通知、逾期提醒都配了，数据也显示已发送，实际没人处理。
原因：通知渠道选错了，发到了不常看的渠道；或者消息内容太模糊，只写“您有一条待办”，没写是什么事、多紧急；或者推送频率过高，一天十几条，直接被无视。
解决：通知内容里带上关键信息——单据标题、发起人、金额、剩余处理时间，让人不点进去也能判断优先级。审批类走即时推送，催办类合并成每日一条汇总，不要一条一个推送。上线第一周盯一下触达率和处理时长，数据不好看就调，别配完就不管。
5.6 权限看起来设了，实际数据还是被看到了
现象：给某个部门设了“仅本部门可见”，结果别的部门还是能搜到记录。
原因：数据权限只配在了列表视图上，详情页的直接链接、导出功能、关联查询的搜索结果都没限制。用户从一个入口进不去，换个入口就进去了。
解决：数据权限要在所有出口上都设一遍——列表、详情、导出、关联查询、消息推送里的链接。配置完成后用另一个部门的测试账号实际验证一遍，把这个账号能触达的所有入口都点开看，不要只看主列表。
6. 进阶：把六个案例改造成自己的模板库
手册读完做完，真正的收获不是会用了某个平台的某个按钮，而是手上多了一套可复用的结构。我的做法是把六个案例抽象成六种模式，存在脑子里也写在笔记里，下次遇到需求先做模式匹配，而不是从空白开始。
收集类对应尺码收集，特征是单表、无流程、重统计。审批类对应设备报修和报销，特征是状态流转、按金额或类型分流。主子表类对应进销存，特征是一对多明细、需要汇总计算。报表类对应报表分析，特征是分组聚合、口径要反复确认。触发类对应定时通知，特征是时间驱动、需要控制频率。门户类对应手册里某家居连锁企业做的多页面导航，特征是给不同角色不同的入口页。
匹配完之后，还有一个动作我强烈建议做：给每个做过的应用写一份“配置说明”，不超过一页，写清楚字段清单、流程节点、权限规则、已知限制、维护人。这份东西不需要给领导看，是给三个月后的自己看的。我吃过一次亏，一个半年前搭的报销应用要做调整，打开配置界面完全不记得某条条件分支为什么那么写，只能一条条反推，花了整整一个下午。从那以后我每次搭完应用，都强制走一遍写说明的流程，把配置逻辑从平台里“抄”出来存成文档。
另外两个技巧值得单独提。一是善用测试数据。所有应用在正式投用前，造三条覆盖不同分支的假数据跑一遍全流程，包括驳回、撤回、超时这些异常路径，跑通再放人进来用。二是版本意识。配置类平台没有代码仓库那种版本管理，改了就是改了，回不去。所以每次大改之前，把当前配置截图或者导出留一份，出问题能对照着回滚。
手册最后一页给了注册入口和沟通渠道，这类资源拿到手之后，先跑通一个最简案例，比通读十遍有用得多。希望帮到你。
本文还有配套的精品资源，点击获取
