最簡日誌打印規範（推薦，轉載）

我的認爲，若是在公司的野蠻生長階段，一些基礎類庫不作約束，極可能「埋坑」，造成技術債務，最終爲此付出代價。本文講解一個最簡的日誌打印規範。
事實上，日誌打印規範互聯網上已有不少，但大多比較冗長（記不住），也不太契合咱們團隊（關注點不契合）。

因此，我又造了個輪子，寫了個簡單易懂、容易記的「最簡日誌打印規範」，後續隨着團隊實力的增加，和項目的演進，會逐步增長新的條例。

1. 日誌打印組件

日誌組件有不少，日誌門面的選擇有：Slf4j、Apache Commons Logging等。

日誌的實現更多，有：log4j、logback、log4j二、Java Util Logging(jul)、Jboss Logging等。

目前，咱們使用Slf4j做爲日誌門面，logback做爲日誌實現。

2. 日誌打印級別

日誌的級別有不少，咱們通常只用四個。日誌級別由低到高DEBUG - INFO - WARN - ERROR。

• DEBUG（調試）：開發調試日誌。通常來講，在系統實際運行過程當中，不會輸出該級別的日誌。所以，開發人員能夠打印任何本身以爲有利於瞭解系統運行狀態的東東。不過不少場景下，過多的DEBUG日誌，並非好事，建議是按照業務邏輯的走向打印。打個比方，打印日誌就像讀書時劃重點，若是導出都是重點，也就失去了重點。
• INFO（通知）：INFO日誌級別主要用於記錄系統運行狀態等關聯信息。該日誌級別，經常使用於反饋系統當前狀態給最終用戶。因此，在這裏輸出的信息，應該對最終用戶具備實際意義，也就是最終用戶要可以看得明白是什麼意思才行。
• WARN（警告）：WARN日誌經常使用來表示系統模塊發生問題，但並不影響系統運行。 此時，進行一些修復性的工做，還能把系統恢復到正常的狀態。
• ERROR（錯誤）：此信息輸出後，主體系統核心模塊正常工做，須要修復才能正常工做。 就是說能夠進行一些修復性的工做，但沒法肯定系統會正常的工做下去，系統在之後的某個階段，極可能會由於當前的這個問題，致使一個沒法修復的錯誤（例如宕機），但也可能一直工做到中止也不出現嚴重問題。

3. 日誌打印場景

在咱們的系統中，不一樣的日誌級別的打印場景大體以下：

4. 日誌使用方式

• 使用的API

日誌級別	打印場景
DEBUG	調試日誌。目前管理相對寬鬆，咱們暫時沒有嚴格要求。
INFO	業務日誌。咱們用來記錄業務的主流程的走向。
WARN	警告日誌。通常來講，發生對整個系統沒什麼影響的異常時，能夠打印該級別的日誌。
ERROR	錯誤日誌。級別比較高，若是發生一些異常，而且任什麼時候候都須要打印時使用。

public static final Logger LOGGER = LoggerFactory.getLogger(MyRealm. class);

咱們使用的日誌門面是slf4j，使用時應面向接口編程，LOGGER/LoggerFactory應該都是slf4j的API。

嚴禁直接使用日誌實現包。緣由大體有兩點，第一是面向接口編程更優雅，這點沒必要說明；第二，舉個例子，由於log4j已經幾年不更新，老的項目可能使用了log4j，如今想要換用logback或者log4j2，如直接使用log4j的API，不利於選型更換與API的統一（固然，非要用也不要緊，有個log4j-over-slf4j的適配器。但接口不統一，總感受哪裏不對勁）。

• 禁止字符串拼接

例如：

LOGGER .debug( "當前用戶是:" + user + ",傳入參數是:" + userId);

嚴禁使用字符串拼接的方式打印日誌，可讀性、可維護性都比較差。

建議的寫法以下：

LOGGER.debug( "當前用戶是:{},傳入參數是:{},返回值是:{},用戶信息:{}", a,b new Object[]{token, userId, userInfo, authcInfo});

由於咱們使用的是Slf4j，Slf4j有佔位符填充的功能。多個佔位符可放在Object數組中。

• 無需使用級別判斷

不優雅示例：

if (LOGGER.isDebugEnabled()) { LOGGER .debug( "當前用戶是{}", token); }

之前，爲了性能，咱們經常在打印日誌以前判斷一下。

使用Slf4j後，咱們能夠寫成以下形式就OK了。

LOGGER .debug( "當前用戶是{}", token);

固然，若是依然使用字符串拼接的方式，仍是得判斷一下級別的。

做者： 周禮  原文地址：http://www.itmuch.com/work/simple-standard-log/