最近做一个活动，需要用到定时任务，于是使用了 node-schedule 库。
用法很简单，就是可配置开始、结束时间，以及重复执行的时间点，如下所示，从2020-12-23T09:00:00Z开始，每10分钟执行一次，直至2020-12-23T09:30:30Z结束。
schedule.scheduleJob({ start: '2020-12-23T09:00:00Z', end: '2020-12-23T09:30:30Z', rule: '* */10 * * * *' }, test);
一、时间修改困难
如果是需要在未来某个时间段执行的定时任务，那么要还原真实场景，就得修改服务器时间。
测试环境虽然可以改时间，但是我们这边是几个组共用几台服务器，修改了时间后，可能会影响其他组的业务，并且正式环境的时间是不能修改的。
一开始测试的时候，改过几次时间，改时间毕竟太繁琐，每次代码发布，服务器的时间就又会重置，又要修正一次，还收到了其他组的投诉。
后面就改成今天的时间段，这次的定时任务的时间段有7个，每次修改好后，就要提交一遍代码，然后合并分支，最后发布一下代码，服务也会重新启动。
这种纯手工方式过于费时，后面想到可以在后台做个通用配置（下图是个配置列表），将这些常量（例如时间参数）存在数据库（例如MongoDB或MySQL）中，可随时读写。
通用配置还有一个比较常见的场景，那就是测试的时候，在线修改可配置的参数。例如有个活动，里面有个任务是观看直播30分钟，而测试的时候不可能等到30分钟后，查看效果。在测试的时候可以调整成2分钟，如果这些参数写死在代码中，那么就需要重发代码，而保存在通用配置中的话，就不用重发代码了。
下图是个增和改的弹框，在新增的时候需要格式化多行文本中的JSON数据，先用 eval()，再用JSON.stringify()，这样的话在调用JSON.parse()的时候就不会出错。
JSON.stringify(eval(`(${values.content})`))
为了让JSON数据的展示更友好，就需要格式化数据，也就是要有空格。
JSON.stringify(JSON.parse(record.content), null, 2)
二、错误查看困难
在测试环境或正式环境，如果定时任务处理的数据错误了，那么只能通过日志来排查。
而一台跑着的服务器中会有很多其他的定时任务，在测试环境中，为了能看清楚日志，可以只运行一个任务。
但是在正式环境中，是不能停止任务的，像目前运行的定时任务，可能几秒内就有几百行的日志，用肉眼观察有点累。
好在我们这边接入了阿里云的日志服务，可以查看日志控制台，里面有丰富的查询过滤条件，可以准确的定位到某条日志。
如果你有更好的调试方法，欢迎留言讨论。
三、应急处理
在线上运行的时候，可能会因为这个那个的问题导致任务没有在指定时间运行。
那么就得开放一个入口，来手动执行这个任务。
一开始的想法是写个临时接口，然后用postman手动访问，不过这样的话对运营不太友好，毕竟运营会有人半夜值班盯着活动，但开发人员是不会半夜还盯着服务器的。
于是又快速搭了个后台执行页面，有个下拉框可选择任务时间段，还有个运行按钮，到时候出问题的话，就手动运行一次。
