0、try_catch
try 後別接of，即使你很有把握，但第二個開發者會在of和catch間增加認爲已經被異常捕獲的代碼。
1. error_logger
默認crashlog 用，一旦進程批量crash，因爲內部receive-match 寫磁盤方式，越來越慢。
建議實現自己的lager_backend，通過cast 到獨立 gen_server2 寫磁盤，或者cast 到網絡寫到日誌服務器上去
2. gen_server receive-match 問題
避免在熱點gen_server 中使用receive-match 方式，或者都使用如rabbitmq 中的gen_server2，一定要防止在
message_queue_len可能，比較大的進程中做recieve-match，error_logger就存在這個問題。
3. 熱點進程
erlang 是公平調度，熱點進程在負載稍高時，就會沒機會得到處理，注意設置priority high
4. 單進程處理瓶頸
erlang 進程無法共享數據，往往使用單個gen_server 完成共享邏輯，
但erlang CPU計算是很低效的，往往但進程無法完成業務處理，這個時候需要拆分到多個進程處理 。
5. ETS
對於3，4另一個解決方案是使用ETS，ETS 可以作爲全局表，所有進程都可以讀寫，不存在熱點進程，
而且減少了進程消息交互成本效率要高很多。
6. rpc:call
成本較大：一次調用有3次網絡往返
服務端單進程：服務端有rex 進程處理，容易產生瓶頸，測試最多處理 10w/s 消息
如有必要儘量多使用 Pid ! Msg - receive 方式
7. gen_server:call timeout
timeout 是給call 方返還的，而實際處理一定會被處理，而且reply 也會在timeout 後發回message_queue，要注意。。
8. Pid ! Msg
Pid 不存在時消息會丟失，gen_cast 也一樣；就算is_process_alive 判斷也會存在競態，所有是無法判斷是否send sucess ，只能reply 確認
9. 依賴supervisor
Erlang 設計模式，一般不怎麼處理異常，非常態錯誤依賴supervisor 重啓。 但如果gen_server 存在數據，重啓瞬間 就會丟失數據。
10.now_time
功能狀態，標誌儘量用時間描述，從安全層面考慮如果狀態存在沒有更新的情況，時間戳可以作爲狀態失效校驗的條件。