前端秒变全栈Vue3 Supabase 三小时交付完整应用后端一行不写【免费下载链接】supabaseThe Postgres development platform. Supabase gives you a dedicated Postgres database to build your web, mobile, and AI applications.项目地址: https://gitcode.com/GitHub_Trending/supa/supabase我只写前端后端怎么办这是无数 Vue 开发者在个人项目、独立出海、内部工具、黑客松 Demo 上反复撞见的墙。传统方案要么引入 Node 服务端把工程复杂度翻倍要么使用云函数把逻辑拆得七零八落要么退回 Firebase 接受锁死生态和 SQL 能力阉割。Supabase 给出的答案是另一条路让 PostgreSQL 自己成为后端。它把数据库、REST API、实时订阅、认证、对象存储和边缘函数打包成一套开箱即用的 BaaS前端只要装一个 JS SDK 就能拿到完整的后端能力。这个定位让它在 2025–2026 年踩中了风口——社区讨论中它被称作Vibe Coding 的默认后端估值已突破百亿美元还以 1.5 亿美元融资收购了数据库公司 Turso把目光投向AI 智能体需要数百万个独立数据库的下一程。本文不再复述营销话术而是直接打开 Supabase 官方仓库supabase/supabase中真实的 Vue 3 示例代码从项目初始化、数据库表设计、认证、CRUD、文件存储到本地联调与上线部署把三小时交付完整应用的完整链路拆给你看并交代每一环背后为什么能这么省的机制原理。一张表就是一套 APIBaaS 的底气从哪来先看仓库里最核心的示例examples/user-management/vue3-user-management。这是一个官方维护的完整 Vue 3 用户管理应用功能清单极其克制却覆盖了全栈应用的三大命脉通过 Magic Link邮箱魔法链接登录无需密码读取、更新用户档案数据数据库 CRUD上传、回显头像图片对象存储。整个项目的前端依赖只有两个见 package.jsondependencies: { supabase/supabase-js: ^2, vue: ^3.5.30 }没有 Express、没有 ORM、没有鉴权中间件。后端能力的秘密藏在架构里Supabase 在 PostgreSQL 之上叠了一层PostgREST——一个把数据库表直接暴露为 RESTful API 的网关。你在数据库里建一张表PostgREST 就自动生成GET/POST/PATCH/DELETE端点你在表上定义行级安全RLS策略这个 API 就自带权限语义。前端拿到的supabase.from(profiles).select(...)这样的链式调用底层打的正是这些自动生成的 HTTP 接口。这也解释了为什么仓库的 Docker 自托管编排docker/docker-compose.yml里躺着十来个相互咬合的服务Studio 控制台、基于 Envoy 的 API 网关api-gw、负责 JWT 认证的authGoTrue、把 Postgres 变成 REST API 的 PostgREST、负责 WebSocket 广播的 Realtime、对象存储 Storage、连接池 Supavisor 等等。开发者感知到的一个 BaaS其实是一套企业级开源组件堆叠出的平台——这也是它与 Firebase 最本质的区别底层是标准 SQL 和你能完全掌控的 Postgres。第一步脚手架、环境变量与数据库表设计按官方 Quickstartapps/docs/content/guides/getting-started/quickstarts/vue.mdx的流程从零初始化一个 Vue 应用只需三行命令npm create vitelatest supabase-vue-3 -- --template vue cd supabase-vue-3 npm install supabase/supabase-js然后把项目 URL 与 publishable key 写入.env参考示例中的 .env.exampleVITE_SUPABASE_URLhttps://your-project-ref.supabase.co VITE_SUPABASE_PUBLISHABLE_KEYyour-publishable-key初始化客户端的代码全项目只有五行的量级见 src/supabase.jsimport { createClient } from supabase/supabase-js const supabaseUrl import.meta.env.VITE_SUPABASE_URL const supabasePublishableKey import.meta.env.VITE_SUPABASE_PUBLISHABLE_KEY export const supabase createClient(supabaseUrl, supabasePublishableKey)值得注意这两个变量会暴露在浏览器里官方文档对此的注释是这没问题因为数据库开启了行级安全RLS。这句话是整篇文章的安全主线后面会展开。接下来是整条链路里唯一一次写后端的环节——但用的不是编程语言而是 SQL。示例 READMEREADME.md给出了完整的建表脚本核心是一张profiles表create table profiles ( id uuid references auth.users not null, updated_at timestamp with time zone, username text unique, avatar_url text, website text, primary key (id), unique(username), constraint username_length check (char_length(username) 3) );三个细节值得工程师品一品主键直接引用auth.usersid是 UUID 且外键指向 Supabase 内置的认证用户表登录用户与业务数据的绑定关系由数据库约束兜底约束写在数据库里username唯一、长度不小于 3这类校验不需要前端或中间层重复实现任何绕过 UI 的请求都在数据库层被拦截表结构即 API 契约建完表PostgREST 立即暴露对应的 REST 端点select、insert、update全部可用——这就是后端一行不写的字面含义。建表动作既可以在云端的 SQL Editor 里执行也可以在本地supabase migration new生成的迁移文件中维护后者让表结构像前端代码一样进入版本管理。认证打通Magic Link 登录与登录态管理认证是新手最容易写崩的部分密码哈希、会话令牌、过期刷新、安全 Cookie……Supabase Auth 把这些全部内置。示例使用邮箱魔法链接前端交互代码只有Auth.vue一个组件src/components/Auth.vueconst handleLogin async () { try { loading.value true const { error } await supabase.auth.signInWithOtp({ email: email.value }) if (error) throw error alert(Check your email for the login link!) } catch (error) { if (error instanceof Error) { alert(error.message) } } finally { loading.value false } }用户提交邮箱后Auth 服务签发一次性链接发送到邮箱点击即完成登录。而当前是否已登录的全局状态由 src/App.vue 监听维护onMounted(() { supabase.auth.getClaims().then(({ data }) { claims.value data.claims }) supabase.auth.onAuthStateChange(async () { const { data } await supabase.auth.getClaims() claims.value data.claims }) })Account v-ifclaims :claimsclaims / Auth v-else /getClaims()读取 JWT 中的声明onAuthStateChange订阅登录/登出事件——登录态在页面刷新、跨标签页、Token 过期等场景下都由 SDK 自动维护。需要社交登录时官方仓库还提供了 GitHub OAuth 的完整配置流程社区文章对此也有大量实践原理一致在 GitHub 侧创建 OAuth App把回调地址填进 Supabase 控制台前端一行signInWithOAuth即可。这里有一层值得 Vue 开发者留意的机制JWT 的sub声明用户 UUID与数据库 RLS 中的auth.uid()是同一枚 Token 的两种读取视角。前端从claims.sub拿用户 ID 去查询自己的档案数据库策略用auth.uid()校验请求归属——两端基于同一签名体系这就是无需后端代码却能完成身份鉴权的底层密码。CRUD 与安全底线RLS 是一切的根基登录之后档案的读取与更新落在 src/components/Account.vue两段代码分别是读和写let { data, error, status } await supabase .from(profiles) .select(username, website, avatar_url) .eq(id, claims.value.sub) .single()const updates { id: claims.value.sub, username: username.value, website: website.value, avatar_url: avatar_url.value, updated_at: new Date(), } let { error } await supabase.from(profiles).upsert(updates)select加.eq(id, ...)过滤、upsert一键插入或更新——标准的前端链式调用没有一行服务端逻辑。但真正决定谁能读、谁能写的是建表时跟着写下的那三条 RLS 策略alter table profiles enable row level security; create policy Public profiles are viewable by everyone. on profiles for select using ( true ); create policy Users can insert their own profile. on profiles for insert with check ( (select auth.uid()) id ); create policy Users can update own profile. on profiles for update using ( (select auth.uid()) id );语义一目了然档案公开可读只有auth.uid()等于记录id的用户本人能插入和更新自己的档案。RLS 是 Postgres 原生机制策略在数据库内部执行任何途径REST API、直接 SQL 连接、未来新增的客户端都无法绕过——这正是publishable key 可以安全暴露在浏览器里的前提。反过来忽略这一层就会付出真实代价2025 年 UpGuard 安全团队的研究发现全网有16,326 个 Supabase 项目暴露了公开可读取的数据库表其中不少包含个人数据TechCrunch 等媒体对此做了报道。这些项目的共性失误高度一致——建了表、接入了 SDK却忘了enable row level security和策略。把 RLS 当作可选的进阶功能是 BaaS 时代最危险的认知偏差在你写下create table之后的第一件事就应该是打开 RLS。文件存储三行代码搞定头像上传档案里还躺着一个avatar_url字段对应存储层的能力。头像上传组件 src/components/Avatar.vue 展示了 Storage 的完整闭环——上传与下载let { error: uploadError } await supabase.storage .from(avatars) .upload(filePath, file)const { data, error } await supabase.storage .from(avatars) .download(path.value) src.value URL.createObjectURL(data)上传用的是随机文件名下载后在浏览器侧URL.createObjectURL生成本地预览避免每次渲染都走一遍网络。桶Bucket的权限同样在 SQL 中声明insert into storage.buckets (id, name) values (avatars, avatars); create policy Avatar images are publicly accessible. on storage.objects for select using ( bucket_id avatars ); create policy Anyone can upload an avatar. on storage.objects for insert with check ( bucket_id avatars );Storage 对公众开放读头像需要公开访问、放行登录用户上传权限模型和数据库表完全一致地由策略驱动。更进阶的做法是把上传 URL 签名化、给对象加防盗链或接入 CDN 做边缘缓存——能力都在只是按需开启。至此认证、CRUD、文件存储三大件已经全部打通。把Auth、Account、Avatar三个组件组装进App.vuenpm run dev启动 Vite 开发服务器浏览器打开localhost:5173一个完整的用户管理应用就出现在眼前——这正是官方教程with-vue-3.mdx里At this stage you have a fully functional application!的由来。顺带一提这套用户管理脚手架在仓库里以九种技术栈平行存在——React、Svelte、Swift、Flutter、Angular、Ionic乃至 Solid 和 Nuxt——它们共享同一套数据库、同一份 RLS 策略、同一套 Storage 配置。后端能力与前端框架彻底解耦这是前端秒变全栈最有力的注脚你学的不是某个框架绑定的后端而是一套可复用的后端资产。从本地联调到上线部署两条路线都讲清楚应用写完了接下来是工程师最关心的最后一公里。Supabase 给了两条部署路线恰好对应不同的控制欲与运维成本。路线 A托管云默认路径。在控制台创建项目、执行建表 SQL、拿到 URL 和 key 之后前端npm run build产出静态资源部署到任意静态托管Vercel、Netlify、自有服务器即可。数据库、Auth、Storage 全部由平台托管自动备份、免运维。这也是三小时交付最顺滑的路径——本地开发与生产环境共享同一套 API除了环境变量不同代码路径完全一致。路线 B自托管Docker Compose。仓库根目录的 docker/ 提供了官方自托管编排。它把完整服务栈收进一份docker-compose.ymlStudio 控制台、Envoy API 网关、Auth、PostgREST、Realtime、Storage、Postgres 元数据管理、Postgres 本体、Edge Runtime、日志链路Logflare Vector和连接池 Supavisor。社区里的 Windows 部署与本地联调文章走的也是这条路——装好 Docker 与 Supabase CLIsupabase start即可拉起本地实例.env指向localhost完成联调。日常运维则被封装成脚本docker/run.shsh run.sh start # docker compose up -d --wait sh run.sh status # docker compose ps sh run.sh logs auth # 跟踪指定服务日志 sh run.sh secrets # 打印密钥与 API Key sh update.sh # 备份后升级整套服务自托管的代价在 docker/README.md 里被写得很直白——默认配置不安全不能直接上生产必须更换所有默认密码与密钥、复查 CORS 配置、在服务前方架设 HTTPS 反向代理、并建立备份机制。托管云替你承担了这部分运维风险自托管则把控制权与责任同时交还给你。对大多数个人项目和早期产品路线 A 是正确的默认选择对数据主权敏感或需要深度定制的场景路线 B 才是答案。三小时背后的工程真相复盘整条链路会发现三小时交付不是营销话术而是有清晰机制支撑的工程事实表即 APIPostgREST 把 DDL 变成 REST 端点省掉一整层路由与序列化代码数据库内嵌鉴权RLS 策略让权限逻辑沉淀在数据层任何客户端路径都无法绕过状态与会话由 SDK 接管onAuthStateChange、getClaims、Token 刷新都藏在supabase-js内部存储与数据库共用同一权限心智一条policy同时约束表和桶学习成本被压缩到最小。当然边界也要说清楚。BaaS 能覆盖的是标准的 CRUD 认证 存储形态当业务逻辑复杂到需要跨表事务编排、定时任务、第三方回调签名验证时就需要 Supabase Edge Functions基于 Deno 的云端函数或直接在数据库里写存储过程——这些依然是后端只是换了一种更贴近数据层的写法。RLS 是最后一道防线也意味着它必须成为第一道防线——那 1.6 万个裸奔的数据库就是给所有只写前端的开发者上的最贵一课。如果你正打算用 Vue 3 做一个带账号体系的完整应用不妨直接把examples/user-management/vue3-user-management拉下来跑一遍初始化、建表、魔法链接登录、档案 CRUD、头像上传再到npm run dev看到完整应用在 5173 端口跑起来——这条路径上的每一步仓库里都有真实可运行的代码等着你。剩下的三小时里你会发现自己省下的不是写后端的时间而是整整一类工程问题。【免费下载链接】supabaseThe Postgres development platform. Supabase gives you a dedicated Postgres database to build your web, mobile, and AI applications.项目地址: https://gitcode.com/GitHub_Trending/supa/supabase创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 前端秒变全栈：Vue3 + Supabase 三小时交付完整应用，后端一行不写
前端秒变全栈Vue3 Supabase 三小时交付完整应用后端一行不写【免费下载链接】supabaseThe Postgres development platform. Supabase gives you a dedicated Postgres database to build your web, mobile, and AI applications.项目地址: https://gitcode.com/GitHub_Trending/supa/supabase我只写前端后端怎么办这是无数 Vue 开发者在个人项目、独立出海、内部工具、黑客松 Demo 上反复撞见的墙。传统方案要么引入 Node 服务端把工程复杂度翻倍要么使用云函数把逻辑拆得七零八落要么退回 Firebase 接受锁死生态和 SQL 能力阉割。Supabase 给出的答案是另一条路让 PostgreSQL 自己成为后端。它把数据库、REST API、实时订阅、认证、对象存储和边缘函数打包成一套开箱即用的 BaaS前端只要装一个 JS SDK 就能拿到完整的后端能力。这个定位让它在 2025–2026 年踩中了风口——社区讨论中它被称作Vibe Coding 的默认后端估值已突破百亿美元还以 1.5 亿美元融资收购了数据库公司 Turso把目光投向AI 智能体需要数百万个独立数据库的下一程。本文不再复述营销话术而是直接打开 Supabase 官方仓库supabase/supabase中真实的 Vue 3 示例代码从项目初始化、数据库表设计、认证、CRUD、文件存储到本地联调与上线部署把三小时交付完整应用的完整链路拆给你看并交代每一环背后为什么能这么省的机制原理。一张表就是一套 APIBaaS 的底气从哪来先看仓库里最核心的示例examples/user-management/vue3-user-management。这是一个官方维护的完整 Vue 3 用户管理应用功能清单极其克制却覆盖了全栈应用的三大命脉通过 Magic Link邮箱魔法链接登录无需密码读取、更新用户档案数据数据库 CRUD上传、回显头像图片对象存储。整个项目的前端依赖只有两个见 package.jsondependencies: { supabase/supabase-js: ^2, vue: ^3.5.30 }没有 Express、没有 ORM、没有鉴权中间件。后端能力的秘密藏在架构里Supabase 在 PostgreSQL 之上叠了一层PostgREST——一个把数据库表直接暴露为 RESTful API 的网关。你在数据库里建一张表PostgREST 就自动生成GET/POST/PATCH/DELETE端点你在表上定义行级安全RLS策略这个 API 就自带权限语义。前端拿到的supabase.from(profiles).select(...)这样的链式调用底层打的正是这些自动生成的 HTTP 接口。这也解释了为什么仓库的 Docker 自托管编排docker/docker-compose.yml里躺着十来个相互咬合的服务Studio 控制台、基于 Envoy 的 API 网关api-gw、负责 JWT 认证的authGoTrue、把 Postgres 变成 REST API 的 PostgREST、负责 WebSocket 广播的 Realtime、对象存储 Storage、连接池 Supavisor 等等。开发者感知到的一个 BaaS其实是一套企业级开源组件堆叠出的平台——这也是它与 Firebase 最本质的区别底层是标准 SQL 和你能完全掌控的 Postgres。第一步脚手架、环境变量与数据库表设计按官方 Quickstartapps/docs/content/guides/getting-started/quickstarts/vue.mdx的流程从零初始化一个 Vue 应用只需三行命令npm create vitelatest supabase-vue-3 -- --template vue cd supabase-vue-3 npm install supabase/supabase-js然后把项目 URL 与 publishable key 写入.env参考示例中的 .env.exampleVITE_SUPABASE_URLhttps://your-project-ref.supabase.co VITE_SUPABASE_PUBLISHABLE_KEYyour-publishable-key初始化客户端的代码全项目只有五行的量级见 src/supabase.jsimport { createClient } from supabase/supabase-js const supabaseUrl import.meta.env.VITE_SUPABASE_URL const supabasePublishableKey import.meta.env.VITE_SUPABASE_PUBLISHABLE_KEY export const supabase createClient(supabaseUrl, supabasePublishableKey)值得注意这两个变量会暴露在浏览器里官方文档对此的注释是这没问题因为数据库开启了行级安全RLS。这句话是整篇文章的安全主线后面会展开。接下来是整条链路里唯一一次写后端的环节——但用的不是编程语言而是 SQL。示例 READMEREADME.md给出了完整的建表脚本核心是一张profiles表create table profiles ( id uuid references auth.users not null, updated_at timestamp with time zone, username text unique, avatar_url text, website text, primary key (id), unique(username), constraint username_length check (char_length(username) 3) );三个细节值得工程师品一品主键直接引用auth.usersid是 UUID 且外键指向 Supabase 内置的认证用户表登录用户与业务数据的绑定关系由数据库约束兜底约束写在数据库里username唯一、长度不小于 3这类校验不需要前端或中间层重复实现任何绕过 UI 的请求都在数据库层被拦截表结构即 API 契约建完表PostgREST 立即暴露对应的 REST 端点select、insert、update全部可用——这就是后端一行不写的字面含义。建表动作既可以在云端的 SQL Editor 里执行也可以在本地supabase migration new生成的迁移文件中维护后者让表结构像前端代码一样进入版本管理。认证打通Magic Link 登录与登录态管理认证是新手最容易写崩的部分密码哈希、会话令牌、过期刷新、安全 Cookie……Supabase Auth 把这些全部内置。示例使用邮箱魔法链接前端交互代码只有Auth.vue一个组件src/components/Auth.vueconst handleLogin async () { try { loading.value true const { error } await supabase.auth.signInWithOtp({ email: email.value }) if (error) throw error alert(Check your email for the login link!) } catch (error) { if (error instanceof Error) { alert(error.message) } } finally { loading.value false } }用户提交邮箱后Auth 服务签发一次性链接发送到邮箱点击即完成登录。而当前是否已登录的全局状态由 src/App.vue 监听维护onMounted(() { supabase.auth.getClaims().then(({ data }) { claims.value data.claims }) supabase.auth.onAuthStateChange(async () { const { data } await supabase.auth.getClaims() claims.value data.claims }) })Account v-ifclaims :claimsclaims / Auth v-else /getClaims()读取 JWT 中的声明onAuthStateChange订阅登录/登出事件——登录态在页面刷新、跨标签页、Token 过期等场景下都由 SDK 自动维护。需要社交登录时官方仓库还提供了 GitHub OAuth 的完整配置流程社区文章对此也有大量实践原理一致在 GitHub 侧创建 OAuth App把回调地址填进 Supabase 控制台前端一行signInWithOAuth即可。这里有一层值得 Vue 开发者留意的机制JWT 的sub声明用户 UUID与数据库 RLS 中的auth.uid()是同一枚 Token 的两种读取视角。前端从claims.sub拿用户 ID 去查询自己的档案数据库策略用auth.uid()校验请求归属——两端基于同一签名体系这就是无需后端代码却能完成身份鉴权的底层密码。CRUD 与安全底线RLS 是一切的根基登录之后档案的读取与更新落在 src/components/Account.vue两段代码分别是读和写let { data, error, status } await supabase .from(profiles) .select(username, website, avatar_url) .eq(id, claims.value.sub) .single()const updates { id: claims.value.sub, username: username.value, website: website.value, avatar_url: avatar_url.value, updated_at: new Date(), } let { error } await supabase.from(profiles).upsert(updates)select加.eq(id, ...)过滤、upsert一键插入或更新——标准的前端链式调用没有一行服务端逻辑。但真正决定谁能读、谁能写的是建表时跟着写下的那三条 RLS 策略alter table profiles enable row level security; create policy Public profiles are viewable by everyone. on profiles for select using ( true ); create policy Users can insert their own profile. on profiles for insert with check ( (select auth.uid()) id ); create policy Users can update own profile. on profiles for update using ( (select auth.uid()) id );语义一目了然档案公开可读只有auth.uid()等于记录id的用户本人能插入和更新自己的档案。RLS 是 Postgres 原生机制策略在数据库内部执行任何途径REST API、直接 SQL 连接、未来新增的客户端都无法绕过——这正是publishable key 可以安全暴露在浏览器里的前提。反过来忽略这一层就会付出真实代价2025 年 UpGuard 安全团队的研究发现全网有16,326 个 Supabase 项目暴露了公开可读取的数据库表其中不少包含个人数据TechCrunch 等媒体对此做了报道。这些项目的共性失误高度一致——建了表、接入了 SDK却忘了enable row level security和策略。把 RLS 当作可选的进阶功能是 BaaS 时代最危险的认知偏差在你写下create table之后的第一件事就应该是打开 RLS。文件存储三行代码搞定头像上传档案里还躺着一个avatar_url字段对应存储层的能力。头像上传组件 src/components/Avatar.vue 展示了 Storage 的完整闭环——上传与下载let { error: uploadError } await supabase.storage .from(avatars) .upload(filePath, file)const { data, error } await supabase.storage .from(avatars) .download(path.value) src.value URL.createObjectURL(data)上传用的是随机文件名下载后在浏览器侧URL.createObjectURL生成本地预览避免每次渲染都走一遍网络。桶Bucket的权限同样在 SQL 中声明insert into storage.buckets (id, name) values (avatars, avatars); create policy Avatar images are publicly accessible. on storage.objects for select using ( bucket_id avatars ); create policy Anyone can upload an avatar. on storage.objects for insert with check ( bucket_id avatars );Storage 对公众开放读头像需要公开访问、放行登录用户上传权限模型和数据库表完全一致地由策略驱动。更进阶的做法是把上传 URL 签名化、给对象加防盗链或接入 CDN 做边缘缓存——能力都在只是按需开启。至此认证、CRUD、文件存储三大件已经全部打通。把Auth、Account、Avatar三个组件组装进App.vuenpm run dev启动 Vite 开发服务器浏览器打开localhost:5173一个完整的用户管理应用就出现在眼前——这正是官方教程with-vue-3.mdx里At this stage you have a fully functional application!的由来。顺带一提这套用户管理脚手架在仓库里以九种技术栈平行存在——React、Svelte、Swift、Flutter、Angular、Ionic乃至 Solid 和 Nuxt——它们共享同一套数据库、同一份 RLS 策略、同一套 Storage 配置。后端能力与前端框架彻底解耦这是前端秒变全栈最有力的注脚你学的不是某个框架绑定的后端而是一套可复用的后端资产。从本地联调到上线部署两条路线都讲清楚应用写完了接下来是工程师最关心的最后一公里。Supabase 给了两条部署路线恰好对应不同的控制欲与运维成本。路线 A托管云默认路径。在控制台创建项目、执行建表 SQL、拿到 URL 和 key 之后前端npm run build产出静态资源部署到任意静态托管Vercel、Netlify、自有服务器即可。数据库、Auth、Storage 全部由平台托管自动备份、免运维。这也是三小时交付最顺滑的路径——本地开发与生产环境共享同一套 API除了环境变量不同代码路径完全一致。路线 B自托管Docker Compose。仓库根目录的 docker/ 提供了官方自托管编排。它把完整服务栈收进一份docker-compose.ymlStudio 控制台、Envoy API 网关、Auth、PostgREST、Realtime、Storage、Postgres 元数据管理、Postgres 本体、Edge Runtime、日志链路Logflare Vector和连接池 Supavisor。社区里的 Windows 部署与本地联调文章走的也是这条路——装好 Docker 与 Supabase CLIsupabase start即可拉起本地实例.env指向localhost完成联调。日常运维则被封装成脚本docker/run.shsh run.sh start # docker compose up -d --wait sh run.sh status # docker compose ps sh run.sh logs auth # 跟踪指定服务日志 sh run.sh secrets # 打印密钥与 API Key sh update.sh # 备份后升级整套服务自托管的代价在 docker/README.md 里被写得很直白——默认配置不安全不能直接上生产必须更换所有默认密码与密钥、复查 CORS 配置、在服务前方架设 HTTPS 反向代理、并建立备份机制。托管云替你承担了这部分运维风险自托管则把控制权与责任同时交还给你。对大多数个人项目和早期产品路线 A 是正确的默认选择对数据主权敏感或需要深度定制的场景路线 B 才是答案。三小时背后的工程真相复盘整条链路会发现三小时交付不是营销话术而是有清晰机制支撑的工程事实表即 APIPostgREST 把 DDL 变成 REST 端点省掉一整层路由与序列化代码数据库内嵌鉴权RLS 策略让权限逻辑沉淀在数据层任何客户端路径都无法绕过状态与会话由 SDK 接管onAuthStateChange、getClaims、Token 刷新都藏在supabase-js内部存储与数据库共用同一权限心智一条policy同时约束表和桶学习成本被压缩到最小。当然边界也要说清楚。BaaS 能覆盖的是标准的 CRUD 认证 存储形态当业务逻辑复杂到需要跨表事务编排、定时任务、第三方回调签名验证时就需要 Supabase Edge Functions基于 Deno 的云端函数或直接在数据库里写存储过程——这些依然是后端只是换了一种更贴近数据层的写法。RLS 是最后一道防线也意味着它必须成为第一道防线——那 1.6 万个裸奔的数据库就是给所有只写前端的开发者上的最贵一课。如果你正打算用 Vue 3 做一个带账号体系的完整应用不妨直接把examples/user-management/vue3-user-management拉下来跑一遍初始化、建表、魔法链接登录、档案 CRUD、头像上传再到npm run dev看到完整应用在 5173 端口跑起来——这条路径上的每一步仓库里都有真实可运行的代码等着你。剩下的三小时里你会发现自己省下的不是写后端的时间而是整整一类工程问题。【免费下载链接】supabaseThe Postgres development platform. Supabase gives you a dedicated Postgres database to build your web, mobile, and AI applications.项目地址: https://gitcode.com/GitHub_Trending/supa/supabase创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考