Supabase 中触发器（如 update_quest_data）在客户端插入 feedback 时未更新 quests 表，根本原因是 quests 表缺少允许 UPDATE 操作的行级安全（RLS）策略；而通过 Supabase Dashboard（即后台管理权限）操作时绕过 RLS，故能正常执行。
supabase 中触发器在客户端查询中未更新关联表，根本原因是 `quests` 表缺少允许 update 操作的行级安全（rls）策略；而通过 supabase dashboard（即后台管理权限）操作时绕过 rls，故能正常执行。
在 Supabase 中，触发器函数（如 update_quest_data()）本身逻辑正确——它在 feedback 插入前更新 quests 的 total_reviews 和 total_score。但关键在于：触发器的执行权限继承自调用上下文。
- ✅ 通过 Supabase Dashboard（或 SQL Editor）插入 feedback：使用的是项目管理员（service_role）密钥，拥有绕过 RLS 的权限，因此 UPDATE quests 可无阻碍执行；
- ❌ 通过客户端 JS 查询（如 supabase.from('feedback').insert(...)）插入：使用的是受限的 anon 或 authenticated 密钥，所有数据库操作均受 RLS 策略约束。此时，即使触发器内部执行 UPDATE quests，若 quests 表未配置允许该角色执行 UPDATE 的 RLS 策略，该语句将被静默拒绝（不报错，但不生效）。
? 解决方案：为 quests 表添加 UPDATE RLS 策略
你需要显式授予 anon 或 authenticated 用户对 quests 表的 UPDATE 权限（仅限触发器所需字段，遵循最小权限原则）：
-- 允许 authenticated 用户更新 total_reviews 和 total_score 字段（推荐） CREATE POLICY "Allow update quest stats for authenticated users" ON public.quests FOR UPDATE TO authenticated USING (true) WITH CHECK ( total_reviews IS NOT NULL OR total_score IS NOT NULL );
? 更安全的做法是限制仅允许触发器修改特定字段（Supabase 2023+ 支持列级策略），但当前主流方式是使用 USING (true) + WITH CHECK 约束业务逻辑合法性，并确保该策略仅启用在 quests 表上，且不开放 INSERT/DELETE 权限。
✅ 验证步骤
- 进入 Supabase 控制台 → Table Editor → quests 表 → Row Level Security → 启用 RLS（若未启用）；
- 在 Policies 标签页 → 点击 Create policy；
- 选择 UPDATE、适用角色（如 authenticated）、策略类型为 With Check，填入上述 SQL；
- 保存后，重新通过客户端提交反馈，观察 quests 表的 total_reviews 和 total_score 是否实时更新。
⚠️ 注意事项
- 不要为 quests 表开启 INSERT 或 DELETE RLS 策略（除非业务必需），避免暴露数据操作风险；
- 若应用支持匿名用户提交反馈，需将策略目标角色设为 anon，但务必评估安全影响；
- 触发器中 RETURN NEW 是必需的（符合 BEFORE INSERT 触发器规范），无需修改；
- 建议为 total_score 和 total_reviews 添加 CHECK 约束防止负值：
ALTER TABLE quests ADD CONSTRAINT quests_total_reviews_non_negative CHECK (total_reviews >= 0), ADD CONSTRAINT quests_total_score_non_negative CHECK (total_score >= 0);
正确配置 RLS 后，客户端插入与后台操作将行为一致——触发器真正“可执行”，数据一致性得到保障。
