update() 方法 permission denied 是因数据库表 update 权限默认为 false，需在 schema.json 中设 "update": true 并上传 DB Schema；云函数可绕过前端权限限制；H5 需配置 manifest.json 的 useUniCloud；where().update() 全表扫描性能差，doc(id).update() 更高效稳定；批量更新应分批用 doc(id).update()；时间戳自动刷新靠 schema 中 force: "now" 规则；事务须显式 commit/rollback，否则导致超时；真实业务关键在权限、索引与可追溯性三者齐备。
update() 方法为什么总是 permission denied
不是代码写错了，而是数据库表的更新权限没开。uniCloud 默认所有 collection 的 update 权限为 false，哪怕你在控制台勾选了“初始化权限”，也可能因本地 schema.json 文件未上传而失效。
检查路径：uniCloud-aliyun/database/xxx.schema.json（或 uniCloud-tcb），确认 "permission" 节点中包含："update": true
- 改完必须右键该文件 → 「上传 DB Schema」，仅保存不生效
- 若用云函数操作，权限由云函数身份决定，不受前端限制——这是绕过权限问题的常用方式
- H5 端需确保
manifest.json中"h5": { "useUniCloud": true }已配置，否则直连被禁用
where().update() 和 doc(id).update() 怎么选
where().update() 是全表扫描式更新，doc(id).update() 是索引驱动的精准更新。数据量一过百，前者就容易超时或触发频控；后者稳定、快、可预测。
- 要批量更新已知 ID 列表？先用
where({ _id: db.command.in(idList) }).get()拿到文档，再循环调用doc(id).update() - 别用
where({ _id: db.command.in(idList) }).update()——它仍是条件匹配，不走索引，性能和事务支持都不如逐个doc() - 单次事务内最多 10 次操作（阿里云限制），所以 ID 列表建议 ≤ 50，分批提交更稳妥
更新时怎么保证时间戳自动刷新
靠 DB Schema 的 "force" 规则最可靠。比如想每次更新都重置 updated_at 字段，不能只靠前端传值或云函数手动赋值——容易漏、易被绕过。
在 xxx.schema.json 的对应字段定义里加：
"updated_at": {
"force": {
"rules": "now"
}
}
- 该规则在数据库服务端强制生效，无论请求来自前端还是云函数
- 配合轮询方案时，这个字段是判断增量的唯一可信依据
- 注意：字段类型必须是
Date，且索引需单独创建（Schema 不自动建索引）
云函数里更新失败但没报错？检查事务 commit
用了 db.startTransaction() 却没显式 commit() 或 rollback()，会导致连接挂起、后续请求卡住，甚至超时后云函数直接终止——但错误日志里可能只显示 “timeout”，看不出根源。
- 事务内所有操作必须轻量：禁止 HTTP 请求、文件读写、复杂计算
- 云函数默认超时 5 秒，处理 >20 条记录时务必在函数配置里调高至 15–30 秒
-
catch块里必须写await transaction.rollback()，否则未关闭事务会持续占用资源
真实业务中，最难的不是写对那行 update()，而是让每一次更新都可追溯、可回滚、可对齐权限与索引——这三样漏一个，上线后就容易查不到数据、改不掉脏值、或者突然全表锁死。
