unicloud定时触发器由云端配置驱动，需在云函数自身package.json中正确配置trigger对象（非根目录或数组），cron用6位格式，部署后须在控制台确认生效，注意超时设置、冷启动延迟及日志排查环境与异常。
uniCloud 的定时触发器不是“在前端写代码启动”的东西，它完全由云端配置驱动。只要云函数部署时带了正确的 trigger 配置，且部署成功，就会自动按 cron 执行——不依赖 uni-app 前端、不靠 setInterval、也不需要手动调用。
云函数 package.json 中必须写对 trigger 字段
这是最常出错的地方：很多人把 trigger 写在根目录的 package.json 里，或者写错位置、格式、字段名。
-
trigger必须放在云函数自己的package.json文件中（即uniCloud/cloudfunctions/your-function-name/package.json），不是项目根目录 - 字段名是
trigger（不是triggers，也不是cloudfunction-config.triggers），且是对象，不是数组 - 正确结构示例：
{"name":"my-task","version":"1.0.0","main":"index.js","trigger":{"type":"timer","name":"daily-clean","config":"0 0 2 * * *"}} -
config是标准 cron 表达式：6 位（秒 分 时 日 月 周），阿里云/支付宝云/微信云都用这个；腾讯云是 7 位（多一个年份位），但 uni-app 封装层已做兼容，统一填 6 位即可 - 注意：整点（尤其是
0 0 0 * * *）在 UTC+8 时区可能因平台调度高峰出现延迟或漏触发，建议错开，比如用0 0 2 * * *（凌晨 2 点）
部署后必须在控制台确认触发器已生效
上传后不等于就跑起来了。uni-app 的 HBuilderX 或 CLI 上传可能跳过 trigger 校验，导致配置没真正生效。
- 打开
uniCloud控制台 → 进入对应服务空间 →「云函数」→ 找到你的函数 → 点「详情」→ 查看「触发器」标签页 - 如果这里为空，说明
package.json的trigger没被识别（常见原因：JSON 格式错误、字段名拼错、用了triggers数组而非trigger对象） - 不要依赖本地日志判断是否触发——定时任务执行时不会返回给前端，只能看云函数「日志」页里有没有对应时间戳的记录
- 首次部署后，建议手动点一次「测试运行」，再等下一个 cron 时间点，对比两次日志时间差，确认是否真按配置走
超时和冷启动会影响实际执行效果
定时函数不是“准时准点毫秒级执行”，它受平台资源调度影响，尤其对支付、订单类强时效逻辑要格外小心。
- 阿里云默认超时 60 秒，但定时任务建议显式设为
"timeout": 600（600 秒），写在package.json的同级字段里（不是 trigger 下） - 冷启动延迟真实存在：函数若长时间未触发，首次执行可能比 cron 时间晚 1–3 秒；连续触发则基本稳定
- 如果你的任务必须“严格在某分钟后执行”（比如支付超时关单），别依赖定时触发器——改用数据库标记 + 每分钟扫表的轮询方案，例如：
scheduledAt: new Date(Date.now() + 5 * 60 * 1000)，再配一个每分钟跑的check-scheduled函数 - 避免在定时函数里写阻塞式操作（如同步 fs 读文件、未 await 的 Promise），否则可能超时中断
真正麻烦的不是配置语法，而是误以为“配完就万事大吉”。cron 表达式写对了，trigger 字段放对位置了，部署也成功了，但日志没出来——大概率是服务空间选错、环境（alpha/test/production）切错了，或者函数本身抛异常没 catch 导致静默失败。查日志前，先确认你在看的是那个服务空间、那个环境、那个函数的日志。
