java中的日誌框架梳理（故事的形式呈現）

日誌算是java工具體系的一個知識點，但又是寫程式碼的時候繞不過去的一個知識點，這篇文章主要是針對於小白，以故事的形式來對目前市場上常見的一些日誌框架進行一個介紹和梳理。

階段一：

從前有一個程式設計師，名字叫張三，張三呢，每天矜矜業業，業務能力程式碼能力都很強。老闆就讓他負責一個比較複雜的系統。於是張三呢，每天使用System。out。println（），在控制檯打印出來一些關鍵的資訊。這時候麻煩來了，專案需要上線了，總不能還要把這些沒用的資訊輸出到控制檯吧，於是老闆讓張三把這些語句全部去掉。這麼龐大的系統，張三找呀找，終於把所有的System。out語句全部註釋掉了。

階段二：

過了一段時間呢，專案遇到了一些問題，老闆突然想起來張三之前寫過System。out的相關語句，覺得有必要把一些關鍵資訊打印出來，於是又讓張三把所有的System。out語句新增進來，這下子又把張三忙活得不輕，累了一天終於又改過來了。在找出錯誤之後，然後再重新去掉。

階段三：

就這樣來回折騰了幾次，把張三氣得不輕，畢竟需求總是會不斷的變化的，於是張三考慮做一個框架，記錄系統執行的一些必要的資訊，這個框架就叫做日誌框架，在這裡且命名為logging-jar。

階段四：

在第一代日誌框架中，總是會把各種各樣的執行資訊打印出來，這對於張三來說只想要找出一些錯誤資訊，他必須要在很長的一個控制檯去尋找。於是張三考慮著如何改進這個框架，比如說把輸出資訊分類，有異常資訊，有錯誤資訊，還有警告資訊等等。這對於張三來說，開發起來太便利了。叫做logging-good-jar。

階段五：

老闆一看，張三業務能力這麼強，乾脆把其他的一些專案也讓張三帶吧，於是張三又負責了一些其他的專案，但是問題又來了，其他的專案使用的不是張三的日誌框架，而是其他的日誌框架，怎麼辦呢？張三考慮著把這個專案的去掉，換成自己的不就可以了嘛，於是張三去掉了別人的，換成了自己的，又廢了半天功夫更改了大量的日誌api程式碼。

階段六：

隨著張三業務能力的不斷增強，負責的專案也越來越多，接觸到的日誌框架也是參差不齊。於是張三考慮定義一些規則介面，其他的任何框架都要有相應的實現方法，這樣做的好處就是每次張三就不需要去掉別人的，換成自己的。而是呼叫相應日誌框架的相關實現即可。這個規則就叫做日誌門面，也叫做日誌框架的抽象層。實現這些規則介面的框架就叫做日誌實現框架。

目前最受歡迎的就是這麼幾個。按照使用的角度來說，那就是左邊選擇一個日誌門面，右邊選擇一個日誌實現就好了。就這樣他們之前進行了激烈的競爭。

Ceki Gülcü是一個java大佬，一開始發明了log4j，後來把這個捐給了Apache基金會，後來覺得這個功能不夠牛，又發明了logback。logback一出來很離開，但是日誌門面不能滿足需求了，於是乎又設計了slf4j。

階段七：

隨著時間的流逝，slf4j門面和logback日誌實現框架脫穎而出。於是平時張三就用這個了。但是我們需要知道的是在使用的時候其實用的是日誌門面slf4j的方法，而不用關心是哪一個實現的。springboot開發團隊，一看這個搭配使用起來是真的好，於是就選用了他倆了。既然這麼好，乾脆我們使用springboot來整合一下他們倆。

第一步：新增依賴

第二步：配置日誌

在 src\main\resources 路徑下建立logback。xml配置檔案。

上面的這些都是模板程式碼，你可以直接拿來用。下面我們就直接使用。

第三步：使用

執行結果就不展示了。