1、 【致命】不是所有Panic都能捕獲
我們知道Golang給開發人員提供recover()機制，對堆棧異常（panic）進行捕獲並自定義其處理邏輯。下面舉個例子：
構造一個除0的異常場景：
輸出結果：
我們看到程序正常退出，沒有異常，說明recover()按照預期捕獲到panic異常；但不是所有panic都能通過recover()捕捉到的，比如：並發操作map實例。
構造並發操作map的場景：
輸出結果：
以上結果可知，我們不能單純依靠recover()解決函數內部所有panic異常，應該做到以下幾點：
a) 通過編寫代碼校驗，防止能預期到的panic，比如：空指針引用的指針判斷。
b) 對於無法預期的panic，使用recover()捕獲並加以處理。
c) 使用map時，必須要考慮是否存在並發讀寫場景，存在時，應使用ConcurrentMap組件或自己加sync.RWMutex進行加鎖保護。
相關參考：
關於並發讀寫map導致的panic無法使用recover()捕獲，是Go1.6增加的一個特性，https://golang.org/doc/go1.6#runtime；
當然這個並非是唯一一個無法通過recover()捕獲的場景，還有可能Go本身的bug，https://github.com/golang/go/issues/21717；這個Bug在Go1.9.2才修復
2、 【嚴重】小心Map的內存泄露
大部分Golang程序做業務緩存實現時，都使用了map，看以下代碼片段，簡單模擬了這種使用場景：
增加環境變量GODEBUG=gctrace=1，運行可見，即使代碼邏輯清空了map，但進程內存使用並沒有像預期那樣“實報實銷”：
應如何解決：定期替換成新的map，釋放舊的map對象。
3、 【提示】不是每次Map遍歷都能得到相同排序的集合
經常遇到一些業務場景，需要將map的所有元素打印輸出，在Golang里面實現是非常簡單的，一個for range就可以實現，但結果卻有點出人意料：
輸出結果：
兩次遍歷的結果均不相同，這是為什么呢？這是Golang故意增加的一個隨機數導致的，https://blog.golang.org/go-maps-in-action；所以如果對結果一致性有要求的業務邏輯，就不能簡單的遍歷map了，可以這樣實現：
4、 【嚴重】客戶端執行Response.Body.Close()后HTTP連接真的關閉了嗎？
按照官方文檔對標准庫中的http client包的說明，在使用時需要主動調用Response.Body.Close()將連接關閉，但並不說明只要寫了這句話就能關閉連接的。看看以下場景：
執行后，統計了下連接數，發現大量TIME_WAIT連接沒有按預期回收，看來Response.Body.Close()沒生效。
我們把代碼調整如下：
再看看連接數統計：
為什么？以上是個較為特殊的場景，業務只關心請求的響應碼，並不關心響應體，所以沒有加入讀取resp.Body的代碼。可以看到此時關閉Body讀取數據通道，會導致Golang底層沒有真正關閉連接。要解決這個這種場景出現的連接泄露問題，需要在Close前額外加入io.Copy(ioutil.Discard, resp.Body)，來完成TCP響應體讀取流程。
Go語言未來的前景很不錯，而在國內的大廠中，華為雲對此的支持還是可以的，在其微服務應用平台、微服務引擎中開放了Go語言的服務框架。
目前，華為雲有一個關於微服務的活動，有想應用服務微服務化需求的朋友可以考慮試用一下！
https://activity.huaweicloud.com/cse/index.html?dfk