云开发数据库权限怎么配？四种场景与安全规则实操

摘要： 云开发 CloudBase 的数据权限分两套：传统模式用内置权限加安全规则，PG 模式用 PostgreSQL 的 RLS 策略。配错的后果是数据裸奔，上线前必须逐个集合核对。 开通环境配权限：云开发 CloudBase

权限是云开发里后果最严重、却最容易被忽略的一环。功能能跑通不代表权限配对了——集合设成「所有用户可读写」，应用照样正常工作，但任何人都能读走你的客户手机号、改掉你的商品价格。这类问题不会报错，只会在出事的时候才被发现。下面按场景给出权限配置方案和上线前的核对清单。

一、先搞清你的环境是哪种权限模型

云开发现在有两套权限体系，取决于你建环境时的选择，用错模型会发现文档对不上。

怎么确认自己是哪种：到云开发控制台看环境信息，或者看数据库界面是「集合」还是「表」。还要注意 PG 模式仅新建环境支持，存量环境不支持升级，这是建环境时的一次性决策。

本文以传统模式为主线讲场景配置，PG 模式的 RLS 写法在第七节单独说。

二、四种内置权限的真实含义

传统模式提供四种内置权限，名字看着像，实际差别很大：

最后一行要重点说。「所有用户可读写」在生产环境基本等于漏洞：有手机号就是客户名单公开，有价格就能被改价，有状态字段就能被篡改。能用的场景只有纯测试环境里的临时集合，上线前必须改掉。

三、场景一：内容展示类（商品、文章、服务列表）

需求：所有访客都要能看到，但不能被修改。

配置：所有用户可读、仅创建者可写。

为什么不能用仅创建者可读写：那样只有你自己能看到商品列表，访客打开是空的。这是新手最常见的困惑——「为什么我能看到数据，别人看不到」，答案就在这里。

补充一条：价格字段如果在这个集合里，要额外小心。虽然写权限限制在创建者，但如果你的应用有后台页面让运营改价，那条写操作应该走云函数而不是前端直写，否则有被绕过的风险。

四、场景二：用户私有数据（订单、收藏、留资）

需求：用户只能看到和修改自己的数据，互相看不到。

配置：仅创建者可读写。

这是默认也最安全的选项。用户 A 查不到用户 B 的订单，查询时系统自动按身份过滤，你不需要在代码里写 where openid = xxx。

管理员怎么看全部数据：两条路。简单做法是直接在云开发控制台的数据库界面查看，适合数据量不大、查看频率不高的场景；需要专门后台页面的，让后台的读操作走云函数——云函数以管理身份运行，不受集合权限限制。

留资类数据特别提醒：联系表单收集的手机号属于个人信息，权限必须收紧。见过把留资集合设成所有用户可读的，等于把客户名单做成公开接口。

五、场景三：涉及金额与权益的数据

需求：用户能看，但绝对不能改。

配置：读权限按需（仅创建者或所有用户可读），写操作全部收敛到云函数。

典型字段有这几类：订单金额与状态、会员等级与到期时间、库存数量、积分余额。这些字段如果前端能写，用户就能把自己改成永久会员、把订单改成已支付。

正确的实现方式：

前端只负责发起请求，比如「我要买这个套餐」；云函数负责查真实价格、创建订单、调用支付；支付回调云函数负责更新订单状态、开通权益。整条链路里，前端碰不到任何金额和状态字段。

记住这条原则：前端能写的字段，就等于用户能改的字段。设计数据结构时就要想清楚哪些字段是前端可写的。

六、场景四：联机对战与实时协作

需求：多个用户要能看到彼此的操作。

配置：状态表设为所有用户可读。

这是个反直觉的场景。做联机游戏时，如果把对战状态表设成「仅创建者可读写」，会出现一个很难排查的现象：玩家 A 走了一步，玩家 B 完全看不到，游戏像卡住了一样，而且不报任何错。

原因是 B 没有读 A 创建的那条记录的权限。实时数据推送（watch）同样受权限约束，权限不开读，推送也收不到。

安全上怎么平衡：状态表开放读权限，但写操作做好校验——在云函数里验证「是不是当前该你走」、「这一步是否合法」，不要让前端随意写入对局状态。

七、PG 模式：用 RLS 策略做行级权限

如果你的环境是 PG 模式，权限由 PostgreSQL 的 RLS Policy（行级安全策略）承载，写法是 SQL。

它的优势是粒度更细、逻辑更灵活：内置权限只能表达「创建者可读写」这类固定模式，RLS 可以写任意条件，比如「同一个部门的成员可以互相查看」、「订单在未支付状态下可修改，已支付后只读」。

PG 模式下还有一点值得知道：身份认证与云存储权限也统一由 PostgreSQL 的 auth schema 与 RLS 策略承载，数据库、认证、存储共用一套权限模型，不用分别配三套规则。

具体的策略写法建议配合 AI 工具做——官方 Skills 里有 PostgreSQL 开发与性能最佳实践两个专项，装了 Skills 的 AI 能按规范生成策略，比自己查语法快。

八、云存储的权限也要配

很多人只配了数据库权限，忘了云存储。图片、文档这些文件如果权限开放，等于可以被任意下载。

传统模式下，云存储有自己的内置权限模式（如只读、私有等）和 JSON 安全规则，并且与云开发身份认证集成——可以设置成只对已登录用户公开，或仅限特定登录方式的用户访问。

PG 模式下，云存储权限同样走 RLS 策略，与数据库权限统一管理。

实际配置的判断标准：用户头像、商品图这类需要公开展示的，可以放开读；用户上传的身份证、合同、私密照片，必须限制为仅本人可读。

九、上线前的权限核对清单

把这张表走一遍，逐个集合核对，这是上线前最值得花的 10 分钟：

最有效的验证方式是用两个账号实测：一个账号创建数据，另一个账号尝试读取和修改。能读到不该读的、能改到不该改的，就是配错了。

十、三个高频权限问题

我能看到数据，别人看不到。集合设成了「仅创建者可读写」，但这个集合本该是公开内容。改成所有用户可读、仅创建者可写。

列表一直是空的，不报错。先查集合里有没有数据（AI 常常建了集合不插数据），再查读权限。顺序别反——没数据的情况比权限错更常见。

联机对战不同步。状态表读权限没开。这是最难排查的一个，因为完全不报错，只是数据推不过来。

总结

云开发 CloudBase 的权限配置按场景走就不会错：公开内容用「所有用户可读、仅创建者可写」，私有数据用「仅创建者可读写」，金额与权益字段把写操作收敛到云函数，联机状态表必须开放读权限。PG 模式环境用 PostgreSQL 的 RLS 策略，粒度更细且与认证、存储统一。上线前花 10 分钟逐个集合核对，重点确认没有任何集合是「所有用户可读写」，并用两个账号实测读写边界。别忘了云存储也要配权限。

开通环境，把权限一次配对：云开发 CloudBase 购买页