node-cron不保证毫秒级准时，其执行依赖setTimeout和事件循环，受主线程阻塞、GC、同步耗时等影响，实际触发时间常偏离预期，本质是应用层语义准确而非系统级精度。
node-cron 的执行是否真的“准时”？
不，node-cron 本身不保证毫秒级准时——它依赖 Node.js 的 setTimeout 和事件循环，一旦主线程被阻塞（比如同步文件读写、大量计算、未 await 的 Promise），下一次触发就会延迟。你看到的「每分钟执行」实际可能是「上一次任务结束 + 60 秒后执行」，而非严格按系统时钟对齐。
常见错误现象：*/5 * * * * * 本意是每 5 秒跑一次，但若某次回调耗时 8 秒，接下来会立刻再跑一次（跳过等待），造成堆积；或因 GC 暂停导致连续两次间隔达 12 秒。
- 用
process.hrtime()打点记录真实触发时间，别只信console.log(new Date()) - 避免在
onTick回调里写长耗时同步代码；异步操作务必await，否则调度器会误判任务已结束 - 若需强准时（如金融对账），应改用系统
crontab+ HTTP 触发接口，而非进程内调度
VSCode 调试时如何确认 node-cron 任务已启动？
直接看终端输出不可靠——任务可能已注册但没触发，或被 silent error 中断。必须查实例状态。
实操建议：
- 保存返回值：
const job = cron.schedule('0 * * * *', ...)，然后打印job.nextDates(1)（需 v3.0+）查看下次计划时间 - 检查
job.running属性：true 表示已激活；false 可能因scheduled: false或手动job.stop() - 在 launch.json 的
configurations里加"env": { "NODE_ENV": "development" }，避免生产配置意外禁用任务
为什么本地 VSCode 运行时区总是 UTC，不是 Asia/Shanghai？
node-cron 默认用 Node.js 进程所在系统时区，而 VSCode 终端常继承 shell 环境变量，Windows/macOS GUI 启动的 VSCode 往往丢失 TZ 或读不到系统时区设置。
Rydberg Agent Node
下载
使用一条命令部署ProbeChain Rydberg测试网代理节点。自动注册为Agent(NodeType=1)，免gas，支持macOS/Linux/Windows。触发词：/r
解决路径：
- 显式传参：
cron.schedule('30 9 * * *', fn, { timezone: 'Asia/Shanghai' })—— 注意字符串大小写敏感，'asia/shanghai'无效 - 启动前设环境变量：在 VSCode 终端先运行
export TZ=Asia/Shanghai（macOS/Linux）或$env:TZ="Asia/Shanghai"（PowerShell） - 验证方式：打印
new Intl.DateTimeFormat('en-US', { timeZone: 'Asia/Shanghai' }).format(new Date())，对比终端输出
任务执行失败后如何自动重试并记录轨迹？
node-cron 不内置重试或日志追踪，出错即静默吞掉（除非你 catch）。必须自己补全链路。
最小可行方案：
- 包裹整个回调：
try { await doWork() } catch (err) { console.error('[cron] failed at', new Date(), err) } - 加唯一 traceId：
const traceId = crypto.randomUUID()，所有日志带上它，方便在 VSCode 的 Output 面板中过滤 - 写入本地文件（非数据库）：
fs.appendFileSync('./cron-log.txt', `${traceId} ${new Date()} ${err?.message}\n`)，避免异步写入丢失
真正难的是跨重启持久化——VSCode 关闭再开，node-cron 实例就没了。想保留执行历史，得把日志存到磁盘文件或 SQLite，而不是靠内存变量。
