其實新增介面返回資料壓縮還不是增加的第一個功能。因為第一個介面是不需要查資料庫的，所以一開始只考慮了快取問題，沒有考慮資料庫連線問題。 做快取的時候，因為時間長任務少，就自己從頭開始做了一個 輕量的快取系統。這個快取系統具有快取資料和超時被動清除資料的功能，不用主動清除是因為被動清除可以不用設定定時器，能減少 cpu 消耗。現在想想是有些問題的，如果一直沒有清除快取，那麼不是要一直生存到應用關閉了？所以還是需要弄一個時間跨度大一點的定時任務來清掉過期快取的。 做了這個之後，很快遇到了需要連線 mongodb 的情況。依舊是使用 mongoose。 但是這裡就出現了狀況，框架核心檔案中沒有考慮連線資料庫的情況，另外也不能什麼資料庫都寫一個連線方法吧。還好 mongoose 是支援在連線之後開始查詢的，連線上資料庫之前的查詢是可以等待的，所以還按之前的把資料庫連線寫在單獨的 model 檔案中也還是可以的。 但是後來又遇到了新的需求，我們不能再把資料庫賬號密碼明文寫在配置檔案中了，需要從集團內部的其它系統中獲取。經過對 java 示例程式碼和文件的研究，我發現這其實就是向那個系統傳送一個 http 請求，然後那個系統返回給我們加密過的賬號和密碼。加解密這個在做香港C端專案的時候就已經搞過一遍了，不是問題。但是要先發請求拿資料庫賬號密碼，就不能像之前一樣連線資料庫了，因為需要確認資料庫賬號密碼拿到了，才能開始連線。於是就把入口檔案的程式碼用 (async function() {})() 包起來，改成了一個同步的自執行函式，又在最開頭加上獲取賬號密碼的方法，解決了這個問題。 如果只有這一個需要再 app 正常執行前執行的方法，後面也就沒啥問題了。然而問題從來沒有全部解決的時候，在這之後，又出現了需要啟動完成之後開始同步資料的需求，以及獲取開放平臺的 access_token 的需求。正巧這時候我看了一段時間的 egg 的生命週期的文件，於是就嘗試著把生命週期的概念引入到了我們的框架中。首先開始不搞特別複雜的，我就弄一個 beforeStart 和一個 afterStart 好了。於是重新梳理了核心框架程式碼，把 app 的啟動封裝起來，改造成 async 函式，這樣就能在裡面插入同步方法了。然後給 app 加上 beforeStart 和 afterStart 的 api， 在框架內部新增上序列執行任務的步驟，就簡單完成了新增生命週期控制的方案，之後對於 app 啟動前後要做的動作就能在程式碼中更清晰的體現了。 在這之後還有一個大的功能點就是在通過平安開放平臺連線員工賬號密碼登入服務的時候，很多介面就需要做未登入使用者攔截了，於是就在路由功能上從之前的只能每個介面對應一個 controller 改成了可以對應一組 controller 了。現在想想登入校驗功能也未必需要放在 controller 裡面，放在 service 裡面也可以，但是這樣的話好像不僅不符合用 controller 來控制流程的思想，而且還是每個 controller 都需要再呼叫一次 service，相當於登入校驗和正常功能耦合在一起，沒有做分離，如果後面要改成不需要登入或者要改變登入邏輯，那就需要修改每一個 controller ，那樣就很尷尬了。反之，如果在一個 controller 裡面單獨做登入校驗，那麼修改登入邏輯就很方便了。