简介《0代码搭应用——宜搭开发手册》面向希望低成本推进企业信息化的业务人员、管理者与开发入门者针对业务无系统支持、流程脱节、信息孤岛、智能化程度低及开发运维成本高等痛点系统讲解阿里巴巴企业智能事业部推出的0代码应用搭建平台宜搭。手册从产品定位、核心能力与产品优势讲起覆盖页面设计、业务规则定义、数据收集与分析三大模块并给出杭州市一医院、老板电器、居然之家、海纳威等客户案例帮助读者理解零代码如何缩短交付周期。实践部分包含T恤尺码收集、设备报修、企业进销存、报表分析、定时消息通知、企业报销流程等案例配合快速入门与进阶教程可对照完成从表单流程搭建到数据看板的全过程。资源为1个PDF文件压缩包约22.76MB结构清晰便于按章节查阅。目前已有6769人学习下载适合想快速上手宜搭、评估零代码方案或寻找落地参考的读者。1. 从「0 代码搭应用」说起宜搭开发手册到底解决谁的燃眉之急如果你手上有一份《0 代码搭应用——宜搭开发手册》.pdf却迟迟没打开大概率不是懒而是不确定它值不值得花一个下午啃完。我最初接触宜搭也是这个心态低代码平台听得多真正落到自己业务上往往卡在「表单能建流程能跑但一到权限、联动、数据回写就翻车」。这份手册的价值恰恰在于它把「0 代码」这个听起来有点玄学的口号拆成了可照着点的操作路径——从表单设计、流程编排到数据源对接和页面发布覆盖的是一个应用从零到能用的完整闭环。它适合三类人一是业务侧的产品或运营手里有明确需求但排不上研发资源二是刚转低代码方向的开发者想用宜搭快速验证一个内部工具三是团队里被推出来「先搭个 demo」的那个人。不适合指望它替代后端架构的人——0 代码能解决的是表单流转和轻量数据管理不是高并发交易系统。想清楚这一点再往下看怎么落地。2. 宜搭的核心构件表单、流程、数据源三件套怎么配合宜搭搭应用的底层逻辑说白了就三样东西在转表单负责收集和展示数据流程负责驱动状态流转数据源负责把外部数据拉进来或写出去。三者不是并列关系而是表单是入口流程是骨架数据源是血管。很多人第一次搭应用失败不是某个组件不会用而是没想清楚这三者谁触发谁。2.1 表单设计字段类型选错后面全在还债表单是用户看到的第一层。宜搭的字段类型大致分几类文本、数字、日期、下拉单选/多选、关联表单、子表单、附件。选型时最容易踩的坑是「用文本字段存本该用关联表单存的数据」。比如「所属部门」你用一个文本框让用户手填后面想做按部门统计时就会发现数据脏得没法看。正确做法是凡是需要参与筛选、统计、联动的字段一律用结构化类型。部门用关联表单或下拉单选金额用数字字段并设精度日期用日期字段而不是文本。下面是一个典型表单字段配置的示意宜搭里是可视化配置这里用 JSON 表达结构方便理解字段之间的约束关系{ formName: 报销申请单, fields: [ { key: applicant, type: employee, label: 申请人, required: true }, { key: dept, type: select, label: 所属部门, required: true, optionsSource: department_api }, { key: amount, type: number, label: 报销金额, precision: 2, required: true }, { key: expenseDate, type: date, label: 费用发生日期, required: true }, { key: detail, type: subform, label: 费用明细, columns: [itemName, itemAmount, invoiceNo] } ] }这段配置里applicant用员工类型而不是文本是为了自动带出工号和部门dept的optionsSource指向部门接口保证选项和 HR 系统一致amount设了两位精度避免浮点误差在汇总时炸掉detail用子表单是因为一张报销单可能对应多张发票用子表单才能做行级校验。参数上最需要盯的是required和precision——前者决定流程能不能往下走后者决定财务对账时会不会差几分钱。2.2 流程编排节点权限和流转条件是最容易翻车的地方流程编排的核心不是画流程图而是配清楚两件事每个节点谁能操作以及什么条件下走哪条分支。宜搭的流程节点类型有审批人、抄送人、条件分支、并行分支等。新手常犯的错是把审批人设成「发起人自选」结果流程走到一半没人认领卡在那里变成黑匣子。一个稳妥的配置习惯是审批人优先用角色或主管字段而不是让发起人手选。条件分支的表达式要写全不要留「其他情况」的空分支——宜搭在条件不匹配时会直接报错或挂起。下面是一个条件分支的表达式写法示例// 报销金额大于 5000 走总监审批否则走经理审批 // 条件分支表达式宜搭表达式语法 amount 5000 // 对应的另一条分支 amount 5000逻辑说明两条分支必须覆盖所有可能的amount取值不能只写amount 5000就完事。参数上注意宜搭表达式里的字段名要用表单里定义的key不是显示标签。如果字段是子表单里的行级字段表达式里要写成detail.itemAmount这种带前缀的形式否则取不到值。流程发布前一定要用测试数据把每条分支都走一遍尤其是金额边界值 5000 本身走哪条这个不测上线必出问题。2.3 数据源对接远程 API 和本地数据集的取舍宜搭的数据源分两类平台内置的数据集表单提交的数据自动形成数据集和远程 API对接外部系统。什么时候用哪个如果数据只在宜搭内部流转用数据集就够了如果需要和 ERP、CRM 或自建系统同步就得配远程 API。远程 API 配置的关键是请求方式和字段映射。宜搭支持 GET 和 POST返回结果需要做字段映射才能被表单或页面消费。常见坑是接口返回嵌套结构而宜搭的映射只认一层这时候要么在接口侧做扁平化要么用宜搭的数据处理节点拆一层。参数上超时时间建议设 5 到 10 秒太短容易误报失败太长会把页面拖死。认证方式如果对方要求 token记得把 token 获取也配成一个前置数据源不要硬编码在请求头里——硬编码的 token 过期后整个应用会静默失效排查起来非常痛苦。3. 从零搭一个「报销审批」应用可复现的六步操作前面讲的是构件和选型这一章直接走一遍完整流程。选报销审批是因为它覆盖了表单、流程、数据源、权限四个核心点搭完这一个其他内部工具基本能照搬。3.1 第一步建应用和表单先把字段定死进入宜搭工作台新建应用命名「费用报销」。然后在应用下新建表单按 2.1 节的字段结构配置。这一步不要急着调样式先把字段的key、类型、是否必填定下来。字段key一旦被流程或数据源引用后期改名会导致引用断裂所以命名要一次到位用英文小写加下划线。配置完表单后点预览手动填一条测试数据提交确认数据能进数据集。这一步是后面所有操作的基础如果这里数据进不去流程配了也是空跑。3.2 第二步配流程把审批人和分支条件写清楚在表单设置里开启流程进入流程设计器。按这个顺序配开始节点 → 申请人提交 → 经理审批 → 条件分支 → 总监审批金额大于 5000→ 财务确认 → 结束。每个审批节点的审批人设置经理审批节点选「发起人主管」总监审批节点选「部门总监角色」财务确认节点选「财务角色」。不要用「发起人自选」除非业务上确实需要动态指定。条件分支按 2.2 节的表达式配两条分支都要有明确的下一步不能有断头路。配完后用测试数据走一遍提交一笔 3000 的看是否只走经理再提交一笔 8000 的看是否走经理加总监。如果分支没生效先检查表达式里的字段key是否和表单一致。3.3 第三步接数据源把部门选项和财务系统打通部门下拉选项如果手动维护人一多就会过期。常见做法是配一个远程 API 数据源指向 HR 系统的部门接口。配置时注意请求方法用 GET返回格式如果是{ data: [...] }字段映射里要指定取data这一层。财务确认节点如果需要回写报销单号到外部系统再配一个 POST 数据源在流程的财务确认节点后触发。参数上把表单里的amount、applicant、detail映射到接口字段注意子表单数据要转成数组传不能直接传对象。# 远程 API 数据源配置示意宜搭界面配置此处用 curl 表达请求结构 curl -X POST https://internal-erp.example.com/api/reimburse \ -H Content-Type: application/json \ -H Authorization: Bearer ${TOKEN} \ -d { employeeId: {{applicant.id}}, amount: {{amount}}, items: {{detail}} }逻辑说明{{ }}是宜搭的变量占位符运行时会被表单数据替换。items对应子表单宜搭会自动转成数组。参数上Authorization的 token 建议从环境变量或前置数据源取不要写死在配置里。如果接口返回非 200宜搭会在流程日志里记录排查时先看日志里的请求体和响应体。3.4 第四步配权限别让不该看的人看到金额权限分两层表单权限和流程节点权限。表单权限控制谁能新建、谁能查看、谁能编辑。报销单的查看权限建议设成「仅本人和审批人可见」不要设成全员可见——金额和发票信息属于敏感数据。流程节点权限在流程设计器里配每个节点的审批人只能看到自己需要操作的部分。如果某个字段在经理节点不需要看可以在节点字段权限里把它设为隐藏。这一步不做上线后大概率会收到「为什么他能看到我报销多少」的投诉。3.5 第五步发布页面把入口给到用户表单和流程配好后需要建一个页面作为入口。宜搭的页面设计器支持拖拽组件把「新建报销」按钮和「我的报销记录」列表拖上去。列表的数据源选表单数据集筛选条件设成「申请人等于当前用户」。页面发布后把链接或二维码发给用户。如果是内部使用建议配到工作台首页减少用户找入口的成本。发布前用非管理员账号登录测一遍确认权限和数据显示都正常。3.6 第六步用测试数据跑通全流程再交给真实用户这一步最容易被跳过。正确做法是用三个不同角色的测试账号申请人、经理、财务各走一遍完整流程包括通过、驳回、条件分支三种情况。驳回后重新提交看流程是否能回到正确的节点。全部通过后再小范围放给真实用户试用一周收集反馈再调整。4. 宜搭落地避坑五条血泪经验这一章单独列坑因为下面每一条都是我或身边人真实踩过的现象、原因、解决都写清楚照着排查能省不少时间。4.1 现象流程走到某个节点卡住没人能审批原因审批人设成了「发起人自选」但发起人没选或选了一个已离职的人。宜搭不会自动兜底节点就挂在那里。解决把审批人改成角色或主管字段并在流程设置里开启「审批人离职自动转交」。如果业务必须自选加一个校验发起人未选时不允许提交。4.2 现象表单提交后数据集里查不到数据原因表单的「数据提交」权限没开或者数据集筛选条件写错了。还有一种情况是表单用了草稿模式用户没点最终提交。解决检查表单权限设置里的「新增」权限是否对目标角色开放检查数据集筛选条件是否把当前用户排除了确认用户操作的是「提交」而不是「暂存」。4.3 现象远程 API 数据源偶尔失败刷新又好了原因接口超时时间设得太短或者对方接口本身有波动。宜搭默认超时可能是 3 秒跨网络调用经常不够。解决把超时时间调到 8 到 10 秒并在数据源配置里开启重试如果平台支持。如果对方接口不稳定考虑加一层缓存数据集定时同步而不是实时调用。4.4 现象条件分支不生效所有单子都走同一条路原因表达式里的字段key写错了或者字段类型不匹配。比如amount是数字字段表达式里却写成了字符串比较。解决在流程日志里看分支判断的实际取值确认字段key和类型。数字字段直接比较数值不要加引号。子表单字段要带前缀如detail.itemAmount。4.5 现象页面列表加载慢数据多了直接转圈原因列表数据源没有分页或者筛选条件没走索引。宜搭数据集在数据量超过几千条后全量拉取会明显变慢。解决列表组件开启分页每页 20 条筛选条件尽量用结构化字段如日期范围、部门 ID避免用文本模糊搜索。如果数据量确实大考虑用远程 API 分页查询而不是直接绑数据集。5. 进阶技巧用宜搭中级实操题的思路验证你的应用如果你已经搭完一个应用怎么判断自己是不是真的掌握了我的习惯是拿「宜搭中级实操题二」这类题目来练手——不是背答案而是看自己能不能在不查文档的情况下把题目里的需求拆成表单、流程、数据源三部分并预判出哪里会卡。这个自测方法比看十遍手册都管用。具体做法找一道实操题先不看答案自己估一下需要几个表单、几条流程分支、要不要接外部数据源。然后动手搭搭完和参考答案对比差异最大的地方就是你最薄弱的环节。比如题目要求「根据库存自动触发补货申请」如果你第一反应是手动建表单说明还没建立起「数据源触发流程」的思维。另一个进阶方向是关注低代码界面的组件化思路。宜搭的页面设计器支持自定义组件如果你有前端基础可以把重复出现的模块比如审批历史时间线封装成自定义组件在多个页面复用。这样做的收益是改一处所有引用它的页面同步生效不用逐个页面调。// 自定义组件注册示意宜搭自定义组件开发模式 export default { name: ApprovalTimeline, props: { records: { type: Array, default: () [] } }, mounted() { // 组件挂载时按时间倒序排列审批记录 this.records.sort((a, b) new Date(b.time) - new Date(a.time)); } };逻辑说明records是父页面传入的审批记录数组mounted里做排序保证最新记录在最上面。参数上default给空数组是为了防止父组件没传值时组件报错。自定义组件开发需要一定的前端基础如果团队里没有前端优先用平台内置组件不要为了封装而封装。最后说一个我自己的习惯每搭完一个应用我会把配置过程反向写成一份「如果重来一次我会怎么改」的清单贴在应用文档里。下次搭类似应用时先看这份清单能避开八成重复的坑。宜搭这类低代码平台真正的门槛不在组件会不会拖而在对业务数据流的理解——想清楚数据从哪来、经过谁、到哪去剩下的就是配置问题。希望帮到你。本文还有配套的精品资源点击获取