📢 แจ้งเตือน: msdn victory/article/details/

1. 项目概述：当数据库“沉默”时，我们在想什么？

做微信小程序云开发的朋友，估计都遇到过这么个场景：前端页面写得漂漂亮亮，逻辑也跑得通，但一到调用数据库，要么数据死活读不出来，页面一片空白；要么想新增一条记录，结果弹窗提示“权限校验失败”。这时候，你看着控制台里那个不痛不痒的报错，心里大概会飘过一句：“我明明按照文档写的啊！” 没错，这就是典型的云开发数据库权限问题。它不像代码语法错误那样直接给你标红，更像一个隐形的守门员，在你以为万事俱备的时候，轻轻说一句“此路不通”。

云开发的数据库权限系统，本质上是一套声明式的安全规则。它不是你熟悉的那个在后端用 if-else 判断用户角色的逻辑，而是一套在云端、在数据层面预先定义好的“访问合同”。很多从传统后端开发转过来的开发者，初期最容易在这里栽跟头——我们习惯了在服务器代码里为所欲为，但云开发要求我们把数据安全的思考，前置到数据库设计的环节。今天，我们就来彻底拆解这个“守门员”的规则手册，从原理到实操，从配置到排查，让你不仅知道怎么改，更明白为什么要这么改，下次再遇到权限问题，能一眼看穿症结所在。

2. 权限系统的核心原理：不只是“开关”

很多人把数据库权限理解成一个简单的“开/关”按钮，认为设置了“所有用户可读”就万事大吉。实际上，云开发的权限模型要精细和强大得多。它的核心是基于 每条记录 和 每个操作 进行动态鉴权。

2.1 安全规则：你的数据“宪法”

云开发数据库的安全规则，是一套用类 JSON 语法（实际是 JSON 的超集，支持函数和表达式）编写的规则集。你可以把它想象成你数据库的“宪法”。它不关心你的业务逻辑具体是什么，只关心两件事： 谁（操作者） 想对 什么数据（记录） 进行 何种操作（增删改查） 。

这套规则在云端独立运行，早于你的云函数逻辑（如果使用云函数调用数据库）或客户端请求被执行。这意味着，即使你的云函数代码逻辑完全正确，如果安全规则不允许，请求也会在抵达你的数据库之前被驳回。

2.2 核心概念： `auth` 、 `doc` 与 `resource`

理解规则，必须先吃透三个最核心的变量：

auth 对象 ：代表当前请求的发起者。在小程序端发起请求时， auth 就包含了该微信用户的 openid 。这是权限判定的基石。 auth.openid 是系统自动注入的，你无法伪造。在云函数端发起请求时，你可以指定一个“身份”（通过 cloud.getWXContext() 获取 OPENID 传入），如果不指定，则代表以“管理员”身份操作，默认绕过所有权限检查（需在云函数中开启 ignorePermissionCheck ，但 极度不推荐 在生产环境常规操作中使用）。
doc 函数与 $ 通配符 ： doc('collection/id') 用于匹配一条具体的记录。而 $ 通配符则用于匹配集合下的所有文档，或者文档内的字段。例如， match /collection/{docId} {...} 中的 {docId} 就是一个通配符，代表集合中的任意文档ID。
resource 对象 ：代表即将被操作的数据对象。在创建 ( create ) 规则中， resource 是客户端试图写入的数据；在更新 ( update ) 或替换 ( write ) 规则中， resource 是请求中携带的、将要生效的新数据。你可以通过 resource.data 访问其字段。

2.3 四种操作类型的细微差别

规则针对四种操作类型进行定义： read （读）、 create （创建）、 update （更新）、 delete （删除）。这里最容易混淆的是 update 和 write 。

update ：仅针对更新操作。在 update 规则中，你除了可以访问 resource.data （新数据），还可以通过 request.resource.data 访问 请求中携带的、将要变更的字段 。这是一个关键点，因为 update 操作可能只更新部分字段。
write ：这是一个“总称”，它涵盖了 create 、 update 和 delete 三种写入操作。当你对这三种操作的规则要求完全一致时，可以用 write 来统一声明，避免重复代码。但注意，在 write 规则里，你无法像在 update 规则里那样精细地区分是创建还是更新。

实操心得 ：我个人的习惯是，除非规则极其简单（如“仅创建者可写”），否则我会分开定义 create 、 update 、 delete 规则。因为在实际业务中，“谁能创建”、“谁能更新自己的某个字段”、“谁能删除”往往是不同的逻辑。分开写虽然代码量多一点，但后期维护和排查问题时，逻辑清晰度会高很多。

3. 从零开始：配置安全规则的完整流程

光说不练假把式，我们现在就进入实战环节。假设我们要为一个“留言板”小程序配置数据库权限。这个留言板的需求是：所有人可以看所有留言，但只有留言发布者可以编辑和删除自己的留言，同时，发布留言时必须自动记录发布者的 openid 。

3.1 第一步：设计数据集合结构

首先，在云开发控制台创建一个集合，比如叫 messages 。每条留言文档我们设计如下结构：

{
  “_id”: “自动生成ID”,
  “