“后端不用寫”這種事我以前是不信的。直到我用 Supabase 把一個小型內(nèi)部工具的后端只用了半天就搭完才意識到這套“后端即服務(wù)”的路子對獨(dú)立開發(fā)者和前端團(tuán)隊(duì)來說確實(shí)能省下大量造輪子的時(shí)間。Supabase 這個名字這兩年討論度很高簡單說它是個開源版的 Firebase 替代品但底層不是文檔數(shù)據(jù)庫而是直接給你一個完整的 PostgreSQL還順手把數(shù)據(jù)庫的實(shí)時(shí)訂閱、用戶認(rèn)證、文件存儲、邊緣函數(shù)都集成好了。這篇文章我會以一個實(shí)際演示項(xiàng)目為主線從建表、CRUD、實(shí)時(shí)訂閱、用戶登錄到文件上傳一步步帶你跑通整個流程同時(shí)把 RLS 這一層權(quán)限控制的坑也拆開講清楚。如果你正打算給 Next.js、Vue 或者小程序做后端或者想找個自部署方案的參考這篇內(nèi)容應(yīng)該能幫你少走幾條彎路。1. 內(nèi)容整體設(shè)計(jì)與思路拆解1.1 為什么我選 Supabase 而不是自己寫后端我先說下這個演示項(xiàng)目的背景我要做一個團(tuán)隊(duì)共享的“任務(wù)看板”成員可以登錄、創(chuàng)建任務(wù)、修改任務(wù)狀態(tài)還能上傳附件。傳統(tǒng)做法是寫 Node.js/Go 服務(wù)提供 REST API再接一個 MySQL/PG 數(shù)據(jù)庫同時(shí)要管用戶密碼加密、Token 生成、權(quán)限校驗(yàn)一套下來少說兩三周。Supabase 的做法是把數(shù)據(jù)庫、認(rèn)證、實(shí)時(shí)推送這些底座能力直接以 SDK 形式給出來前端拿到的是一堆“讓代碼自動運(yùn)行”的服務(wù)而不是要自己維護(hù)的服務(wù)器進(jìn)程。這里有個關(guān)鍵認(rèn)知Supabase 不是一個“低代碼平臺”它不限制你寫高級邏輯。它給你的是一套托管好的 Postgres 實(shí)例外加官方封裝好的客戶端 SDK。Postgres 本身是當(dāng)今功能最強(qiáng)大的開源數(shù)據(jù)庫所以 Supabase 的起點(diǎn)非常高——你能用 SQL 寫存儲過程、觸發(fā)器、視圖也可以用 REST API 直接操作表還能通過 Realtime實(shí)時(shí)功能監(jiān)聽表變化。對我來說選它最大的動力是團(tuán)隊(duì)里前端技術(shù)棧是 React但我不想再維護(hù)一套后端 CI/CD、API 網(wǎng)關(guān)這類基礎(chǔ)設(shè)施Supabase 把基礎(chǔ)設(shè)施的部分接管了我只需要關(guān)注業(yè)務(wù)數(shù)據(jù)表和權(quán)限規(guī)則。1.2 核心功能一覽及適用場景Supabase 的功能模塊可以分成四大部分?jǐn)?shù)據(jù)庫Database基于 PostgreSQL提供了可視化表格界面、SQL 編輯器、自動生成 REST API還支持 Row Level Security 行級安全策略。身份認(rèn)證Auth支持郵箱密碼、手機(jī)驗(yàn)證碼、郵箱魔法鏈接以及 Google、GitHub、微信等 OAuth 登錄管理用戶會話和 Token 刷新。實(shí)時(shí)能力Realtime通過 WebSocket 訂閱數(shù)據(jù)庫表的 INSERT / UPDATE / DELETE 事件也能訂閱 Postgres Changes。非常適合聊天、協(xié)作編輯、實(shí)時(shí)看板這類場景。存儲Storage基于 S3 協(xié)議的對象存儲可以上傳圖片、文檔、音視頻并提供帶權(quán)限約束的臨時(shí)訪問簽名 URL。邊緣函數(shù)Edge Functions基于 Deno 的 serverless 函數(shù)可以寫一些需要跑在服務(wù)端的邏輯比如處理 Webhook、調(diào)用第三方 API。適合它的場景很明確內(nèi)部工具、MVP 產(chǎn)品、原型演示、中小型 SaaS 的起步階段。如果你的項(xiàng)目涉及非常復(fù)雜的事務(wù)邏輯、大量二進(jìn)制流處理或者已經(jīng)在用一套成熟的微服務(wù)架構(gòu)Supabase 未必是唯一解但做一個“能上線、可迭代”的應(yīng)用它絕對夠用。1.3 和 Firebase 的橫向?qū)Ρ群芏嗳四?Supabase 和 Firebase 比較我兩個都用過說下個人感受。Firebase 的 Firestore 是 NoSQL 文檔數(shù)據(jù)庫上手快但數(shù)據(jù)結(jié)構(gòu)一旦復(fù)雜多表關(guān)聯(lián)就非常難受而 Supabase 直接是關(guān)系型數(shù)據(jù)庫有外鍵、有事務(wù)天然適合業(yè)務(wù)邏輯成體系的項(xiàng)目。另外 Supabase 是開源項(xiàng)目意味著你能自己部署數(shù)據(jù)都在你的服務(wù)器上這對很多公司來說是很重要的考量點(diǎn)。但 Supabase 在國內(nèi)的默認(rèn)訪問速度不一定理想而且新手起步時(shí)會覺得它“太像數(shù)據(jù)庫”了——需要懂 SQL、懂表關(guān)系、懂權(quán)限規(guī)則不像 Firebase 的規(guī)則那樣常見的 allow read/write 比較簡單。我的態(tài)度是如果你本身熟悉 SQL選 Supabase 會如魚得水如果你完全沒有后端概念Firebase 可能更輕松但深水區(qū)還是需要知識積累。2. 核心細(xì)節(jié)解析與實(shí)操要點(diǎn)2.1 項(xiàng)目創(chuàng)建與連接參數(shù)演示的第一步去 supabase.com 注冊一個賬號創(chuàng)建一個新項(xiàng)目。需要填項(xiàng)目名稱、數(shù)據(jù)庫密碼和 Region。這里注意Region 一定要選離你用戶最近的區(qū)域但國內(nèi)訪問沒有特別近的節(jié)點(diǎn)可以選 Singapore 這類網(wǎng)絡(luò)相對穩(wěn)定的位置。創(chuàng)建完成后進(jìn)入項(xiàng)目 Dashboard左側(cè)菜單有 Table Editor、SQL Editor、Auth、Storage、Edge Functions對應(yīng)不同模塊。項(xiàng)目創(chuàng)建好后你在Project Settings → API Keys里能找到兩個關(guān)鍵信息URLhttp://xxxx.supabase.co和 anon key匿名公鑰。anon key 會在客戶端的createClient初始化時(shí)用到別看它叫“匿名”它內(nèi)部包含 JWT可以在不登錄狀態(tài)下訪問數(shù)據(jù)庫的公開數(shù)據(jù)——真正限制你要不要暴露數(shù)據(jù)靠的是 RLS 策略。import { createClient } from supabase/supabase-js const supabase createClient( https://your-project.supabase.co, your-anon-key )提示anon key 是公開的所以千萬不要用它來當(dāng)“私密鑰匙”。任何權(quán)限過濾都要依賴數(shù)據(jù)庫層面的 RLS 策略來完成不要依賴 client 端隱藏。2.2 建表前的數(shù)據(jù)建模思路既然底層是 Postgres就按照關(guān)系型數(shù)據(jù)庫的習(xí)慣來建模。任務(wù)看板的核心表是tasks和profiles。profiles用來擴(kuò)展auth.users里的用戶資料比如昵稱、頭像等。任務(wù)表字段可以包括id、title、description、status、assignee_id、creator_id、created_at、updated_at、due_date、attachments。這里有一個新手常犯的錯誤直接把用戶郵箱作為外鍵存放在業(yè)務(wù)表里。郵箱這是可變的而且auth.users里的 email 字段并不適合直接關(guān)聯(lián)。正確做法是使用auth.uid()獲取當(dāng)前登錄用戶的 UUID 作為關(guān)聯(lián)。所以assignee_id和creator_id都應(yīng)該是 UUID 類型并參考auth.users (id)外鍵。在 Supabase 的表編輯器里可以直接新建表也可以用 SQL。我更推薦把建表語句保存在 SQL 文件里方便在另一個項(xiàng)目里復(fù)現(xiàn)。先打開SQL Editor執(zhí)行以下腳本-- 創(chuàng)建個人資料表關(guān)聯(lián) auth.users create table if not exists public.profiles ( id uuid references auth.users (id) on delete cascade primary key, display_name text, avatar_url text, created_at timestamptz default now() ); alter table public.profiles enable row level security; -- 任務(wù)表 create table if not exists public.tasks ( id uuid primary key default gen_random_uuid(), title text not null, description text, status text not null default todo check (status in (todo, in_progress, done)), assignee_id uuid references public.profiles (id), creator_id uuid references public.profiles (id), due_date date, created_at timestamptz default now(), updated_at timestamptz default now() ); alter table public.tasks enable row level security; -- 自動更新 updated_at create or replace function public.handle_updated_at() returns trigger language plpgsql as $$ begin new.updated_at now(); return new; end; $$; create trigger tasks_set_updated_at before update on public.tasks for each row execute function public.handle_updated_at(); -- 為新用戶創(chuàng)建 profile 的觸發(fā)器 create or replace function public.handle_new_user() returns trigger language plpgsql security definer set search_path public as $$ begin insert into public.profiles (id, display_name, avatar_url) values (new.id, new.raw_user_meta_data-display_name, new.raw_user_meta_data-avatar_url); return new; end; $$; create trigger on_auth_user_created after insert on auth.users for each row execute procedure public.handle_new_user();這段 SQL 里包含了兩個觸發(fā)器一個是自動更新任務(wù)的修改時(shí)間另一個是在新用戶注冊后自動往profiles表插一條記錄。這一步非常重要否則你會發(fā)現(xiàn)用戶登錄后用戶信息表是空的——前端還得手動補(bǔ)插容易出錯。2.3 RLS 策略的必要性建表語句里我特別加了enable row level security。很多人會問Supabase 不是自帶 API 嗎為什么還要做這么一層因?yàn)闉榱俗尶蛻舳酥苯邮褂?anon key 訪問數(shù)據(jù)庫Supabase 的 REST API 是“直通”行級數(shù)據(jù)的如果沒有 RLS任何拿到 anon key 的人都能讀取甚至修改所有表的數(shù)據(jù)。這是致命的。RLS 可以理解為 Postgres 在查詢執(zhí)行前加了一道“條件過濾”。比如任務(wù)列表的 RLS我希望登錄用戶只能看到“自己是創(chuàng)建者或指派對象”的任務(wù)那就得寫這樣的策略create policy 用戶可以查看與自己相關(guān)的任務(wù) on public.tasks for select using ( auth.uid() creator_id or auth.uid() assignee_id );同樣寫操作也要定義策略。例如只有創(chuàng)建者能更新任務(wù)以及只有創(chuàng)建者或管理員能刪除任務(wù)。這里的“管理員”我們可以用 profiles 表的一個role字段來定義但為了演示我一直保持簡單——“創(chuàng)建者或執(zhí)行者都可更新”。要注意的策略語法中auth.uid()返回當(dāng)前用戶 UUID如果用戶未登錄這個函數(shù)會返回 NULL策略就會自然失效也保證了數(shù)據(jù)安全。2.4 安裝 SDK 與環(huán)境變量演示項(xiàng)目我直接用 Vite React。在項(xiàng)目根目錄安裝官方包npm install supabase/supabase-js然后建議把 URL 和 anon key 放到.env.local文件中避免把密鑰硬編碼到源碼里VITE_SUPABASE_URLhttps://your-project.supabase.co VITE_SUPABASE_ANON_KEYyour-anon-key注意Vite 項(xiàng)目讀取環(huán)境變量需要以VITE_前綴開頭。然后在src/lib/supabase.js中初始化客戶端。import { createClient } from supabase/supabase-js const supabaseUrl import.meta.env.VITE_SUPABASE_URL const supabaseAnonKey import.meta.env.VITE_SUPABASE_ANON_KEY export const supabase createClient(supabaseUrl, supabaseAnonKey)這里要提醒一個細(xì)節(jié)supabase-js默認(rèn)會建議使用autoRefreshToken它會根據(jù) JWT 過期時(shí)間自動刷新。開發(fā)模式下如果瀏覽器緩存了舊的本地狀態(tài)可能出現(xiàn)登錄失效半天不清醒的情況保留默認(rèn)設(shè)置基本沒問題但如果你做的是 React Native 或小程序務(wù)必看一下文檔里關(guān)于 AsyncStorage 的接入配置。3. 實(shí)操過程與核心環(huán)節(jié)實(shí)現(xiàn)3.1 基礎(chǔ) CRUD 操作演示咱們先在 UI 里做最基礎(chǔ)的增刪改查。先看查詢?nèi)蝿?wù)列表不僅要把 tasks 表查出來還要把 assignee 和 creator 的 profile 信息一次性 join 出來。Supabase 的查詢語法挺直觀const { data, error } await supabase .from(tasks) .select(*, assignee:assignee_id(display_name, avatar_url), creator:creator_id(display_name, avatar_url)) .order(created_at, { ascending: false }); if (error) console.error(error);這里用了別名語法assignee:assignee_id(...)表示把a(bǔ)ssignee_id外鍵關(guān)聯(lián)到 profiles 表并選擇display_name和avatar_url字段。返回結(jié)果里會多出assignee和creator兩個對象方便前端渲染人名和頭像。新增任務(wù)的時(shí)候注意要把creator_id設(shè)置為當(dāng)前登錄用戶的 ID通過supabase.auth.getUser()來獲取const { data: userData } await supabase.auth.getUser(); const userId userData.user.id; const { data, error } await supabase .from(tasks) .insert([ { title: 開發(fā)登錄頁面, description: 使用 Supabase Auth, status: todo, creator_id: userId, assignee_id: userId } ]) .select();鉤子點(diǎn)insert后加.select()這樣才能返回插入后的完整行數(shù)據(jù)包括默認(rèn)生成的 id 和 created_at很多新手會忽略這個導(dǎo)致剛剛插入后無法拿 ID 做下一步操作。更新和刪除也很簡單// 更新狀態(tài) const { error } await supabase .from(tasks) .update({ status: in_progress }) .eq(id, taskId); // 刪除 const { error } await supabase .from(tasks) .delete() .eq(id, taskId);如果操作報(bào) 403 或 42501大概率是 RLS 策略沒寫好。做更新操作時(shí)會觸發(fā)using和with check兩個條件簡單理解是using是“能否操作原有數(shù)據(jù)”with check是“插入/更新后的新值能否滿足條件”。兩個條件都要過。3.2 實(shí)時(shí)訂閱實(shí)現(xiàn)看板自動刷新實(shí)時(shí)功能是一個亮點(diǎn)。在任務(wù)看板中多人同時(shí)操作頁面上如果手動刷新很蠢。用 Supabase 的channel來訂閱任務(wù)表的變化const channel supabase .channel(public:tasks) .on(postgres_changes, { event: *, schema: public, table: tasks }, (payload) { console.log(變化: , payload); // 根據(jù) payload.new 或 payload.old 更新本地狀態(tài) }) .subscribe();這樣只要任何客戶端對 tasks 表做了 INSERT、UPDATE、DELETE都會實(shí)時(shí)推送到訂閱者。需要恢復(fù)舊事件時(shí)在 useEffect 里useEffect(() { const channel supabase .channel(schema-db-changes) .on(postgres_changes, { event: *, schema: public, table: tasks }, handleChange) .subscribe(); return () { supabase.removeChannel(channel); }; }, []);注意訂閱前建議先拉取一次全量數(shù)據(jù)再用實(shí)時(shí)事件做增量更新避免丟數(shù)據(jù)。我做這個小項(xiàng)目時(shí)專門寫了一個applyChange函數(shù)如果是 INSERT把 payload.new 加入 stateUPDATE替換對應(yīng) id 的數(shù)據(jù)DELETE從 state 里移除。如果直接“每次都重新查詢?nèi)怼睍l繁觸發(fā)數(shù)據(jù)庫壓力尤其在多人使用時(shí)。我建議實(shí)時(shí)訂閱只在天真無邪的場景里用。付費(fèi)功能限制方面Supabase 的免費(fèi)層級對 Realtime 并發(fā)連接數(shù)有限制默認(rèn) 200 個在線連接左右如果是在國內(nèi)公網(wǎng)服務(wù)器上用注意一下長連接被防火墻切斷的問題我會在避坑部分詳細(xì)說。3.3 Auth 登錄注冊功能與用戶狀態(tài)管理Supabase Auth 用起來很直接注冊const { data, error } await supabase.auth.signUp({ email: userexample.com, password: password123, options: { data: { display_name: 張三 } } });如果項(xiàng)目里開啟了郵件確認(rèn)用戶會收到一封確認(rèn)郵件。SignUp 成功后默認(rèn)情況不會自動創(chuàng)建 session而是返回一個只有 user 沒有 session 的對象。這在很多新手演示里容易造成困惑——明明注冊成功了為什么前端登錄狀態(tài)不對所以要提示用戶去郵箱確認(rèn)或者在后端的 Auth 設(shè)置里關(guān)閉“確認(rèn)郵箱”選項(xiàng)才能實(shí)現(xiàn)注冊即登錄。登錄const { data, error } await supabase.auth.signInWithPassword({ email: userexample.com, password: password123 });登錄成功后data.session里有 access_token我們會把它存儲到本地Supabase 客戶端會自動處理后續(xù)的請求帶上 Authorization 頭。封裝一個簡單的 AuthContext 來監(jiān)聽登錄狀態(tài)supabase.auth.getSession().then(({ data }) { setSession(data.session); }); supabase.auth.onAuthStateChange((_event, session) { setSession(session); });手動登出const { error } await supabase.auth.signOut();一個有趣的點(diǎn)是如果你想在服務(wù)端渲染框架里讀用戶信息可以用getUser()代替getSession()getUser會向 Auth 服務(wù)發(fā)送請求驗(yàn)證 token更安全。但在客戶端getSession更快因?yàn)?token 就在本地不過它可能有篡改風(fēng)險(xiǎn)我們后續(xù)在 RLS 里都依賴auth.uid()來驗(yàn)真所以問題不大。3.4 用戶資料實(shí)時(shí)聯(lián)動剛才建表時(shí)我們創(chuàng)建了一個觸發(fā)器注冊后自動把用戶數(shù)據(jù)放進(jìn)profiles表那前端怎么讀取當(dāng)前用戶資料可以這樣const { data: profile, error } await supabase .from(profiles) .select(*) .eq(id, userId) .single();而任務(wù)列表中的assignee_id關(guān)聯(lián)到 profiles 表后我們就能拿到 assignee 的名字和頭像。如果頭像的更新是實(shí)時(shí)同步的還可以訂閱 profiles 表的變化達(dá)到類似“用戶頭像更新后全端同步”的效果。3.5 存儲模塊附件上傳與公開/私密訪問任務(wù)看板里我支持上傳圖片附件。Supabase Storage 很方便創(chuàng)建 bucket 時(shí)選擇公開或私有。對于“臟文件 用戶頭像”這類內(nèi)容我建議私有 bucket因?yàn)楹罄m(xù)還要接 RLS 控制誰能訪問。創(chuàng)建 bucket 可以在 Dashboard 里點(diǎn)也可以通過 SDKconst { data, error } await supabase.storage.createBucket(attachments, { public: false, // 私有 allowedMimeTypes: [image/*, application/pdf], fileSizeLimit: 10 * 1024 * 1024 // 10MB });上傳文件的核心 APIconst filePath ${userId}/${Date.now()}-${file.name}; const { error } await supabase.storage .from(attachments) .upload(filePath, file, { cacheControl: 3600, upsert: false });上傳成功后如果需要私有 bucket 內(nèi)的文件預(yù)覽不能直接用getPublicUrl而要生成一個臨時(shí)簽名 URLconst { data } await supabase.storage .from(attachments) .createSignedUrl(filePath, 60 * 60); // 一小時(shí)有效 // data.signedUrl 就是帶限時(shí) token 的地址對于私有 bucket 的訪問Supabase 有storage.objects表的 RLS 可以配置比如“只有任務(wù)參與者可以下載附件”。我寫了一個簡單的策略允許創(chuàng)建該附件的用戶讀取create policy 允許用戶訪問自己的附件 on storage.objects for select to authenticated using (bucket_id attachments and owner auth.uid());這里的owner是 storage.objects 表自動記錄的上傳者 ID有了這層即使生成了簽名 URL別人也無法繞過策略訪問。3.6 邊緣函數(shù)用 Deno 寫點(diǎn)服務(wù)端邏輯有時(shí)候我們需要在服務(wù)端調(diào)一些外部 API 或者生成數(shù)據(jù)那就用 Edge Functions。Supabase 的 CLI 可以本地寫函數(shù)然后部署上去。先安裝 CLInpm install -g supabase supabase login supabase link --project-ref your-project-ref創(chuàng)建函數(shù)時(shí)在項(xiàng)目目錄執(zhí)行supabase functions new hello-world生成的functions/hello-world/index.ts模板長這樣import { serve } from https://deno.land/std0.168.0/http/server.ts serve(async (req) { const { name } await req.json() return new Response(JSON.stringify({ message: Hello ${name}! }), { headers: { Content-Type: application/json } }) })部署supabase functions deploy hello-world我可以在這里實(shí)現(xiàn)“任務(wù)導(dǎo)出為 PDF”之類的需求但是要注意Edge Functions 默認(rèn)是匿名可訪問的如果你的函數(shù)里需要拿到當(dāng)前用戶身份要到 Authorization 頭里解析 supabase JWT。官方提供了supabase-js在 Deno 環(huán)境下的用法我建議用createClient配合auth.getUser()校驗(yàn)用戶身份不要在函數(shù)里盲目信任外部參數(shù)。但在這一步我只做一個相對簡單的“獲取公開任務(wù)數(shù)量”函數(shù)用來驗(yàn)證函數(shù)調(diào)用鏈路。前端要用 fetch 直接打函數(shù)的 URL并附帶上 anon key 作為apikey頭const res await fetch(https://your-project.supabase.co/functions/v1/hello-world, { method: POST, headers: { Content-Type: application/json, Authorization: Bearer ${supabaseAnonKey} }, body: JSON.stringify({ name: Supabase User }) });記得設(shè)置Authorization頭時(shí)如果是登錄用戶可以帶上 access_token否則就用 anon key。很多人在本地測試時(shí)沒部署 Edge Function直接打 URL 會 404記得確認(rèn)函數(shù)已經(jīng)部署成功。4. 常見問題與排查技巧實(shí)錄4.1 “明明設(shè)置了 RLS外層服務(wù)怎么還能查數(shù)據(jù)”這個問題非常典型。你在建表時(shí)啟用了 RLS但客戶端 SDK 依然能讀取所有數(shù)據(jù)通常是兩種原因。第一你建表時(shí)沒啟用 RLS只寫了 policy 但沒有執(zhí)行enable row level security。RLS 默認(rèn)對表所有者是放行的所以當(dāng) Supabase 的 API 內(nèi)部是服務(wù)角色去訪問時(shí)就會繞過所有策略——服務(wù)角色相當(dāng)于“超級管理員”專用于后端服務(wù)不建議前端使用。第二你的 policy 是給anon角色創(chuàng)建的而不是authenticated。如果表里存的是售貨數(shù)據(jù)要么強(qiáng)制用戶登錄要么給 anon 角色寫策略。在 Supabase 的 SQL 編輯器可以用這個查詢來檢查表的 RLS 是否打開select tablename from pg_tables where schemaname public;更直觀的是 Dashboard 的 Table Editor 里表行旁邊會看到綠標(biāo)/紅標(biāo)標(biāo)識 RLS 狀態(tài)。4.2 數(shù)據(jù)庫連接時(shí)好時(shí)壞實(shí)時(shí)通道經(jīng)常斷開Supabase 的 Realtime 用的是 WebSocket部分企業(yè)網(wǎng)絡(luò)環(huán)境里長連接可能被閑置超時(shí)切斷。如果你發(fā)現(xiàn)channel掉線后不能自動重連可以考慮優(yōu)化訂閱方式或者做一個“心跳”邏輯在 channel 事件里監(jiān)聽presence變化或者定期執(zhí)行一個輕量的數(shù)據(jù)庫查詢來保持連接活性。但更穩(wěn)妥的是把 Realtime 和 REST 結(jié)合——先保證重要數(shù)據(jù)通過普通 HTTP 拉取實(shí)時(shí)只是輔助這樣即使斷線關(guān)鍵功能也不會癱瘓。我遇到過的問題本地開發(fā)時(shí)很順暢一部署到公網(wǎng)Realtime 就隔幾分鐘斷一次。原因可能是服務(wù)器側(cè)的 NAT、代理設(shè)了空閑超時(shí)?？梢愿挠眯奶姆绞綇?qiáng)制續(xù)命setInterval(() { supabase.channel(heartbeat).send({ type: broadcast, event: ping, payload: {} }) }, 30000)但這會增加成本務(wù)必在正式環(huán)境按需使用。最省心的做法是僅在需要協(xié)作功能的界面才訂閱實(shí)時(shí)不要把頁面所有數(shù)據(jù)都依賴實(shí)時(shí)。4.3 認(rèn)證流程中的“注冊后不登錄”問題很多朋友用signUp后直接跳轉(zhuǎn)到用戶主頁結(jié)果發(fā)現(xiàn)data.session是 null。剛才說過這是因?yàn)槟汩_啟了“郵件確認(rèn)”。如果希望用戶注冊后免登錄在 Supabase Dashboard 的 Authentication → Providers → Email 里關(guān)閉 “Confirm email” 即可。但在生產(chǎn)環(huán)境我強(qiáng)烈建議保留確認(rèn)郵件一是防止垃圾注冊二是校驗(yàn)郵箱有效性否則有人隨便輸入假郵箱就能注冊賬號。另外用郵箱密碼登錄時(shí)如果密碼錯誤會返回錯誤信息Invalid login credentials這是正常的但是如果用戶輸入郵箱大小寫不一致可能也導(dǎo)致登錄失敗。建議在登錄表單里對郵箱做.trim().toLowerCase()處理并且在注冊時(shí)存小寫郵箱。4.4 查詢性能優(yōu)化與常見坑Postgres 本身很強(qiáng)但如果沒有加索引用戶量大起來查詢會變慢。演示階段無所謂但正式建議給外鍵字段加索引create index tasks_assignee_idx on public.tasks (assignee_id); create index tasks_creator_idx on public.tasks (creator_id); create index tasks_status_idx on public.tasks (status);另一個大坑是select(*)會把大字段也查出來比如 description 很長、附件路徑很多。盡量只 select 所需字段。還有如果在select里關(guān)聯(lián)了profiles表注意只取必要的字段否則一個任務(wù)列表可能查詢數(shù)百行網(wǎng)絡(luò)傳輸慢。4.5 本地開發(fā)中的 Migrations 管理Supabase 不只是線上服務(wù)它支持通過 CLI 把數(shù)據(jù)庫 schema 用 migration 文件管理起來。在項(xiàng)目的supabase/migrations目錄下創(chuàng)建 SQL 文件然后執(zhí)行supabase db push就能把結(jié)構(gòu)變更同步到遠(yuǎn)端數(shù)據(jù)庫。強(qiáng)烈建議從一開始就用版本化 SQL而不是直接在線改表因?yàn)閳F(tuán)隊(duì)里需要環(huán)境同步否則 A 的本地改完B 的數(shù)據(jù)庫還是一頭霧水。不過官方 CLI 需要 Docker 支持本地服務(wù)如果你不想裝 Docker也可以直接在 Dashboard 的 SQL 編輯器執(zhí)行并保存腳本。但寫成 migration 最大的好處是你的整個建表過程可以被代碼審查、回滾、復(fù)制。5. 經(jīng)驗(yàn)與心得幾個被你忽略的細(xì)節(jié)5.1 數(shù)據(jù)庫函數(shù)和觸發(fā)器是真正的“秘密武器”有人覺得 Supabase 無非是一個“表單直連數(shù)據(jù)庫的工具”其實(shí)它背后的 Postgres 能力極其強(qiáng)大。就拿自動給新用戶生成 profile 來說那是我最滿意的策略之一。所有依賴數(shù)據(jù)庫確保“數(shù)據(jù)完整性”的邏輯不要放在應(yīng)用代碼里而是放在數(shù)據(jù)庫觸發(fā)器里。這樣即使用戶通過移動 App、小程序、管理后臺多個入口注冊都能保持一致。再比如任務(wù)更新的updated_at如果用應(yīng)用層代碼設(shè)置那每次要重寫代碼但用觸發(fā)器就一勞永逸。5.2 培養(yǎng)“先設(shè) RLS再寫業(yè)務(wù)”的習(xí)慣在 Supabase 項(xiàng)目里所有跟數(shù)據(jù)有關(guān)的操作的第一步就是設(shè)置 RLS。如果表的 RLS 沒建好就別碰業(yè)務(wù)邏輯。我見過不少團(tuán)隊(duì)在初期用 anon key 調(diào)接口數(shù)據(jù)裸奔了幾個月才發(fā)現(xiàn)等用戶量上來再補(bǔ)策略時(shí)已經(jīng)晚了不少。建議剛啟一個表立即空寫一個極端保守的策略“只允許 authenticated 且 uid 匹配”的策略后面再放寬。5.3 善用 Dashboard 的查詢?nèi)罩居?到問題不要瞎猜Supabase Dashboard 的 Logs 面板可以看數(shù)據(jù)庫、Auth、Realtime 的日志。點(diǎn)擊某個請求還能看到 SQL 本體這對排查“為什么這條查詢被拒絕”非常有效。比如你會看到一行日志里帶著new row violates row-level security policy就知道是 RLS 的with check沒通過而不是代碼邏輯 bug。5.4 一個用于演示的完整代碼結(jié)構(gòu)最后把演示項(xiàng)目的目錄結(jié)構(gòu)寫出來算是一個可抄作業(yè)的參考src/ components/ TaskCard.jsx TaskList.jsx AuthForm.jsx lib/ supabase.js hooks/ useAuth.js useTasks.js pages/ Dashboard.jsx Login.jsx任務(wù)列表頁的流程掛載時(shí)拉取任務(wù)然后訂閱 tasks 表變化按鈕觸發(fā)更新、刪除時(shí)調(diào)用 SDK 對應(yīng)方法附件上傳先調(diào)用 Storage 拿到文件路徑再更新任務(wù)表的 attachments 字段。整體代碼量很輕但功能完整。我自己在本地搭這套東西的時(shí)候最大的體驗(yàn)是Supabase 把“做后端”這件事的門檻降到極致同時(shí)又留有足夠的深度。免費(fèi)層級的限制對個人項(xiàng)目來說絕對夠用如果以后用戶增長可以平滑切到按量付費(fèi)或自托管生態(tài)和服務(wù)穩(wěn)定度也越來越好。如果你正處在“想做個自己作品但不想寫一堆服務(wù)器代碼”的階段我建議直接拿這個演示項(xiàng)目開刀跑一遍下來后端的基本功力也就練出來了。