云函数查数据库前必须在unicloud控制台手动配置表权限，否则即使只调get()也会返回空数组或permission denied；默认read为false，需设为true或{"auth":"user"}，且前端禁止直连，权限校验必须在云函数内通过event.userinfo联动实现。
云函数里查数据库前必须配好表权限
uniCloud 数据库默认禁止任何读写，哪怕只调 get() 也会返回空数组或 permission denied。这不是代码问题，而是控制台没点几下鼠标。
权限配置不在代码里，也不在云函数文件中，必须去 uniCloud 控制台手动操作：
- 进入对应服务空间 → 左侧「数据库」→ 点击目标表名 → 右上角「表结构」→ 切到「权限」标签页
- 刚建的表默认是
"read": false，至少得改成"read": true - 若需按用户身份控制（比如仅登录用户可读），要设为
"read": {"auth": "user"}，并确保已启用uni-id - 字段名含驼峰（如
userName）可能触发校验失败，建议统一用下划线（user_name）
前端不能直连数据库，所有权限逻辑必须收口到云函数
uniCloud.database().collection('orders').get() 这行代码在 H5 或小程序里能编译通过，但运行时一定失败——uni-app 前端 SDK 明确禁用直连，这是安全策略，不是 bug。
真正的权限判断只能发生在云函数内部，靠 event.userInfo 和数据库规则联动：
- 云函数被调用时，
event自动带userInfo（含uid、role等，前提是启用了uni-id） - 查询时用
db.collection('orders').where({ user_id: event.userInfo.uid }).get()，而非全量查再前端过滤 - 若需 RBAC（角色权限），可在云函数里先查
uni-id-users表拿到role_id，再 join 权限表或查缓存 - 避免在云函数里做复杂权限计算，高频场景建议把角色-权限映射预存为 JSON 字段或独立缓存集合
动态权限变更后，旧 token 不会自动失效
用户权限调整（比如管理员把某人从「编辑者」降为「查看者」）后，ta 当前持有的 token 仍有效，直到过期。这不是 uniCloud 的缺陷，而是 JWT 的通用行为。
要让权限实时生效，得配合主动机制：
- 在关键操作前，云函数里加一层
uniID.checkPermission()（需安装uni-id并配置config.json） - 对敏感操作（如删除订单），云函数不依赖前端传来的
role，而是重新查uni-id-users表确认当前权限 - 前端登出时调用
uniID.logout()清 token；服务端也可调用uniID.refreshToken()强制刷新 - 不要在前端 localStorage 存 role 字符串并据此隐藏按钮——这纯属障眼法，后端必须二次校验
上传文件时 cloudPath 的路径和权限容易漏配
调用 uniCloud.uploadFile() 时，cloudPath 若以 / 开头（如 /images/1.jpg），会直接报错；若不带扩展名（如 avatar），文件可能无法正常访问或下载失败。
更隐蔽的问题是：云存储文件权限默认是私有，即使数据库里存了 fileID，前端调 uniCloud.downloadFile() 仍可能 403。
-
cloudPath必须是相对路径且含扩展名，例如images/avatar_abc.jpg - 如需前端直链访问，上传时加
customOptions: { isPublic: true }，或在控制台「云存储」→「权限设置」里开公共读 - 若走私有访问，前端必须通过云函数中转生成临时下载链接（调
uniCloud.getTempFileURL()） - 别把权限逻辑写在上传云函数里——上传和权限应解耦，上传只管存，权限由后续业务云函数或数据库规则控制
where 条件，或者 event.userInfo 根本没被正确解析。
