Supabase CLI 上手实战4 步从本地数据库到云函数部署【免费下载链接】cliSupabase CLI. Manage postgres migrations, run Supabase locally, deploy edge functions. Postgres backups. Generating types from your database schema.项目地址: https://gitcode.com/GitHub_Trending/cli23/cli上周五晚上要上线前你需要给数据库加一张表、再写一个 webhook 函数。想先在本地验证但项目里根本没有本地 Postgres只能直接改线上库——你敢吗Supabase CLI 就是为这种处境准备的命令行工具它把 Supabase 平台Postgres、Auth、Storage、Realtime、Edge Functions整套搬进你的终端本地起全栈、迁移版本化、函数部署都是终端里敲几条命令的事。它是什么一套平台服务装进终端一句话定义Supabase CLI 是 Supabase 的命令行客户端把本地开发栈 数据库迁移 边缘函数 类型生成整合成一套工具链。主要工作流如下和其他常见工具横向对比一下维度Supabase CLIFirebase CLIPrisma CLI开源与否是MIT是是可自托管程度本地完整跑起全部服务依赖 Firebase 托管平台只是数据库工具不含平台典型场景数据库 认证 函数 API 一站式函数托管 静态站部署Schema 管理与迁移学习曲线中等需 Docker 环境中等较低最短时间跑起来一条命令装好按你的平台选一种方式即可平台方式命令macOS / LinuxHomebrewbrew install supabase/tap/supabaseNode 项目npm/pnpm/yarn/bun包管理器npm install -D supabaseNode 项目beta 通道包管理器npm install -D supabasebetaWindowsScoopscoop install supabase先scoop bucket add supabase bucket 仓库地址见 READMELinux 发行版原生包从官方 Releases 下载 .deb / .rpm / .apk 安装没有包管理器的环境还有一条 curl 安装脚本具体地址以仓库 README.md 的 Installation 一节为准。装完执行验证命令supabase --version # 查看当前版本号期望输出长这样打印出supabase version 版本号一行而不是command not found。场景一用 supabase start 起本地全栈开发环境目标一条命令拉起包含 Postgres、Auth、Storage、Realtime、Edge Functions 和 Web 管理界面的完整本地环境。mkdir my-app cd my-app # 建项目目录 supabase init # 生成 supabase/config.toml supabase start # 启动本地全栈服务 supabase status # 查看各服务状态 supabase stop # 用完停掉、释放资源想要带模板的完整项目骨架可以直接改用supabase bootstrap。成功标志start结束时终端会打印一组地址和密钥API URL、DB URL、Studio URL、anon key 等浏览器打开 Studio URL 能看到 Web 数据库界面supabase status显示各容器均为运行中。⚠️ 第一次 start 要下载多个服务镜像明显比后续慢官方建议至少预留 7GB 内存跑全部服务内存紧张时可以用-x排除用不到的容器比如-x imgproxy。场景二数据库变更版本化migrations 与 diff目标每次 Schema 变更都落成带时间戳的.sql迁移文件进版本库谁都能按同样顺序重放。supabase migration new add_users_table # 在 supabase/migrations/ 新建迁移文件 # 编辑生成的 timestamp_add_users_table.sql写入建表等 DDL supabase db diff -f fix_drift # 对比当前库与迁移的差异直接输出为迁移文件 supabase db reset # 重置本地库并按序重放全部迁移 supabase db dump # 把当前库备份成本地 SQL 文件成功标志migration new之后supabase/migrations/下出现按时间戳命名的新.sql文件db reset会依次应用迁移和种子数据supabase/seed.sql数据库回到与仓库一致的可复现状态。⚠️db reset会丢弃你在本地手工写入的一切数据。任何风险操作前先db dump留底。场景三Edge Functions 本地测试与部署目标用 TypeScript 写服务端代码先在本地跑通再部署到远端。supabase functions new hello-world # 在 supabase/functions/ 生成函数骨架 # 编辑生成的 index.ts改你的业务逻辑 supabase functions serve # 本地运行全部函数进行测试 supabase functions deploy hello-world # 部署到已 link 的远端项目 supabase gen types --local # 按本地库 Schema 生成 TypeScript 类型可重定向存入项目成功标志serve打印已加载的函数列表与本地访问地址可用 curl 或前端直接调用验证deploy返回成功gen types输出覆盖表、视图的完整类型定义存进前端项目后数据库访问代码就有自动补全了。⚠️deploy依赖 link 状态报未登录 / 未关联时先执行supabase login和supabase link再重试。从本地走向线上link 远端项目与协作路径可以概括成四步。先supabase login用个人访问令牌登录令牌存在系统密钥链里CI 环境可改用SUPABASE_ACCESS_TOKEN环境变量免交互再supabase link把当前目录关联到远端托管项目然后supabase db push同步 Schemasupabase functions deploy和secrets子命令分别负责函数上线与环境变量。团队协作的锚点是迁移文件是唯一事实源首次db push会在远端建立迁移历史表记录每个已应用的迁移时间戳之后 push 自动跳过已应用的条目多人先后推送不会重复执行。新同事克隆仓库后执行一次supabase db reset本地数据库就和仓库对齐了发现远端漂移时用db diff --linked看差异再补一个新迁移收口。排障手册常见现象与处理现象可能原因处理方式start 报端口冲突config.toml 固定的端口被占用或同机另一个本地栈占用同端口supabase stop停掉对应栈后重试或调整端口配置首次 start 很慢、健康检查失败首次要拉取服务镜像网络不佳等镜像拉取完成超时后重新执行 start部分容器不健康默认启动全部服务内存不足建议约 7GBsupabase start -x gotrue,imgproxy排除不需要的容器db push 提示未关联项目没执行过 login / link先supabase login再supabase linkfunctions deploy 无权限访问令牌过期或缺失重新 loginCI 中设置SUPABASE_ACCESS_TOKENreset 后本地数据全没了reset 的设计就是按迁移重建库养成先db dump备份再 reset 的习惯收尾你的下一步Supabase CLI 的核心价值一句话把本地全栈环境 → Schema 版本化 → 云函数上线压缩成同一套终端命令让本地与远端的状态始终可复现。接下来建议按这个路径走先玩熟status/stop/db reset养成管理本地生命周期的习惯完整走一轮迁移migration new→ 编辑 SQL →db reset验证做一个函数从serve到deploy的全流程并用gen types给前端生成类型对任意命令加--help如supabase db --help阅读参数这是最准的本地文档资源清单仓库 README.md安装方式与核心命令速览各命令的完整行为说明apps/cli/docs/supabase/按命令分文件的参考文档官方 Supabase 文档站的 CLI Reference 与 Local Development 指南以官方文档为准源码结构速查apps/cli/docs/code-structure.md【免费下载链接】cliSupabase CLI. Manage postgres migrations, run Supabase locally, deploy edge functions. Postgres backups. Generating types from your database schema.项目地址: https://gitcode.com/GitHub_Trending/cli23/cli创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考