云函数中保证多条数据库操作原子性，必须使用阿里云支持的db.transaction包裹所有操作，或手动实现补偿逻辑；腾讯云、支付宝云暂不支持事务。
云函数里怎么保证多条数据库操作要么全成功、要么全失败
uniCloud 的 db.collection 默认不支持跨集合事务，单个 update 或 add 是原子的，但多个操作组合（比如扣库存 + 写订单 + 更新用户积分）天然不具备原子性。直接顺序执行，中间出错会导致数据不一致。
真正能落地的方案只有两种：用阿里云/腾讯云提供的原生事务能力（仅限对应云服务商），或在云函数里手动实现补偿逻辑。阿里云 uniCloud 支持 db.transaction，腾讯云暂不支持；支付宝云未开放事务 API。
- 阿里云环境下，必须用
db.transaction包裹所有操作，且所有collection必须属于同一服务空间（不能跨 space） - 事务内禁止调用其他云函数、不能使用
uniCloud.uploadFile等非 DB 操作 - 事务超时默认 10 秒，大字段或慢查询容易触发
TransactionTimeout错误 - 事务失败后，
catch中不能重试原事务，需明确返回错误并由前端决定是否重发请求
exports.main = async (event, context) => {
const db = uniCloud.database()
try {
await db.transaction(async () => {
const res1 = await db.collection('goods').doc(event.goodsId).update({ stock: db.command.inc(-1) })
const res2 = await db.collection('orders').add({ ...event.orderData })
const res3 = await db.collection('users').doc(event.userId).update({ points: db.command.inc(event.points) })
if (res1.updated === 0) throw new Error('库存不足')
})
return { success: true }
} catch (err) {
return { success: false, message: err.message }
}
}
为什么 schema 配置了 required 却还是能插入空数据
schema 的 required 字段只在客户端校验和数据库写入前校验生效，但云函数里绕过客户端直连 DB 时，db.collection().add() 不会自动触发 schema 校验 —— 这是常见误解点。
除非显式调用 validate 方法，否则云函数内的写操作完全跳过 schema。这意味着你写的云函数可能把脏数据直接写进库，而前端却一直报“字段必填”。
- 云函数中必须手动加校验：
await db.collection('xxx').validate(data)，失败会抛ValidationError - schema 的
force选项（如"force": true）只对客户端 SDK 有效，对云函数无效 - 如果用了
db.collection().add({ data, rules: 'xxx' })，rules 是安全规则，不是 schema 校验，两者不等价 - 建议把校验逻辑抽成公共函数，在所有云函数入口统一调用，避免遗漏
云对象里怎么处理并发更新冲突（比如抢红包、秒杀）
高并发场景下，多个请求同时读-改-写同一文档，靠普通 update 会丢更新。uniCloud 提供了 db.command.set 和 db.command.inc，但它们本身不解决“读取旧值 → 计算新值 → 写回”这个三步过程的竞态问题。
真正可靠的做法是用数据库的原子操作 + 条件更新，而不是在云函数里做判断。例如库存扣减，不能先 get 再 update，而要用 where 带条件的 update 直接命中。
- 用
db.collection('goods').where({ _id: 'xxx', stock: db.command.gte(1) }).update({ stock: db.command.inc(-1) }) - 检查返回的
updated字段是否为 1，为 0 表示条件不满足（已售罄） - 绝对不要在云函数里用
get+if (data.stock > 0)+update这种模式 - 红包金额分配若需随机拆分，必须在事务内完成全部写入，且每个子红包文档带唯一
seq字段防重复领取
云函数调用链中如何传递上下文与错误定位
一个业务常涉及多个云函数串联调用（比如下单 → 库存校验 → 支付回调 → 发货通知），但 uniCloud.callFunction 默认不透传 requestId 或用户身份，导致日志分散、问题难追溯。
关键不是加日志，而是让每个环节都携带可追踪的标识。uniCloud 的 context 对象里有 clientInfo 和 env，但缺少业务级 traceId。
- 前端首次调用时生成
traceId（如Math.random().toString(36).substr(2, 9)），通过data.traceId传入第一个云函数 - 每个后续云函数调用都显式把
traceId透传到data参数里，不要依赖全局变量 - 云函数日志中统一打印
console.log(`[trace:${event.traceId}] xxx`)，便于 Kibana 或 uniCloud 控制台聚合 - 避免在
catch中只抛new Error('失败')，应带上event.traceId和关键参数摘要，否则线上排查等于盲人摸象
