Supabase列级安全配置替代方案咨询

你不需要为单个字段拆分独立表，Supabase底层基于PostgreSQL，原生支持列级权限管控，搭配现有RLS能力就能低成本实现is_banned字段可见不可改、其余字段可正常读写的需求，以下是按推荐度排序的可行方案：

方案1：原生列级授权（优先选，零冗余） #

PostgreSQL本身就支持针对角色分配列级别的操作权限，完全匹配你的需求：给访问角色授予is_banned字段的查询权限，收回该字段的写入、修改权限，其余字段正常开放读写权限即可，不需要改表结构，也不需要写额外的业务校验逻辑。
直接执行以下SQL即可完成配置：

-- 给匿名用户、登录用户开放整表查询权限
GRANT SELECT ON 你的业务表名 TO anon, authenticated;

-- 先给两类用户开放整表的写入、修改权限
GRANT INSERT, UPDATE ON 你的业务表名 TO anon, authenticated;

-- 单独收回两类用户对is_banned字段的写入、修改权限
REVOKE INSERT (is_banned), UPDATE (is_banned) ON 你的业务表名 FROM anon, authenticated;

这个权限规则是数据库层面强制生效的，无论RLS策略如何配置，普通用户尝试修改is_banned时都会直接触发权限报错，根本无法修改字段值，可靠性远高于业务层校验。而且这个写法不需要枚举所有非敏感字段，后续新增业务字段时默认就有读写权限，不需要额外调整权限配置。

方案2：RLS列级校验（适合细粒度权限场景） #

如果你需要给高权限角色（比如管理员、服务端角色service_role）开放is_banned的修改权限，仅禁止普通用户修改该字段，列级授权的灵活度不够，可以直接在RLS更新策略里加字段校验规则：

-- 普通用户更新策略：允许编辑自己有权限操作的行，但不能修改is_banned字段
CREATE POLICY "普通用户可编辑非敏感字段" ON 你的业务表名
FOR UPDATE TO authenticated
USING (
  -- 这里可以叠加你原有的行级权限判断逻辑，比如仅作者可编辑自己的内容: author_id = auth.uid()
  true
)
WITH CHECK (
  -- 校验修改后的is_banned和修改前的值完全一致，即不允许修改该字段
  is_banned = OLD.is_banned
);

-- 给管理员/服务端角色单独开放全字段修改权限
CREATE POLICY "高权限角色可编辑所有字段" ON 你的业务表名
FOR UPDATE TO service_role
USING (true)
WITH CHECK (true);

这个方案可以和你现有的RLS规则完全融合，不需要额外做权限拆分，适合权限规则更复杂的业务场景。

不推荐拆独立私有表的原因 #

给每个业务表额外配套敏感字段私有表的方案维护成本极高，长期来看实用性很差：

• 所有涉及该表的查询都需要额外做联表操作，增加语句复杂度的同时会带来额外性能开销
• 后续调整表结构时，需要同步维护两张表的字段、关联关系、RLS策略，很容易出现配置遗漏
• 外键约束、触发器、数据备份等配套逻辑都需要双份配置，随着业务表增多会形成很重的技术债

内容的提问来源于stack exchange，提问作者Dragonsnap