1.寫完接口後用postman測試接口功能時發現所有Post請求都變成了非法登錄，以前不登錄都能直接請求的，想到是不是代碼和git上有區別，仔細比對後發現沒有影響，最後發現要先調用login接口進行一次登錄，可能之前是同事已經幫我登錄了，所以上次不用登錄。
2.郵箱無法發送郵件，經檢查每次登錄要輸入驗證碼，一開始以爲是驗證碼導致的，後來想到發郵件相當於客戶端，直接調用stmp服務的，登錄郵箱後發現新申請的測試郵箱還沒開通smtp服務，於是先設置了授權碼，然後再代碼中用這個授權碼代替密碼使用服務，成功發送郵件。
3.當郵件發送不成功時，報錯信息最好在recoverWith中捕獲，經過查詢，發現recover和recoverWith的關係相當於map和flatMap，recover能夠創建一個新future對象，該對象當計算完成時持有和原future對象一樣的值。如果執行不成功則偏函數的參數會被傳遞給使原Future失敗的那個Throwable異常。如果它把Throwable映射到了某個值，那麼新的Future就會成功完成並返回該值。如果偏函數沒有定義在Throwable中，那麼最終產生結果的future也會失敗並返回同樣的Throwable。組合器recoverWith能夠創建一個新future對象，當原future對象成功完成計算時，新future對象包含有和原future對象相同的計算結果。若原future失敗或異常，偏函數將會返回造成原future失敗的相同的Throwable異常。如果此時Throwable又被映射給了別的future，那麼新Future就會完成並返回這個future的結果。
4.recoverWith中有如下一段代碼：
case e: MessagingException => {
db.run {
DataCloudUsers
.filter(t => t.username === username && t.deleted === 0)
.map(_.password).update(x.password)
}.flatMap(_ => Future.failed(UnsuccessfulSendMail(x.username, x.email)))
之前flatMap寫成map的時候，調用post接口一直返回值轉換異常，後來發現可能就是map和flatMap的細微差別導致的，flatMap在按照映射規則轉換完之後還會把結果從抽出來組成一個扁平化的數組，所以flatMap返回來的是Future類型的。
5.把如果不是MessagingException的情況用下劃線代替作爲recoverWith中的一個case的話，貌似不會執行，具體原因待研究。