最近做一個活動，需要用到定時任務，于是使用了?[node-schedule](https://github.com/node-schedule/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）中，可隨時讀寫。 :-:  圖 11   通用配置還有一個比較常見的場景，那就是測試的時候，在線修改可配置的參數。例如有個活動，里面有個任務是觀看直播30分鐘，而測試的時候不可能等到30分鐘后，查看效果。在測試的時候可以調整成2分鐘，如果這些參數寫死在代碼中，那么就需要重發代碼，而保存在通用配置中的話，就不用重發代碼了。   下圖是個增和改的彈框，在新增的時候需要格式化多行文本中的JSON數據，先用 eval()，再用JSON.stringify()，這樣的話在調用JSON.parse()的時候就不會出錯。 ~~~ JSON.stringify(eval(`(${values.content})`)) ~~~ :-:  圖 12   為了讓JSON數據的展示更友好，就需要格式化數據，也就是要有空格。 ~~~ JSON.stringify(JSON.parse(record.content), null, 2) ~~~ ## 二、錯誤查看困難   在測試環境或正式環境，如果定時任務處理的數據錯誤了，那么只能通過日志來排查。   而一臺跑著的服務器中會有很多其他的定時任務，在測試環境中，為了能看清楚日志，可以只運行一個任務。   但是在正式環境中，是不能停止任務的，像目前運行的定時任務，可能幾秒內就有幾百行的日志，用肉眼觀察有點累。   好在我們這邊接入了阿里云的日志服務，可以查看日志控制臺，里面有豐富的查詢過濾條件，可以準確的定位到某條日志。 :-:  圖 13 ## 三、應急處理   在線上運行的時候，可能會因為這個那個的問題導致任務沒有在指定時間運行。   那么就得開放一個入口，來手動執行這個任務。   一開始的想法是寫個臨時接口，然后用postman手動訪問，不過這樣的話對運營不太友好，畢竟運營會有人半夜值班盯著活動，但開發人員是不會半夜還盯著服務器的。   于是又快速搭了個后臺執行頁面，有個下拉框可選擇任務時間段，還有個運行按鈕，到時候出問題的話，就手動運行一次。 :-:  圖 14 ***** > 原文出處： [博客園-Node.js躬行記](https://www.cnblogs.com/strick/category/1688575.html) [知乎專欄-Node.js躬行記](https://zhuanlan.zhihu.com/pwnode) 已建立一個微信前端交流群，如要進群，請先加微信號freedom20180706或掃描下面的二維碼，請求中需注明“看云加群”，在通過請求后就會把你拉進來。還搜集整理了一套[面試資料](https://github.com/pwstrick/daily)，歡迎閱讀。  推薦一款前端監控腳本：[shin-monitor](https://github.com/pwstrick/shin-monitor)，不僅能監控前端的錯誤、通信、打印等行為，還能計算各類性能參數，包括 FMP、LCP、FP 等。