ClientDB权限校验由数据库schema配置控制，非前端代码决定；常见问题包括未登录、权限拒绝、查无数据却无报错，根源在于schema未生效或配置错误，需严格按JQL语法编写规则并调试验证。
ClientDB 的权限校验不是前端代码控制的，而是靠数据库表的 schema 配置生效——写错或漏配，uniCloud.database().collection(...) 就会直接报错或静默拒绝。
为什么调用 uniCloud.database() 会报 “未登录” 或 “无权限”？
这不是 clientDB 本身的问题，而是 schema 没生效或没配对。常见现象包括：
-
Failed to get current user info: current user is anonymous：说明用户未登录，或登录后 token 未被 clientDB 正确识别（通常因未引入uni-id或未调用uniId.init()） -
permission denied：schema 中的read或write规则不满足，比如"auth.uid == doc._id"写成了"auth.uid === doc._id"（JQL 不支持严格等于） - 查不到数据但无报错：
read权限返回空数组，而非错误，容易误判为逻辑问题
schema 中的 read/write 规则怎么写才有效？
JQL 权限规则是表达式，运行在云端，不执行 JS 全语法。关键点：
- 必须用双等号
==，不能用===；字符串要用双引号"admin"，不能用单引号 -
auth对象只包含uid、role、permission等字段，不包含自定义扩展字段（如auth.profile.name不可用） - 角色判断推荐用
"admin" in auth.role，而不是auth.role == "admin"（因为role是数组） - 字段级权限需在
field节点下配置，例如隐藏敏感字段："phone": {"read": "auth.role == 'admin'"}
clientDB 查询时如何触发权限校验？
只要用了 uniCloud.database()，所有操作都会走 schema 校验——但注意：
-
get()和add()会校验read和write，但remove()和update()默认只校验write，除非你在 schema 里显式写了"delete": ...或"update": ... -
where条件不影响权限判定，哪怕你写where("false")，只要请求发出去，权限仍会被校验 - 使用
clientDB的<unicloud-db></unicloud-db>组件时，组件内部调用的也是get()，所以同样受 schema 约束
调试权限规则最直接的方法
别猜，直接看日志和返回值：
- 在 uniCloud 控制台打开「数据库」→「表」→「权限配置」，点击「测试规则」，填入模拟的
auth和doc数据，实时验证表达式结果 - 在 HBuilderX 中右键表 →「下载 schema 到本地」，改完立刻上传，避免线上误配导致全站读写失败
- 临时开启
"read": true排查是否为权限问题，确认后再收紧，切忌长期留开放规则
真正卡住人的地方，往往不是规则写得多复杂，而是 auth.uid 拿不到（登录流程断了）、schema 没上传成功、或者用了 uni-id-common 却没配好 config.json 里的 uniId 字段——这些细节比语法更常导致“明明写了权限却没生效”。
