内功篇Paid
6、数据安全 RLS
上一课我们成功地为网站装上了“前门”，用户现在可以通过 Google 账号安全地登录了。这是一个巨大的进步！
但是，正如我们结尾时提到的，我们还面临两个关键问题：
1、我们没有地方存储用户的自定义信息，比如他们的昵称、个人简介等。
2、我们的数据库就像一个空旷的大厅，没有任何安全隔离。
这一课，我们将一举解决这两个问题，学习如何为每个用户创建他们专属的、安全的“个人档案室”。这就要用到 Supabase 的核心安全功能——行级安全策略 (Row-Level Security, RLS)。
在开始操作前，你必须先理解 Supabase 安全模型的两个基本概念。
核心一：两把关键的“钥匙” (API Keys)
在你的 Supabase 项目后台“API 设置”里，你会看到很多密钥，但其中最重要的有两个，你必须清楚它们的区别：
| 钥匙类型 | 中文名 | 在哪里用？ | 权限如何？ |
|---|---|---|---|
anon public | 前端访客钥匙 | 用在你的前端代码里 (比如 React, Vue 应用中)。 | 低权限。它是一个“匿名”钥匙，它能做什么完全取决于下面要讲的 RLS 策略。 |
service_role | 后端超管钥匙 | 只能用在安全的后端环境 (比如 Vercel Edge Functions, Next.js 服务器)。 | 最高权限 (上帝模式)。它可以无视所有 RLS 策略，对数据库进行任何操作。 |
安全红线警告：
anon public 钥匙是可以也应该暴露在你网站的前端代码里的，这很安全，前提是你启用了 RLS。
service_role 钥匙是你的最高机密！绝对、绝对、绝对不能把它写在前端代码里，或者上传到公开的 GitHub 仓库。泄露它等于把你的整个数据库拱手让人。
核心二：为用户创建“个人档案室” (Profiles 表)
auth.users 表只应该存放认证的核心数据。如果你想存储用户的昵称、个人简介、会员等级等应用特有的数据，最佳实践是：
1、回到我们熟悉的 Table Editor，点击 “Create a new table”，创建一个名为 profiles 的新表。