定时量化任务最怕的不是报错，而是成功执行两次

把选股或调仓脚本搬到云函数后，很多人先关心 Cron 是否准时、运行时间够不够，却容易漏掉一个更实际的问题：同一批任务可能被执行不止一次。腾讯云云函数的定时触发属于异步调用，运行错误和部分系统异常会触发重试。对数据清洗来说，重复执行也许只是多写一份文件；对下单任务来说，后果可能是仓位直接翻倍。

因此，定时器只能负责“唤醒”，不能被当成“只执行一次”的保证。比较稳妥的做法，是为每次任务生成业务幂等键，例如 strategy_id + trade_date + rebalance_batch。函数启动后先向数据库写入一条任务记录，并给幂等键建立唯一约束。只有成功写入的实例可以继续计算和下单；遇到重复键的实例直接结束

任务状态也不建议只设成成功和失败。我一般会拆成 CREATED、CALCULATED、ORDER_SENT、DONE。这样函数在中途超时后，下一次执行可以知道上次走到了哪一步，而不是从头再来。计算结果可以安全覆盖，但进入 ORDER_SENT 后，要先查询委托状态，再决定补单还是等待。

还有一个边界必须单独处理：券商接口已经接受委托，但程序还没来得及把结果写回数据库就异常退出。仅靠本地任务锁挡不住这种重复下单。如果接口支持自定义委托编号，可以把幂等键作为 client_order_id；如果不支持，至少要用证券代码、方向、数量、时间窗口核对当日委托，再决定是否重发。

最后再处理时区。云函数事件中的时间字段可能采用 UTC，策略的交易日判断则通常按北京时间和交易所日历计算。不要直接截取事件日期，应该显式转换时区后再生成幂等键。一个可靠的量化定时任务，重点不是“每天能跑”，而是重复触发、超时和重启后，仍然只产生一次业务结果