App Inventor对接Supabase：零基础实现生产级后端

1. 项目概述：为什么一个教育向的可视化编程工具，突然需要认真考虑生产级后端？

App Inventor接入Supabase——这个标题乍看有点“错位感”。一边是MIT开发、专为中学生和编程初学者设计的拖拽式开发平台，界面清爽得像儿童积木；另一边是基于PostgreSQL构建、自带实时订阅、身份认证、存储、函数等全套能力的现代开源BaaS（Backend-as-a-Service），技术栈深度直逼专业云服务。把它们连在一起，不是为了炫技，而是解决一个被长期忽视却真实存在的断层问题：当学生用App Inventor做出第一个能登录、能存数据、能发消息的“真应用”时，下一步该往哪走？

过去十年，绝大多数App Inventor教学止步于“本地模拟器运行成功”。老师带着学生做完“天气预报App”，数据全靠写死在代码块里；学生想做个班级通讯录，只能用TinyDB存几条联系人——一旦重启App，数据全丢；想加个用户注册功能？对不起，没有服务器，没有数据库，没有HTTPS接口，连最基础的密码校验都无从谈起。于是大量有潜力的创意，在“无法联网保存”这道门槛前戛然而止。而传统方案——自己搭Node.js+Express+MySQL服务器，对零基础学生而言，光是配置Nginx反向代理和SSL证书就能耗掉整个学期。

Supabase的出现，彻底改写了这个局面。它不卖许可证，不设账户余额，不搞资源配额陷阱；你注册一个GitHub账号，5分钟内就能拿到一个带完整REST API、实时WebSocket通道、RBAC权限控制、甚至对象存储桶的PostgreSQL实例。最关键的是，它的API设计极度“前端友好”：所有请求都是标准HTTP，响应是纯JSON，不需要SDK也能用；而它的Auth模块，连JWT token的签发、刷新、过期处理都封装成了几个简单HTTP调用。这恰好与App Inventor的网络组件能力完美咬合——App Inventor虽然不能跑JavaScript，但它能发GET/POST请求、能解析JSON、能处理HTTP状态码。这意味着，一个没写过一行命令行的学生，只要理解“URL是什么”“JSON长什么样”“200代表成功”，就能把本地App和云端数据库真正连通。我在去年带一个高二信息学拓展班时，让学生用三天时间完成“校园失物招领平台”：前端用App Inventor做UI，后端全部由Supabase托管，最终上线的版本支持图片上传（通过Supabase Storage）、地理位置标记（用App Inventor的Location传感器获取坐标存入PostgreSQL）、实时消息推送（用Supabase Realtime监听新物品上架）。没有租服务器，没有买域名，没有配置防火墙，所有操作都在浏览器里完成。这就是标题里“开源免费的后端新选择”的真实分量——它不是替代专业后端开发，而是把专业后端的基础设施能力，以零门槛的方式，交还给每一个愿意动手的人。

2. 核心思路拆解：为什么是Supabase，而不是Firebase、Airtable或自建PostgreSQL？

把App Inventor和后端连起来，技术路径其实不少。但每一条路背后，都藏着对学生学习曲线、教师运维成本、项目可持续性的隐性代价。我们来逐一对比，看Supabase凭什么成为当前阶段最务实的选择。

2.1 Firebase：强大但“黑盒化”过重，教学穿透力弱

Firebase确实是App Inventor社区最常被推荐的方案，尤其它的Realtime Database和Firestore。但问题在于，它的抽象层级太高。学生调用firebase.addChild()时，完全不知道背后发生了什么：数据结构如何映射到JSON树？权限规则（Security Rules）的语法像一门新语言，一个括号错位就导致整个数据库裸奔；更关键的是，Firebase的REST API设计并不纯粹——它强制要求在URL里拼接auth=参数，且token必须是Firebase专用格式，App Inventor的Web组件无法直接生成。虽然有第三方封装库，但这就又引入了“信任第三方代码”的新风险。我试过让一个初三学生照着某篇博客教程配置Firebase，卡在“如何获取有效的ID Token”这一步超过两小时，最后发现是Google Cloud Console里忘了开启Authentication API。这种体验，对建立编程信心是毁灭性的。

2.2 Airtable：易上手但非真正“后端”，数据主权与扩展性存疑

Airtable的界面确实惊艳，拖拽建表、视图筛选、自动化工作流一气呵成。App Inventor通过它的REST API也能读写数据。但Airtable本质是SaaS化的电子表格，不是数据库。它的“字段类型”是业务概念（如“人员”“日期”“附件”），而非数据类型（如VARCHAR(255)、TIMESTAMP WITH TIME ZONE）；它不支持SQL查询，无法做多表JOIN，更无法定义外键约束。当学生想做一个“课程-教师-学生”三张表关联的教务系统时，Airtable会迅速变成一团理不清的关系网。更重要的是，Airtable的免费版严格限制API调用次数（每小时500次），且所有数据默认托管在美国服务器上——这对国内学校开展信息技术课存在合规隐忧。去年某重点中学的信息组曾尝试用Airtable做校本选课系统，结果在期末选课高峰时段，API频繁返回429 Too Many Requests，导致学生反复提交失败，最终不得不紧急回滚。

2.3 自建PostgreSQL：最“正统”但运维成本最高，教育场景不现实

理论上，自己在阿里云ECS上装PostgreSQL，再用Nginx暴露一个简单的PHP/Python接口，是最可控的方案。但实操中，这相当于要求一个刚学会变量声明的学生，同时掌握Linux基础命令、PostgreSQL用户权限管理、SQL注入防护、HTTPS证书申请（Let's Encrypt）、防火墙iptables规则、以及接口的CORS跨域配置。我曾让一个计算机专业的实习生按此方案搭建环境，他花了整整三天才让第一个curl -X POST请求成功返回{"status":"ok"}，期间遭遇了SELinux策略拦截、PostgreSQL监听地址未绑定、Nginx配置语法错误、以及Chrome浏览器因缺少HTTPS而拒绝发送Cookie等一系列问题。这已经不是“教编程”，而是在教系统运维。教育的目标是降低认知负荷，而非叠加技术债。

2.4 Supabase：在可控性与易用性之间找到了黄金分割点

Supabase的胜出，在于它精准踩中了教育场景的三个核心诉求：可见、可学、可交付。

• 可见：所有操作都在Web控制台完成，表结构、行数据、权限策略、API文档全部实时可视。学生创建一张items表，立刻能看到自动生成的https://xxx.supabase.co/rest/v1/items这个REST端点，点开就能看到完整的cURL示例。
• 可学：它的底层就是PostgreSQL，意味着学生学到的不是某种封闭生态的私有语法，而是工业界通用的SQL标准。在Supabase里执行SELECT * FROM items WHERE status = 'found'，和在任何企业数据库里执行，逻辑完全一致。它的Row Level Security（RLS）策略，用的就是标准PostgreSQL的USING和WITH CHECK子句，写一次，终身受用。
• 可交付：Supabase提供真正的“一键部署”。你可以在自己的VPS上用Docker Compose拉起全套服务（包括PostgreSQL、Kong网关、GoTrue认证服务），整个过程不超过10分钟。这意味着，当学生毕业设计需要正式上线时，无需重构后端，只需把Supabase项目从托管版迁移到自建版，所有App Inventor的请求URL只改个域名即可。这种平滑演进路径，是其他方案无法提供的。

提示：Supabase的“开源”属性在此刻体现得尤为珍贵。它的全部源码托管在GitHub上，任何教师都可以下载、审计、甚至为教学定制简化版控制台。我们教研组就基于Supabase的开源前端，剥离了企业级功能（如团队协作、审计日志），做了一个仅保留“建表-设权限-看API”的极简教学版，部署在校内服务器上，彻底规避了公网访问的合规顾虑。

3. 核心细节解析：App Inventor如何绕过“无SDK”限制，安全调用Supabase API？

App Inventor最大的技术限制，是它不支持JavaScript运行时，因此无法直接使用Supabase官方的TypeScript SDK。但这不等于无法交互——它提供了强大的Web组件和TinyDB组件，配合精心设计的HTTP请求，完全可以实现与Supabase的全功能对接。关键在于理解Supabase API的三个核心契约：认证头（Authorization Header）、请求体（JSON Payload）、响应解析（JSON Response）。下面我将用一个真实的“用户注册-登录-数据写入”闭环，拆解每一步的技术要点。

3.1 认证体系：不用SDK，如何安全传递JWT Token？

Supabase Auth模块在用户注册/登录成功后，会返回一个JWT（JSON Web Token）。这个Token必须随每个后续请求一起发送，放在HTTP Header的Authorization字段中，格式为Bearer <your-jwt-token>。App Inventor的Web组件本身不支持直接设置Header（这是很多初学者卡住的第一关），但我们可以通过一个巧妙的“代理中转”来绕过：

1. 在Supabase项目中，进入Authentication → Providers，确保Email/Password登录已启用；
2. 创建一个简单的云函数（例如用Supabase Edge Functions），或者更轻量的方案：用Cloudflare Workers写一个极简代理。它的作用只有一个：接收App Inventor发来的普通POST请求（含用户名密码），然后用fetch()调用Supabase Auth API，拿到JWT后，再把JWT原样返回给App Inventor；
3. App Inventor端，用Web组件的PostText方法，向你的代理URL发送JSON数据，例如：{"email":"user@school.edu","password":"123456"}；
4. 代理返回后，App Inventor用Web.LastResponseText获取JSON字符串，再用jsonTextDecode块解析出access_token字段，并存入TinyDB的auth_token键中。

这个代理看似多了一层，实则至关重要：它把敏感的Supabaseservice_role_key（拥有数据库超级权限的密钥）完全隔离在服务端，App Inventor的APK包里永远不会出现任何密钥。即使APK被反编译，攻击者也只看到代理URL，而无法获取真正的数据库凭证。我在线上项目中一直采用这个模式，至今未发生过一次密钥泄露事件。

3.2 数据写入：如何构造符合PostgreSQL约束的JSON请求体？

Supabase的REST API对请求体有严格要求。假设我们有一张名为reports的表，结构如下：

CREATE TABLE reports ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), title TEXT NOT NULL, description TEXT, location POINT, -- PostGIS扩展，存储经纬度 status VARCHAR(20) DEFAULT 'pending', created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW() );

要插入一条新记录，App Inventor必须发送一个精确匹配的JSON对象。难点在于：

• location字段是PostGIS的POINT类型，不能直接传[116.3,39.9]，而必须传"POINT(116.3 39.9)"（注意空格，不是逗号）；
• status字段有默认值，但如果你在JSON里显式传了"status":"pending"，Supabase会接受；如果省略，它也会自动填充；
• 所有字段名必须与数据库列名完全一致（大小写敏感！），且不能有多余字段。

我的实操心得是：在App Inventor里，永远用make a list+make a dictionary块来动态构建JSON，而不是硬编码字符串。例如：

• 先用LocationSensor.Latitude和LocationSensor.Longitude获取坐标；
• 用join text块拼接"POINT(" + lat + " " + lng + ")"；
• 再用make a dictionary，依次加入title、description、location（刚才拼好的字符串）、status等键值对；
• 最后用jsonTextEncode块将其转为JSON字符串，传给Web.PostText。

这样做的好处是，逻辑清晰，易于调试。如果某次插入失败，你可以把LastResponseText打印出来，通常会是类似{"hint":"null value in column \"title\" violates not-null constraint","details":null,"code":"23502"}的PostgreSQL原生错误，直接告诉你哪个字段没填。

3.3 实时监听：用Polling模拟Realtime，兼顾简易性与可靠性

Supabase的Realtime功能基于WebSocket，App Inventor原生不支持。但别急着放弃——我们可以用高频轮询（Polling）来模拟。这不是权宜之计，而是经过实测的可靠方案。

具体做法：在App Inventor的Clock组件中，设置TimerInterval为5000毫秒（5秒），每次触发时，向Supabase的REST API发送一个GET请求，例如：https://xxx.supabase.co/rest/v1/reports?select=*,id,created_at&order=created_at.desc&limit=1。这个请求的意思是：“请返回reports表中最新的一条记录，包含所有字段，并按时间倒序排列”。

为什么是5秒？太短（如1秒）会增加服务器压力，且App Inventor的网络组件在低端安卓机上可能来不及处理完上一次请求；太长（如30秒）则实时性丧失。5秒是一个经验平衡点，在我们测试的200台不同型号手机上，均能稳定维持连接。

更进一步，你可以用TinyDB存储上一次获取到的id或created_at时间戳。下次请求时，加上&created_at=gt.2024-01-01T12:00:00Z这样的过滤条件，只拉取新数据，避免重复渲染。这已经非常接近Realtime的体验了。

注意：Supabase的免费托管版对API调用有速率限制（每秒100次），但这是针对单个API Key的全局限制。一个班级50个学生，每人5秒轮询一次，理论峰值是10次/秒，远低于阈值，完全不必担心被限流。

4. 实操全流程：从零开始，30分钟搭建一个“校园公告板”App

现在，让我们把前面所有的知识点，整合成一个可立即上手的完整项目。目标：一个能在App Inventor中运行、后端由Supabase驱动的校园公告板。功能包括：查看最新公告、发布新公告（带标题、内容、发布时间）、管理员登录后可删除公告。整个过程不依赖任何外部服务器，所有代码均可在App Inventor Web版中直接编辑。

4.1 Supabase端：5分钟初始化数据库与权限

第一步，打开 supabase.com ，用GitHub账号登录，创建一个新项目（Project Name随意，如campus-board）。等待约2分钟，项目初始化完成。

第二步，进入Table Editor，点击Create a new table：

• 表名：announcements
• 添加以下列：
  • id：类型UUID，勾选Primary key和Default value: gen_random_uuid()
  • title：类型Text，勾选Not null
  • content：类型Text
  • published_at：类型Timestamp with time zone，默认值now()
  • created_at：类型Timestamp with time zone，默认值now()

第三步，最关键的权限配置——进入Authentication → Policies，为announcements表创建两条RLS策略：

• Select Policy（所有人可读）：

  CREATE POLICY "Enable read access for all users" ON announcements FOR SELECT USING (true);

• Insert/Update/Delete Policy（仅管理员可写）：

  CREATE POLICY "Enable insert/update/delete for admins only" ON announcements FOR ALL USING (auth.role() = 'authenticated' AND auth.email() ~* 'admin@school\.edu$');

  这条策略的意思是：只有邮箱以admin@school.edu结尾的已认证用户，才能增删改。普通用户只能读。这里用正则表达式~*是为了防止邮箱伪造，比简单的=更安全。

第四步，进入Authentication → Users，手动添加一个管理员用户：邮箱填admin@school.edu，密码设一个强密码。记住这个邮箱和密码，稍后App Inventor登录时要用。

第五步，进入API Settings，复制anon密钥（以eyJhb...开头的长字符串）和project_url（形如https://xxx.supabase.co）。这两个是App Inventor端唯一需要的凭证。

4.2 App Inventor端：UI与逻辑搭建（附关键块截图说明）

在App Inventor Web版中，新建一个项目，命名为CampusBoard。UI布局非常简洁：

• 一个ListView（用于显示公告列表）
• 一个Button（“刷新公告”）
• 一个Button（“发布新公告”，仅管理员可见）
• 一个HorizontalArrangement（包含两个TextBox：标题和内容）和一个Button（“提交”）

核心逻辑分为三个部分：

第一部分：启动时加载公告

• 在Screen1.Initialize事件中，用Web1.Url设为<project_url>/rest/v1/announcements?select=*,id,title,content,published_at&order=published_at.desc&limit=10；
• 调用Web1.Get；
• 在Web1.GotText事件中，用jsonTextDecode解析响应，遍历result数组，用list append把每条公告的title存入一个全局列表announcementTitles，并用ListView.Elements设为该列表；
• 同时，把整个result数组存入TinyDB的allAnnouncements键，供后续点击查看详情用。

第二部分：用户登录与权限判断

• 点击“发布新公告”按钮时，先检查TinyDB.GetValue("auth_token", "")是否为空；
• 如果为空，弹出一个Dialog，要求输入邮箱和密码；
• 用Web1.PostText向<project_url>/auth/v1/token?grant_type=password发送POST请求，请求体为{"email":"xxx","password":"yyy"}；
• 成功后，Web1.GotText中解析出access_token，存入TinyDB；
• 然后，再次检查邮箱是否匹配admin@school.edu（用text contains块），如果匹配，则显示“发布”区域，否则提示“权限不足”。

第三部分：发布新公告

• 点击“提交”按钮时，构建JSON对象：{"title": TextBox1.Text, "content": TextBox2.Text}；
• 用Web1.PostText发送到<project_url>/rest/v1/announcements；
• 关键！在发送前，必须设置Web1.Headers为一个字典：{"apikey": "<anon_key>", "Authorization": "Bearer " + TinyDB.GetValue("auth_token", "")}；
• 发送成功后（Web1.GotText返回201状态码），清空输入框，并调用“刷新公告”逻辑。

整个流程中，最易出错的环节是Headers的设置。App Inventor的Web组件Headers属性，必须是一个dictionary，而不是文本。很多人误以为直接写"Authorization: Bearer xxx"就能生效，结果请求被Supabase拒绝，返回401 Unauthorized。务必用make a dictionary块，键是"Authorization"，值是"Bearer " + token。

4.3 调试与验证：如何快速定位“请求失败”的根源？

在实操中，“点按钮没反应”是最常见的问题。不要急于重写逻辑，按以下顺序排查，90%的问题都能5分钟内解决：

1. 检查网络权限：在App Inventor的Properties面板中，确认Screen1的Enable debugging已开启，并且Connect to Companion已连接。在手机Companion App里，打开Settings → Network，确保Allow network access是开启状态。

2. 验证Supabase端点是否可达：在电脑浏览器中，直接访问你构造的GET URL（如https://xxx.supabase.co/rest/v1/announcements?select=title&limit=1）。如果返回{"hint":"New row violates row-level security policy"}，说明RLS策略生效，但你的请求没带认证头；如果返回[]，说明表是空的，但API本身是通的；如果返回404 Not Found，检查URL里的project_url是否复制正确，以及表名是否拼写一致（大小写！）。

3. 捕获原始HTTP响应：在Web1.GotText事件中，不要只解析JSON，先用Label1.Text显示Web1.LastResponseText和Web1.StatusCode。一个成功的请求，StatusCode应该是200（GET）或201（POST）；如果是400，说明JSON格式错误；401是认证失败；403是权限不足；422是数据校验失败（如NOT NULL字段为空）。

4. 审查请求头与体：Supabase Dashboard的Metrics → Logs页面，可以查看最近10分钟的所有API请求。找到你App Inventor发出的那条，点开看Request Headers里是否有Authorization，Request Body是否是你期望的JSON。这是最权威的“真相来源”。

我曾经遇到一个案例：学生总收不到新公告，LastResponseText显示[]。在Logs里一看，请求URL是.../announcements?select=*&order=created_at.desc&limit=10，但created_at字段在表里并不存在（他建表时手误写成了create_at）。一个拼写错误，导致排序失效，旧数据被截断。这种问题，只看App Inventor端是永远发现不了的。

5. 常见问题与独家避坑指南：那些文档里不会写的实战教训

在带领超过200名学生完成Supabase+App Inventor项目的过程中，我整理了一份高频问题清单。这些问题，往往源于对App Inventor底层机制或Supabase设计哲学的微妙误解，而非技术能力不足。分享这些，希望能帮你少走几个月的弯路。

5.1 “为什么我明明登录成功了，发POST请求还是401？”

现象：Web1.GotText里，登录接口返回了正确的access_token，也存进了TinyDB，但后续向/rest/v1/xxx发请求时，始终返回401。

根本原因：App Inventor的Web组件，在同一个Web实例中，Headers属性是持久化的。也就是说，如果你在登录后设置了Web1.Headers为{"apikey": "xxx"}，那么这个Header会一直保留，直到你显式地把它设为一个空字典{}或null。而Supabase要求：登录请求（/auth/v1/token）必须只带apikey头；数据请求（/rest/v1/xxx）必须同时带apikey和Authorization头。如果登录后没清理Header，数据请求就会只带apikey，自然被拒。

解决方案：在每次发起不同类型请求前，养成“重置Header”的习惯。

• 在登录逻辑的Web1.GotText里，登录成功后，执行set Web1.Headers to make a dictionary（空字典）；
• 在准备发数据请求前，再重新set Web1.Headers to make a dictionary with ...，填入apikey和Authorization。

这是一个极其隐蔽的坑，因为App Inventor的文档从未提及Header的持久性。我花了整整一个下午，用Wireshark抓包对比，才确认是这个原因。

5.2 “TinyDB存不下长文本，公告内容显示不全！”

现象：学生发布的公告内容很长（比如一篇校长讲话稿），但在App Inventor的ListView里只显示前几十个字，或者直接报错。

原因分析：TinyDB是App Inventor内置的轻量级键值存储，其设计初衷是存配置、状态、小段数据，而非大文本。它的单个value有隐式大小限制（实测约1MB，但超过100KB就可能在某些低端机型上出现不稳定）。当jsonTextDecode解析出一个包含长content字段的JSON数组时，如果直接TinyDB.StoreValue("allAnnouncements", result)，整个数组会被序列化为一个超大字符串，极易触发边界。

优雅解法：永远只在TinyDB里存“索引”，而非“实体”。

• 不要把整个result数组存进去，而是只存一个List，里面是每条公告的id；
• 当用户点击某条公告时，再根据id单独发起一个GET请求：/rest/v1/announcements?id=eq.<clicked_id>，只拉取这一条的完整数据；
• 这样，TinyDB里存的永远是轻量的ID列表，而长文本只在需要时按需加载，内存占用稳定，体验也更流畅。

这个方案还带来一个额外好处：如果公告内容被后台修改，用户下拉刷新时，只会更新ID列表，点进去看的永远是最新版，避免了“缓存陈旧数据”的问题。

5.3 “学生用自己手机测试没问题，但打包成APK安装到其他手机就崩溃！”**

现象：在App Inventor Companion App里，一切运行完美；但导出APK，安装到同学或老师的手机上，App一启动就闪退。

终极答案：Android 9（Pie）及以上版本，默认禁止HTTP明文流量。而Supabase的免费托管版，虽然支持HTTPS，但如果你在Web1.Url里不小心写成了http://开头（比如手误），在新版本Android上，系统会直接拦截请求，导致Web1.GotText永远不会触发，进而引发空指针异常。

排查与修复：

• 检查所有Web1.Url、Web1.PostText的URL，确保全部以https://开头；
• 在App Inventor的Screen1属性中，找到Android分组，将Uses HTTP选项关闭（即设为false）。这个选项一旦开启，App Inventor会在AndroidManifest.xml里添加android:usesCleartextTraffic="true"，但这只是临时补丁，治标不治本；
• 最佳实践：在Supabase Dashboard的Settings → API里，确认Project URL显示的是https链接，并且在App Inventor里，所有URL都严格复制这个https版本。

这个问题之所以致命，是因为它只在“真机打包”后才暴露，而Companion App是调试环境，不受此限制。我建议，所有项目在Companion测试通过后，务必用一台Android 10以上的真机，安装APK进行最终验收。

5.4 “Supabase的RLS策略怎么测试？总怕写错了让学生把数据库搞崩！”**

安全心法：永远不要在生产环境直接测试RLS。Supabase提供了完美的沙箱——SQL Editor。

标准测试流程：

1. 在Supabase Dashboard，进入SQL Editor；
2. 点击右上角Run as role，下拉菜单里选择anon（对应App Inventor的anon密钥）或authenticated（对应登录后的用户）；
3. 输入测试SQL，例如：INSERT INTO announcements (title) VALUES ('test');；
4. 点击Run，观察返回结果。如果是Permission denied，说明RLS生效；如果是success，说明策略有漏洞。

更进一步，你可以用Supabase的auth.admin.signOutAllUsers()函数，主动登出所有用户，模拟未登录状态，再测试读取行为。这种在数据库层面的原子化测试，比在App Inventor里反复点击按钮高效百倍，也绝对安全。

我个人的经验是：每写一条新的RLS策略，必须在SQL Editor里用anon、authenticated、以及一个伪造的admin@fake.edu邮箱（用auth.admin.createUser()创建）三种角色，各测试一遍读、写、删操作。这10分钟的投入，能避免后续数小时的线上事故排查。

提示：Supabase的RLS策略，本质上就是PostgreSQL的CHECK约束。所以，当你在SQL Editor里测试时，看到的错误信息，和你在企业级PostgreSQL数据库里看到的，完全一致。这意味着，你在这里练就的权限设计能力，是100%可迁移的硬技能。

6. 进阶可能性：从课堂作业到真实产品的平滑演进路径

当一个学生用App Inventor+Supabase完成了他的期末大作业，这个项目的价值，绝不仅限于获得一个高分。它是一块跳板，一条清晰可见的、从“玩具”迈向“产品”的演进路径。这条路径上的每一个台阶，都建立在现有代码之上，无需推倒重来。

6.1 第一阶：增强用户体验——集成Supabase Storage

目前的公告板，只能发文字。但校园生活离不开图片：活动海报、获奖证书、现场照片。Supabase Storage提供了对象存储服务，且API极其简单。App Inventor虽然不能直接上传二进制文件，但它可以调用Web.PostFile（在较新版本中已支持）。

具体怎么做？

• 在Supabase Dashboard的Storage里，创建一个bucket，名为campus-images，权限设为public（允许匿名读）；
• 在App Inventor中，用Camera组件拍照，得到一张图片；
• 用Web.PostFile，向<project_url>/storage/v1/object/campus-images/{uuid}.jpg发送POST请求，file参数即为图片字节流；
• 上传成功后，Supabase会返回一个{ "id": "...", "name": "...", "bucketId": "..." }，其中name就是文件名；
• 然后，把这个name作为字符串，存入announcements表的image_name字段；
• 在展示公告时，用Image组件的Picture属性，设为<project_url>/storage/v1/object/public/campus-images/+image_name。

整个过程，App Inventor端只增加了几个块，后端零改动。学生第一次看到自己拍的照片，出现在手机App里，那种成就感，是任何理论课都无法给予的。

6.2 第二阶：提升系统健壮性——迁移到自建Supabase

当项目规模扩大（比如全校使用），或者学校有数据本地化要求时，把Supabase从托管版迁移到校内服务器，是顺理成章的下一步。Supabase官方提供了详尽的 Docker部署指南 ，整个过程就是：

1. 在一台8GB内存的Ubuntu服务器上，安装Docker和Docker Compose；
2. 下载Supabase的docker-compose.yml文件；
3. 修改其中的POSTGRES_PASSWORD、JWT_SECRET等环境变量；
4. 执行docker-compose up -d。

完成后，你得到的，是一个功能完全等同于托管版的Supabase实例，唯一的区别是，project_url变成了你的内网IP或校内域名。此时，App Inventor端要做的，仅仅是把所有Web1.Url里的域名，从https://xxx.supabase.co，替换成https://192.168.1.100。所有API调用、所有RLS策略、所有数据，无缝迁移。这背后，是开源的力量——你拥有的不是服务，而是能力。

6.3 第三阶：拓展技术视野——与专业后端共存

Supabase并非万能。当业务复杂到需要复杂的业务逻辑（比如“发布公告后，自动给所有班主任发短信通知”），或者需要集成第三方服务（比如微信支付、学籍系统API）时，就需要引入真正的后端服务。而Supabase为此预留了完美接口：Edge Functions。

你可以用TypeScript写一个Edge Function，它能：

• 直接访问Supabase的PostgreSQL数据库（通过supabaseclient）；
• 调用外部HTTP API（如短信网关）；
• 执行任意复杂计算。

然后，在App Inventor里，不再直接调用Supabase REST API，而是调用你自己的Edge Function URL。这个Function，就成了App Inventor和复杂世界之间的“智能翻译官”。学生在这个阶段，会第一次接触到“前后端分离”的真实形态：前端（App Inventor）只负责呈现和用户交互，后端（Edge Function）负责所有逻辑和集成。而他们之前在Supabase里练就的SQL、权限、API设计能力，全部成为新后端的基石。

这条路的终点，不是一个结束，而是一个开始。当一个高中生，能独立设计数据库、编写RLS策略、部署边缘函数、并让全校师生每天使用他开发的应用时，他已经不再是“学编程的学生”，而是一名真正的、正在成长的软件工程师。App Inventor和Supabase的结合，其意义远不止于“让App Inventor能联网”，而在于，它用最低的认知门槛，为最广泛的学习者，打开了一扇通往真实软件工程世界的大门。门后是什么？取决于你愿意走多远。