unicloud定时触发器需在服务端配置，先部署云函数再通过控制台绑定cron表达式（注意utc时区），常见失败原因为时区错误、函数未发布、内部异常无日志、超免费额度或数据库访问问题。
uniCloud 云函数怎么配定时触发器
uniCloud 的定时任务不是在前端写个 setInterval 就行，必须在云函数端配置触发器。触发器是服务端行为，和前端代码完全无关，哪怕 uni-app 项目里没写一行云函数调用，只要触发器生效，云函数就会自动执行。
实操分两步：先写好云函数（比如叫 onTimer），再在 HBuilderX 或 web 控制台为它绑定定时规则。注意：触发器只能绑定到已部署的云函数上，本地调试时不会触发。
- 控制台配置路径：
uniCloud > 云函数 > 选择函数 > 触发器 > 新建定时触发器 - 表达式用标准 cron 格式，例如
0 0 * * *表示每天零点执行（注意：uniCloud 使用的是 UTC 时间，国内需手动 +8 小时换算） - HBuilderX 中右键云函数目录 →「上传并部署」后，才可在控制台看到该函数，才能配触发器
为什么定时云函数总不执行或延迟
最常见原因是时区错位和函数未发布。uniCloud 默认使用 UTC 时间，而你在控制台输入的 0 0 * * * 实际对应的是 UTC 零点（即北京时间早八点），看起来像“没按时跑”，其实是时间理解反了。
另一个高频问题是函数内部出错但没日志反馈：云函数抛出异常、return 前就 throw、或用了未安装的 npm 包，都会导致触发失败，且控制台只显示“执行失败”，不报具体错误——必须去「云函数日志」里查 console.error 或未捕获异常。
- 验证是否真没执行：打开
uniCloud 控制台 > 日志服务 > 选择对应函数 > 时间范围拉长看 - 避免冷启动影响：首次触发或长时间无调用后，函数可能有几百毫秒延迟，但不属于“失败”
- 免费版每日最多 1000 次触发，超限后后续定时直接静默丢弃，不报错也不记录
uni-app 前端能不能主动触发定时云函数
不能。定时触发器是服务端独立调度机制，和前端是否在线、是否调用 uniCloud.callFunction 完全无关。前端能做的只有“手动调用”或“监听结果”，但无法干预定时器本身。
如果你需要“按用户操作延后执行某事”，别硬套定时触发器——应该用云函数内调用 uniCloud.database().collection().doc().set({ scheduledAt: new Date(Date.now() + 60 * 60 * 1000) })，再配合一个每分钟扫一次的定时函数来检查 scheduledAt，这才是可落地的方案。
- 前端误写
uniCloud.callFunction({ name: 'onTimer' })并不能让定时器“提前跑一次”，只是普通调用 - 多个客户端同时调用同一个云函数，不会互相干扰定时逻辑，因为触发器是函数级而非调用级
- 若需“用户点击后 5 分钟发通知”，推荐用
uniCloud.timer（仅阿里云支持）或自建时间轮表 + 定时扫描
云函数里访问数据库慢，是不是定时器的问题
不是。定时器只负责“什么时候调起函数”，不参与函数内部执行逻辑。慢的原因几乎都出在数据库查询设计或权限配置上：比如没加索引、用了 where({}).get() 全表扫描、或云函数的 spaceId 和数据库空间不一致导致跨空间访问延迟高。
尤其注意：云函数默认运行在服务端环境，uniCloud.database() 访问的是当前云空间，不是前端当前登录用户的私有数据池。如果函数里写了 db.collection('user').where({ uid: event.uid }).get()，但 event.uid 是空或非法，就会查不到还卡住几秒。
- 加日志定位瓶颈：
console.time('db-query')/console.timeEnd('db-query') - 确保
database().collection()的集合名拼写正确，大小写敏感，不存在会静默返回空数组 - 阿里云和腾讯云的
get()超时默认是 10 秒，超时后函数直接中断，不会重试
定时任务真正难的不是配表达式，而是理清“谁在什么时候以什么身份访问什么数据”。很多问题表面是触发器没跑，实际是云函数连不上数据库、或权限策略拦住了读写——得一层层往日志和权限配置里挖。
