1. 为什么我选择用 WorkBuddy 而不是从零手搓一个 App

去年年底我接了个私活，帮一个做线下活动策划的朋友搭一套内部用的签到与任务管理工具。需求听起来不复杂：活动当天工作人员用手机扫码签到，后台能实时看到到场情况，活动结束后导出名单。但真正动手的时候问题就来了——朋友团队没有专职开发，预算也有限，不可能养一个完整的移动端团队。

我一开始想的是直接写原生 Android，毕竟我对 Android Studio 那套东西还算熟。但算了一下时间成本：光是搭建项目骨架、处理登录态、做数据同步、适配各种机型，保守估计要三周。而且朋友那边后续还想加功能，比如任务分配、消息通知、数据看板，每加一个功能都要重新打包发版，维护成本太高。

后来我换了个思路，用 WorkBuddy 来搭。WorkBuddy 本质上是一个低代码/无代码的应用搭建平台，它把常见的 App 能力（用户体系、数据存储、页面渲染、权限控制）都封装好了，你只需要关注业务逻辑本身。我最终用大约五天时间把这个工具跑通了，从开发到上线再到后续迭代，整个过程踩了不少坑，也积累了一些可复用的经验。

这篇文章不是 WorkBuddy 的官方教程，官方文档该讲的都讲了。我要分享的是从零到上线这个完整链路上，那些文档里不会写、但实际做的时候一定会遇到的问题。包括平台选型的取舍、数据层的设计、WebView 的坑、Supabase 的集成细节、以及上线前必须检查的清单。如果你也打算用 WorkBuddy 做一个能真正跑起来的 App，这篇内容应该能帮你省下不少时间。

提示：本文提到的所有操作和配置，都是基于我实际项目中的经验总结。不同版本的 WorkBuddy 界面和功能可能有差异，具体以你使用的版本为准。

2. 动手之前先想清楚：WorkBuddy 能做什么、不能做什么

2.1 WorkBuddy 的核心能力边界

很多人第一次接触 WorkBuddy 的时候，容易把它当成"万能 App 生成器"，觉得拖拖拽拽就能做出一个微信级别的产品。这个预期是不对的。WorkBuddy 的定位是快速搭建业务工具类应用，它擅长的是：

• 表单填写与数据提交
• 列表展示与详情查看
• 简单的流程审批与状态流转
• 用户登录与权限分级
• 数据统计与简单报表

它不擅长的是：

• 复杂的动画和交互效果
• 高性能的游戏或图形渲染
• 需要深度调用系统硬件的功能（比如蓝牙控制 ESP32 这种）
• 大规模并发场景下的性能优化

我那个签到工具刚好落在 WorkBuddy 的舒适区里：表单提交、列表展示、数据导出，全是它的强项。所以选型这件事，核心不是看平台有多强，而是看你的需求跟平台的能力是否匹配。

2.2 什么时候该用 WorkBuddy，什么时候该换方案

我总结了一个简单的判断标准，你可以对照自己的项目看一下：

如果你的项目大部分落在左边这一列，那 WorkBuddy 是个不错的选择。如果右边占多数，那还是老老实实走原生开发或者跨端框架的路子。

2.3 我踩过的第一个坑：把 WorkBuddy 当成了全栈解决方案

刚开始的时候，我以为 WorkBuddy 把后端也包了，数据存储、用户管理这些都不用管。结果做到一半发现，WorkBuddy 提供的是前端搭建能力 + 基础数据存储，但如果你需要更复杂的数据查询、关联查询、或者自定义 API，还是得自己接后端服务。

我后来接的是 Supabase，因为它提供了 Postgres 数据库、认证、实时订阅、存储等一整套后端能力，而且跟 WorkBuddy 的集成相对顺畅。这个组合在后面会详细讲。

注意：不要等到项目做到一半才发现数据层不够用。在动手之前，先把你需要的数据结构和查询场景列出来，确认 WorkBuddy 自带的数据能力能不能覆盖。覆盖不了的部分，提前规划好外部服务的接入方案。

3. 六个阶段拆解：从空白项目到能上线的 App

3.1 阶段一：需求梳理与数据建模

这个阶段看起来最不起眼，但实际上是后面所有工作的基础。我当时的做法是，先不碰 WorkBuddy，拿一张白纸把整个业务流程画出来：

1. 工作人员打开 App，看到活动列表
2. 选择一个活动，进入签到页面
3. 扫描参与者二维码或手动搜索姓名
4. 确认签到，数据实时同步到后台
5. 管理员在后台查看签到统计，导出名单

画完流程之后，我开始设计数据表。核心就三张表：

• events：活动信息（活动名称、时间、地点、状态）
• participants：参与者信息（姓名、手机号、所属活动、签到状态、签到时间）
• users：工作人员信息（姓名、角色、权限）

这里有个经验：在 WorkBuddy 里建数据表的时候，字段类型尽量用最简单的。比如时间字段，不要用复杂的日期格式，直接用时间戳或者标准化的字符串。因为 WorkBuddy 的数据绑定和展示逻辑对复杂类型的支持有限，简单类型能省掉很多麻烦。

3.2 阶段二：WorkBuddy 项目初始化与页面搭建

WorkBuddy 的项目创建流程比较直观，选模板、填名称、选图标，几分钟就能搞定。但有几个细节需要注意：

第一，项目名称和包名要提前想好。后面如果要上架应用商店，包名是不能改的。我当时的做法是用com.公司名.项目名的格式，比如com.example.checkin。虽然 WorkBuddy 可能会自动生成一个包名，但最好还是自己确认一下。

第二，页面结构要提前规划。WorkBuddy 的页面是树状结构，父页面和子页面的关系会影响导航逻辑。我建议按照业务流程来组织页面，而不是按照功能模块。比如"活动列表 → 活动详情 → 签到页面"是一条完整的用户路径，放在同一个分支下，导航逻辑会清晰很多。

第三，主题和样式统一设置。WorkBuddy 支持全局主题配置，包括主色调、字体、圆角等。这个一定要在开始搭页面之前就定好，不然后面每个页面单独调样式，工作量会翻倍。

3.3 阶段三：数据层对接（Supabase 集成）

这是整个项目里技术含量最高的部分。WorkBuddy 自带的数据存储适合简单的场景，但我需要更灵活的查询和关联能力，所以接了 Supabase。

Supabase 的集成主要分三步：

第一步，在 Supabase 创建项目并建表。建表的时候要注意，字段名用英文，不要用中文。虽然 Supabase 支持中文列名，但在 API 调用的时候容易出问题。我当时的命名规范是：表名用复数形式（events、participants），字段名用下划线分隔（event_id、checkin_time）。

第二步，在 WorkBuddy 里配置 API 连接。WorkBuddy 支持自定义 API 数据源，你需要填入 Supabase 的项目 URL 和 API Key。这里有个坑：Supabase 有两种 Key，一种是anonkey（公开的，受行级安全策略限制），一种是service_rolekey（私密的，绕过所有安全策略）。在客户端一定要用 anon key，service_role key 只能放在服务端，绝对不能暴露在前端代码里。

第三步，配置行级安全策略（RLS）。这是 Supabase 的核心安全机制。你需要为每张表定义：谁可以读、谁可以写、什么条件下可以操作。比如participants表，工作人员只能看到自己所属活动的参与者，不能看到其他活动的数据。这个策略如果配错了，要么数据泄露，要么功能不可用。

-- 示例：participants 表的 RLS 策略 -- 允许工作人员查看自己所属活动的参与者 CREATE POLICY "staff_can_view_own_event_participants" ON participants FOR SELECT USING ( event_id IN ( SELECT event_id FROM staff_events WHERE staff_id = auth.uid() ) );

3.4 阶段四：核心功能开发与联调

这个阶段就是把前面设计好的页面和数据逻辑串起来。我遇到的主要问题集中在两个方面：

一是数据绑定的时机问题。WorkBuddy 的页面加载和数据请求是异步的，如果页面渲染的时候数据还没回来，就会出现空白或者报错。解决办法是在页面加载前先显示 loading 状态，等数据回来再渲染内容。WorkBuddy 提供了数据加载状态的回调，用好了能避免很多白屏问题。

二是表单提交的幂等性。签到场景下，用户可能会快速点击提交按钮，导致同一条数据被提交多次。我在 Supabase 那边加了一个唯一约束（participant_id + event_id唯一），同时在 WorkBuddy 这边做了按钮防抖处理。双保险下来，基本没出现过重复签到的情况。

3.5 阶段五：测试与问题修复

测试环节我主要做了三件事：

• 功能测试：把整个流程走一遍，从登录到签到到导出，确保每个环节都正常。
• 边界测试：比如网络断开时提交会怎样、数据为空时页面怎么显示、并发签到会不会冲突。
• 兼容性测试：在不同品牌、不同系统版本的手机上跑一遍。Android 的碎片化问题在 WebView 场景下尤其明显，后面会详细讲。

这个阶段发现的问题，大部分都是小问题，但有一个比较严重：在某些 Android 机型上，WebView 加载页面时会出现白屏，需要手动刷新才能显示。这个问题后面单独讲。

3.6 阶段六：打包上线与后续迭代

WorkBuddy 支持直接打包成 APK 或者上架到应用商店。打包之前需要准备好应用图标、启动页、隐私政策链接等材料。上架流程各个商店不太一样，但核心就是那几样：应用信息、截图、描述、隐私政策。

上线之后，我大概每两周做一次小迭代。WorkBuddy 的好处是，改完页面直接发布就行，不需要重新打包发版。但如果是涉及到原生能力的改动（比如权限、推送），还是需要重新打包。

4. 十六个坑里最值得说的几个：WebView、Supabase 和那些让人抓狂的细节

4.1 Android WebView 版本碎片化：白屏问题的根因与解法

这是我在这个项目里遇到的最头疼的问题。WorkBuddy 生成的 App 本质上是一个壳，里面用 WebView 加载 H5 页面。而 Android 系统的 WebView 版本是跟系统绑定的，不同版本差异很大。

我遇到的问题是这样的：在大部分手机上，App 运行正常。但在某些较老的 Android 机型上（特别是 Android 8.1 及以下），页面加载到一半就白屏了，控制台报错说某个 JavaScript API 不支持。

排查过程比较曲折。我先是在 WorkBuddy 的调试模式里看日志，发现是某个 ES6+ 的语法在旧版 WebView 里不支持。但 WorkBuddy 生成的代码是打包过的，我改不了源码。后来我想了个办法：在页面加载前加一个特性检测，如果检测到 WebView 版本过低，就跳转到一个简化版的页面。

// 检测 WebView 是否支持某个关键 API if (typeof Promise === 'undefined' || typeof Object.assign === 'undefined') { // 跳转到兼容版页面 window.location.href = '/fallback.html'; }

但这个方案治标不治本。真正的解决办法是在 WorkBuddy 的项目设置里，把目标 WebView 版本调低。WorkBuddy 支持配置最低支持的 WebView 版本，调低之后，它生成的代码会自动做兼容处理。这个设置藏得比较深，在"项目设置 → 高级选项 → 兼容性"里面。

提示：如果你的 App 需要覆盖较老的 Android 机型，一定要在项目初期就把 WebView 兼容性设置好。等到上线之后再来处理，成本会高很多。

4.2 Supabase 的行级安全策略：配错了就是数据泄露

Supabase 的 RLS 是个好东西，但也是个容易踩坑的地方。我一开始为了图省事，直接给所有表开了"允许所有操作"的策略。结果测试的时候发现，用 A 活动的账号登录，居然能看到 B 活动的参与者数据。这要是上线了，就是严重的数据泄露。

正确的做法是最小权限原则：每张表只开放必要的操作，而且必须带上用户身份过滤条件。比如：

-- 错误做法：允许所有人读取所有数据 CREATE POLICY "allow_all_read" ON participants FOR SELECT USING (true); -- 正确做法：只允许工作人员读取自己所属活动的数据 CREATE POLICY "staff_read_own_event" ON participants FOR SELECT USING ( event_id IN ( SELECT event_id FROM staff_events WHERE staff_id = auth.uid() ) );

另外，Supabase 的 RLS 策略是可以叠加的。如果你同时开了多条策略，Supabase 会用 OR 逻辑把它们合并起来。这意味着如果你不小心开了一条"允许所有"的策略，其他策略就形同虚设了。所以每次加策略之前，先检查一下有没有冲突的旧策略。

4.3 数据同步的实时性：轮询还是订阅

签到场景对数据实时性有一定要求：工作人员签到之后，后台最好能马上看到。Supabase 提供了实时订阅功能（Realtime），可以监听数据表的变化并推送更新。但实时订阅在移动网络下不太稳定，有时候会断连。

我最后的方案是实时订阅 + 定时轮询兜底。正常情况下用实时订阅，如果超过 30 秒没有收到更新，就触发一次轮询请求。这样既保证了实时性，又避免了断连导致的数据不同步。

// 伪代码示例：实时订阅 + 轮询兜底 let lastUpdate = Date.now(); supabase .channel('participants') .on('postgres_changes', { event: '*', schema: 'public', table: 'participants' }, (payload) => { lastUpdate = Date.now(); refreshData(payload); }) .subscribe(); // 每 30 秒检查一次，如果超过 30 秒没更新，就主动拉取 setInterval(() => { if (Date.now() - lastUpdate > 30000) { fetchLatestData(); } }, 30000);

4.4 那些让人抓狂的小问题

除了上面几个大坑，还有一些小问题也很烦人：

图标不显示：WorkBuddy 的图标库有时候会加载失败，特别是在网络不好的时候。解决办法是把用到的图标提前下载到本地，或者用 SVG 内联的方式。

字体大小不一致：不同手机的系统字体缩放设置不一样，导致页面上的文字大小不统一。解决办法是在 CSS 里用rem或者vw单位，不要用px。

返回键逻辑混乱：Android 的物理返回键在 WebView 里的行为跟原生页面不一样。有时候按返回键会直接退出 App，而不是返回上一页。这个需要在 WorkBuddy 的导航设置里配置返回键的拦截逻辑。

输入框被键盘遮挡：在表单页面，点击输入框弹出键盘后，输入框被挡住了。解决办法是在页面底部留出足够的空白，或者用scrollIntoView在输入框获得焦点时滚动页面。

5. 上线前必须检查的清单：别等到用户反馈才发现问题

5.1 功能完整性检查

上线之前，我把整个流程从头到尾走了至少五遍，每一遍都换不同的账号、不同的活动、不同的网络环境。检查项包括：

• 登录/登出是否正常
• 活动列表是否能正确加载
• 签到功能是否正常，重复签到是否有提示
• 数据导出是否完整，格式是否正确
• 权限控制是否生效，不同角色看到的内容是否不同

这个清单看起来简单，但实际做的时候很容易漏。我建议你把它写成一个 checklist，每完成一项就打个勾，不要凭记忆。

5.2 性能与体验检查

性能这块，我主要关注三个指标：

首屏加载时间是最影响用户体验的。我的优化手段主要是两个：一是把非关键的图片和资源延迟加载，二是把数据请求做成异步的，先渲染页面骨架，数据回来再填充。

5.3 安全与合规检查

安全这块，除了前面说的 RLS 策略，还有几个点要注意：

• API Key 不能硬编码在前端：Supabase 的 anon key 虽然是公开的，但也要通过环境变量注入，不要直接写在代码里。
• 敏感数据要加密：比如参与者的手机号，在数据库里存的时候最好加密，展示的时候脱敏。
• 隐私政策要齐全：如果上架应用商店，隐私政策是必须的。内容要说明你收集了哪些数据、用来做什么、怎么保护。

注意：不同应用商店对隐私政策的要求不一样，上架之前先去看一下目标商店的具体要求。有些商店还要求提供数据删除功能，这个也要提前规划。

5.4 上线后的监控与迭代

上线不是终点，而是起点。我在 Supabase 那边开了日志功能，记录所有的 API 调用和错误。WorkBuddy 这边也有基础的错误上报，可以配置一个 Webhook，把错误信息推送到我的邮箱或者即时通讯工具。

上线第一个月，我大概收到了十几条错误报告，大部分都是边缘情况，比如某个特定机型上的兼容性问题、某个特殊字符导致的提交失败。这些问题在测试阶段很难覆盖到，只能靠线上反馈来发现和修复。

6. 一些可以复用的经验：下次再做类似项目我会怎么做

6.1 项目启动阶段就要考虑的事

如果让我重新做一遍这个项目，我会在启动阶段多做三件事：

第一，先做一个最小可用的原型。不要一上来就把所有功能都搭好，先用 WorkBuddy 搭一个最简单的版本，跑通"登录 → 列表 → 详情 → 提交"这个核心链路。原型跑通之后，再往上加功能。这样能尽早发现平台的能力边界，避免做到一半发现某个功能实现不了。

第二，把数据模型设计得稍微冗余一点。我当时的表设计比较精简，后来加功能的时候发现有些字段不够用，又得改表结构。如果一开始就多留几个备用字段，后面会省事很多。

第三，提前规划好错误处理。网络请求失败、数据为空、权限不足，这些情况在开发阶段很容易被忽略，但上线之后一定会遇到。提前把这些错误状态处理好，能减少很多线上问题。

6.2 WorkBuddy 使用中的一些技巧

用了一段时间 WorkBuddy 之后，我总结了一些能提高效率的技巧：

• 善用模板：WorkBuddy 有很多现成的页面模板，比如登录页、列表页、表单页。直接套用模板比从零搭建快很多，而且模板的兼容性和体验一般都调得比较好。
• 组件复用：把常用的 UI 元素（比如按钮、卡片、标签）做成自定义组件，后面直接拖拽使用，不用每次都重新配置。
• 版本管理：WorkBuddy 支持版本历史，每次大的改动之前先保存一个版本。万一改坏了，可以快速回滚。
• 调试模式：WorkBuddy 的调试模式可以看到详细的日志和网络请求，排查问题的时候非常有用。建议在开发阶段一直开着。

6.3 关于 Supabase 的一些补充

Supabase 是个很强大的工具，但也有一些需要注意的地方：

• 免费版有资源限制：数据库大小、API 请求次数、存储空间都有限制。如果项目规模上来了，需要升级到付费版。
• 实时订阅有延迟：虽然叫"实时"，但实际上还是有几百毫秒的延迟。对实时性要求极高的场景，可能需要考虑其他方案。
• 备份很重要：Supabase 免费版不提供自动备份，需要自己定期导出数据。我当时的做法是每周手动导出一次，存到本地。

6.4 最后分享一个小技巧

如果你也在用 WorkBuddy 做项目，有一个小技巧可以帮你省很多时间：把常用的数据查询和提交逻辑封装成自定义函数。WorkBuddy 支持自定义 JavaScript 函数，你可以把 Supabase 的调用逻辑封装起来，在页面里直接调用函数名就行，不用每次都写一遍完整的 API 调用代码。

// 封装一个通用的数据查询函数 async function queryData(table, filters = {}) { let query = supabase.from(table).select('*'); for (const [key, value] of Object.entries(filters)) { query = query.eq(key, value); } const { data, error } = await query; if (error) throw error; return data; } // 页面里直接调用 const participants = await queryData('participants', { event_id: currentEventId });

这个做法不仅减少了重复代码，还让后期的维护和修改方便很多。如果查询逻辑需要调整，只需要改一个地方，不用每个页面都改一遍。

整个项目做下来，我最大的感受是：用 WorkBuddy 搭 App，技术门槛确实低了很多，但业务理解和数据设计的能力反而更重要了。因为平台帮你解决了技术实现的问题，你的精力可以更多地放在"这个功能到底该怎么设计""数据该怎么组织"这些更本质的问题上。如果你也在考虑用类似的方式做项目，希望这些经验能帮到你。