Supabase RLS 无限递归错误排查与修复：从报错到生产级解决方案

快速答案

• 核心结论：Supabase RLS 无限递归错误通常由策略中的自引用或循环依赖导致，PostgreSQL 会主动检测并抛出 infinite recursion detected 错误。
• 第一检查：查看报错信息中提到的表名，检查该表所有 RLS 策略是否查询了自身或形成了 A→B→A 的循环依赖。
• 最小修复方案：对于简单自引用，重写策略避免查询同一张表；对于复杂循环依赖，将权限检查逻辑封装在 SECURITY DEFINER 函数中，以 postgres 角色执行。
• 适用边界：该方案适用于 Supabase 所有版本（包括自托管和云服务），但 SECURITY DEFINER 函数会绕过 RLS，仅应在受控场景下使用。
• 生产警告：切勿在生产环境中直接使用 SECURITY DEFINER 函数而不做权限审计，否则可能导致数据泄露。

它解决什么问题

Supabase 的 Row-Level Security (RLS) 允许你在数据库层面实现细粒度的行级访问控制。但当 RLS 策略编写不当，尤其是出现自引用或循环依赖时，PostgreSQL 会抛出 infinite recursion detected in policy for relation "table_name" 错误，导致查询失败、应用崩溃。

典型场景包括：

• 多租户应用：每个用户只能看到自己的数据，策略中查询了同一张表来判断用户权限
• 基于角色的访问控制：策略需要查询角色表，而角色表本身也有 RLS 策略
• Supabase Storage 文件访问：存储桶的 RLS 策略与数据库表形成循环依赖
• 与 Next.js、React、Flutter 等前端框架结合：通过 Supabase 客户端直接查询时触发递归

根因分析：RLS 递归是如何发生的

RLS 策略本质上是一个附加在查询上的 WHERE 子句。当 PostgreSQL 执行查询时，它会检查目标表的 RLS 策略，如果策略中又查询了同一张表（或通过其他表间接形成循环），就会触发递归检测。

示例：自引用递归

SQL
-- 假设有一个 tasks 表，用户只能看到自己创建的任务
CREATE POLICY "users can see own tasks" ON tasks
  FOR SELECT
  USING (user_id = auth.uid() OR EXISTS (
    SELECT 1 FROM tasks WHERE assigned_to = auth.uid()
  ));

这个策略在 USING 子句中又查询了 tasks 表，导致 PostgreSQL 在评估策略时再次触发 RLS 检查，形成无限递归。

示例：循环依赖递归

SQL
-- 表 A 的策略查询表 B
CREATE POLICY "a_policy" ON table_a
  FOR SELECT
  USING (EXISTS (SELECT 1 FROM table_b WHERE table_b.user_id = auth.uid()));

-- 表 B 的策略查询表 A
CREATE POLICY "b_policy" ON table_b
  FOR SELECT
  USING (EXISTS (SELECT 1 FROM table_a WHERE table_a.user_id = auth.uid()));

当查询表 A 时，策略 A 触发查询表 B，表 B 的 RLS 策略又触发查询表 A，形成 A→B→A 的循环。

两种解决方案对比

方案一：重写 RLS 策略（推荐）

核心思路是避免在策略中查询自身或形成循环。通常可以通过以下方式实现：

1. 使用 auth.uid() 直接比较：如果权限逻辑只是基于当前用户 ID，直接比较即可，无需子查询
2. 将权限判断逻辑移到应用层：在客户端先获取用户角色，再构造查询条件
3. 使用触发器或物化视图：预计算权限结果，避免运行时递归

示例：修复自引用递归

SQL
-- 错误策略
CREATE POLICY "users can see own tasks" ON tasks
  FOR SELECT
  USING (user_id = auth.uid() OR EXISTS (
    SELECT 1 FROM tasks WHERE assigned_to = auth.uid()
  ));

-- 修复后：将 assigned_to 的判断移到应用层，或使用单独的权限表
CREATE POLICY "users can see own tasks" ON tasks
  FOR SELECT
  USING (user_id = auth.uid());

示例：修复循环依赖

SQL
-- 假设有一个 organizations 表和 members 表
-- 用户只能看到自己所在组织的记录

-- 错误：organizations 的策略查询 members，members 的策略查询 organizations
CREATE POLICY "org_policy" ON organizations
  FOR SELECT
  USING (EXISTS (
    SELECT 1 FROM members WHERE members.org_id = id AND members.user_id = auth.uid()
  ));

CREATE POLICY "member_policy" ON members
  FOR SELECT
  USING (EXISTS (
    SELECT 1 FROM organizations WHERE organizations.id = org_id
  ));

-- 修复：只在一个表中保留权限判断
-- 在 organizations 上保留策略，members 上移除或简化
DROP POLICY IF EXISTS "member_policy" ON members;
CREATE POLICY "member_policy" ON members
  FOR SELECT
  USING (user_id = auth.uid());

方案二：使用 SECURITY DEFINER 函数（备选）

当无法通过重写策略解决循环依赖时，可以将权限检查逻辑封装在 SECURITY DEFINER 函数中。该函数以创建者权限执行，绕过 RLS 检查。

步骤 1：创建函数

SQL
CREATE OR REPLACE FUNCTION check_user_org_access(org_id bigint)
RETURNS boolean
SECURITY DEFINER
SET search_path = public
AS $$
BEGIN
  -- 这里直接查询 members 表，因为函数以 postgres 权限执行，不会触发 RLS
  RETURN EXISTS (
    SELECT 1 FROM members
    WHERE members.org_id = check_user_org_access.org_id
      AND members.user_id = auth.uid()
  );
END;
$$ LANGUAGE plpgsql;

步骤 2：在 RLS 策略中使用函数

SQL
CREATE POLICY "org_policy" ON organizations
  FOR SELECT
  USING (check_user_org_access(id));

步骤 3：授权函数执行权限

SQL
-- 允许 authenticated 角色执行该函数
GRANT EXECUTE ON FUNCTION check_user_org_access TO authenticated;

常见报错与排查

错误 1：infinite recursion detected in policy for relation "table_name"

报错信息：ERROR: infinite recursion detected in policy for relation "table_name"

解决方案：

1. 检查报错中提到的表的所有 RLS 策略
2. 查找策略中是否查询了同一张表或形成了循环依赖
3. 按上述方案一或方案二修复

错误 2：new row violates row-level security policy for table "table_name"

报错信息：ERROR: new row violates row-level security policy for table "table_name"

解决方案：

• 检查 INSERT 或 UPDATE 操作是否满足 WITH CHECK 条件
• 确保插入的数据中的 user_id 等字段与 auth.uid() 匹配
• 确认策略的 AS PERMISSIVE 或 AS RESTRICTIVE 设置正确

错误 3：permission denied for table table_name

报错信息：ERROR: permission denied for table table_name

解决方案：

• 确认 RLS 策略已正确创建并启用
• 确认用户角色（anon/authenticated）有对应的策略
• 检查是否误用了 SECURITY DEFINER 函数导致权限提升

错误 4：query has no destination for result data

报错信息：ERROR: query has no destination for result data

解决方案：

• 在 PL/pgSQL 函数中确保正确使用 RETURN QUERY 或 INTO
• 在客户端确保查询结果被正确消费

生产环境实践与注意事项

1. SECURITY DEFINER 函数的安全风险

SECURITY DEFINER 函数以创建者权限执行，如果创建者是 postgres，它会绕过所有 RLS 策略。这虽然能解决递归问题，但也带来了安全风险。

安全建议：

• 函数创建者使用具有最小必要权限的角色，而非 postgres
• 函数逻辑应严格限制，只执行必要的权限检查
• 对函数输入进行严格验证，防止 SQL 注入
• 定期审计函数的使用情况
• 使用 SET search_path 防止 schema 注入

2. 性能优化

复杂的 RLS 策略会显著降低查询性能，尤其是递归策略。

优化建议：

• 使用 EXPLAIN ANALYZE 分析查询计划，查看策略执行路径
• 为常用查询字段添加索引
• 避免在 RLS 策略中使用子查询或函数调用
• 使用 pg_stat_statements 监控慢查询

3. 并发控制

多个用户同时触发递归策略可能导致数据库连接池耗尽。

建议：

• 设置合理的连接池大小（如 PgBouncer）
• 实现查询超时机制
• 监控数据库连接数

4. 权限最小化

确保 anon 和 authenticated 角色只有最小必要权限。

SQL
-- 撤销不必要的权限
REVOKE ALL ON ALL TABLES IN SCHEMA public FROM anon;
REVOKE ALL ON ALL TABLES IN SCHEMA public FROM authenticated;

-- 只授予必要的权限
GRANT USAGE ON SCHEMA public TO anon, authenticated;
GRANT SELECT ON specific_table TO anon;
GRANT SELECT, INSERT, UPDATE ON specific_table TO authenticated;

5. 网络安全

• 使用 SSL/TLS 连接
• 限制数据库 IP 白名单
• 启用 Supabase 的 Network Restrictions

常见问题 FAQ

Q: 为什么我的 RLS 策略会导致无限递归，即使我只查询了其他表？

A: 无限递归不仅发生在自引用查询中，还可能通过间接循环依赖触发。例如：策略 A 查询表 B，表 B 的 RLS 策略又查询表 A，形成 A→B→A 的循环。PostgreSQL 会检测到这种循环并抛出错误。解决方案是检查所有相关表的 RLS 策略，确保没有形成循环依赖，或者使用 SECURITY DEFINER 函数来打破循环。

Q: 使用 SECURITY DEFINER 函数解决递归问题安全吗？

A: SECURITY DEFINER 函数以创建者权限执行，如果创建者是 postgres，它会绕过所有 RLS 策略。这虽然能解决递归问题，但也带来了安全风险：如果函数逻辑有漏洞，攻击者可能访问到本不该看到的数据。建议：

1. 仅在必要时使用，且函数逻辑应严格限制
2. 函数创建者使用具有最小必要权限的角色
3. 对函数输入进行严格验证，防止 SQL 注入
4. 定期审计函数的使用情况

Q: 如何调试复杂的 RLS 策略递归问题？

A: 调试步骤：

1. 查看 PostgreSQL 日志，找到具体的错误信息和涉及的表名
2. 使用 EXPLAIN ANALYZE 分析查询计划，查看策略执行路径
3. 临时禁用 RLS（ALTER TABLE table_name DISABLE ROW LEVEL SECURITY;）确认问题是否由 RLS 引起
4. 逐个禁用策略，找出导致递归的策略
5. 使用 pg_stat_statements 监控慢查询
6. 在 Supabase Dashboard 的 SQL Editor 中测试简化版的策略

官方参考

• Supabase Storage 错误：数据库 schema 不兼容
• RLS 简化指南