日志滿天飛總是不好的，代碼是程序員的藝術品，日志也是其中一部分。
寫在前面的話
程序員在程序中打印日志的目的一般有兩個：定位問題和顯示程序運行狀態。試想有那么一個夜晚，突然手機響了，美夢中驚醒，報警短信，然后不到兩分鐘leader電話來了，你用快速又嫻熟的動作爬起來，打開電腦當你打開日志文件準備查問題的時候，傻了，這日志誰寫的，問題被雜亂的日志埋葬了，一時急火攻心，終于通過對照源代碼和日志，在數小時之后解決了問題。可見日志的重要性。
其實好的日志打印方式還有一個作用，能實現一些業務運營方面的統計工作，比如你在每個操作的關鍵位置都有對當前用戶的操作記下一條日志，這樣就能統計出，該業務功能走到每一步的用戶數，從而能分辨出是在哪一步損失了用戶，從而做相應的業務流程的優化。
可能大家認為日志不管咋打印都不會影響功能邏輯，拋開影響系統性能不說，這有點高級了，其實從上面的話中也可以看出，日志其實很重要的，所以下面我將從幾個方面討論一下如何打印日志，以便理清我自己的思路，同時提醒程序員同行們，這樣后面維護你的代碼的程序員，少一點吃屎，更少一點對你的咒罵，為和諧美好的程序員天堂添磚加瓦（好偉大呀，哈哈）。
目錄：
1. 方便定位問題的日志如何打
2. 顯示程序運行狀態的日志如何打
3. 可以用作運營統計的日志如何打
4. 什么樣的日志不應該打
1. 方便定位問題的日志
這是日志的最主要的用途。
- 日志明確標志屬于哪次請求
打印的每一條日志中盡量包含請求流水號，以便區分這條日志是屬于哪次請求的日志，日志樣例：
log.warn("賬戶創建和升級功能，無法識別操作類型（0：創建，1：升級），請求流水號：{}，當前值：{}" , flowNo, operType);
如果獲取不到流水號，則需要打印明確能縮小日志歸屬范圍的字段信息，如用戶號、協議號、手機號等。
- 在對外提供的接口入口處打印一條日志
打印接口的唯一標識和中文（如果你English enough可以打英文）簡短描述，并且要將調用方傳入的參數原樣打印出來。這樣當系統出現問題時，你就能很容易的判斷出是否是調用方出現了問題。日志樣例：
log.info("addUpAccount&賬戶創建和升級接口，外部系統入參：{}" , JSONObject.toJSONString(request));
- 在調用其它系統接口的前后各打印一條日志
打印所調用接口的系統名稱/接口名稱和傳入參數/響應參數，這樣能方便做問題定界，通過這兩條日志可以清楚地看出是否是所調用的系統出現了問題，傳染到我了。日志樣例：
log.info("調用cif業務訂購，bcc入參：{}" , JSONObject.toJSONString(request));
log.info("調用cif業務訂購，cif響應：{}" , JSONObject.toJSONString(cifResponse));
- 不符合業務邏輯預期打印一條日志
打印關鍵的參數，要能從這些參數中清楚地看出，誰的操作與預期不符，為什么與預期不符。并且唯一定位到這條日志，要包含用戶id或者流水號。日志樣例：
// 校驗重復簽約
int count = agreementService.countSignAndPre(externalUserId, userInfo.getUserId(), agreementType);
if (count == 1) {
// 已經簽約過，不允許重復簽約
log.warn("簽約失敗，不允許重復簽約！用戶信息：{}，協議類型：{}，來源系統：{}，外部系統用戶號：{}",
JSONObject.toJSONString(userInfo), agreementType, systemCode, externalUserId);
}
- 業務處理出現異常打印一條日志
主要打印異常信息和業務邏輯描述。日志樣例：
try {
//業務邏輯處理
} catch (BizException e) {
log.warn("賬戶升級過程中出現業務異常", e);
}catch (Exception e) {
log.error("賬戶升級過程中出現無法識別的異常", e);
}
- 極少出現的else情況打印一條日志
打印業務功能描述和該極少出現的參數值，還有唯一定位一次請求的請求流水號。日志樣例：
if("0".equals(operType)){
//創建賬戶
}else if("1".equals(operType)){
//升級賬戶
}else{
log.warn("賬戶創建和升級功能，無法識別操作類型（0：創建，1：升級），請求流水號：{}，當前值：{}" , flowNo, operType);
}
2. 顯示程序運行狀態的日志
系統程序日復一日/月復一月/年復一年的運行著，查看系統的運行狀態是必不可少的，比如一些可能和耗時的業務處理，批處理，IO操作等。
- 耗時（可能出現超時）業務邏輯處理時間打印一條日志
打印業務邏輯描述和處理時間。日志樣例：
long startTime = System.currentTime();
//業務邏輯處理
log.info("綁定銀行卡總耗時 : " + (System.currentTime() - startTime) + "ms");
- 批量處理大量數據時顯示處理進度打印n條日志
在夜間做對賬處理時，一般都是批量處理大量數據，這是應打印的日志包括：對賬功能描述和處理進度，每處理1000（視情況而定）條打印一條。日志樣例：
log.info("業務開通狀態對賬功能處理中，總數據量：{}，當前處理到：{}", total, current);
3. 可用作運營統計的日志
從業務上來說，一個大的功能往往是由多個小功能組成，這些大的功能組成一個完整的系統。比如一個系統包括注冊用戶/開通某項業務/綁定銀行卡/消費下單，從而達到一個電商類系統的最終目的。針對這個系統運營人員經常會要一些數據如多少注冊用戶，多少開通業務用戶，多少綁卡用戶，多少下過單的用戶，如果是這樣的粗粒度的統計需求，可能寫幾條sql摟一下數據庫就搞定了。但是如果需要更加細致統計，如綁卡功能分為這樣幾步：用戶實名校驗，銀行卡校驗，發送短信驗證碼，校驗短信驗證碼，簽協議綁卡。日志樣例：
...
log.info("用戶綁卡，實名校驗，用戶信息：{}", JSONObject.toJSONString(userInfo));
...
log.info("用戶綁卡，銀行卡校驗，用戶信息：{}", JSONObject.toJSONString(userInfo));
...
log.info("用戶綁卡，發送短信驗證碼，用戶信息：{}", JSONObject.toJSONString(userInfo));
...
log.info("用戶綁卡，校驗短信驗證碼，用戶信息：{}", JSONObject.toJSONString(userInfo));
...
log.info("用戶綁卡，簽協議綁卡，用戶信息：{}", JSONObject.toJSONString(userInfo));
...
通過后臺日志可以做到細粒度的運營統計分析，當然還有其他更專業的技術實現這種運營分析的功能，這種方法可以作為一個過渡期的方法。只要有一個好的打印日志的習慣，通過大數據的分析，日志還有其它的價值。
4. 不應該打印的日志
- 無意義的日志
日志樣例：
log.info("調用客戶系統開始...");
...
log.info("調用客戶系統結束...");
...
log.info("用戶簽約失敗...");
當我們看到這樣的日志的時候，沒有包含任何有意義的信息。調用開始，我想知道誰調用的，入參是啥；調用結束，我想知道調用結果，出參是啥，調用成功還是失敗；同樣，用戶簽約失敗，我想知道的是哪個用戶失敗，為什么失敗；顯然都沒展示，所以這樣的日志是沒有任何意義的。
- 混淆信息的日志
所打印出來的日志都應該是清楚準確的表達，當你不能確定具體原因的時候，不能在日志中只是展示一種可能的情況，這樣會影響對問題的判斷，這樣的日志千萬不能打。日志樣例：
Connection connection = ConnectionFactory.getConnection();
if (connection == null) {
log.warn("System initialized unsuccessfully");
}
結束lala
