有些技能只有踩過坑的人才能夠掌握,能用來避免后來的坑,很多時候是用凌晨的時間換來的，我們通常把他叫做經驗。
故事
這個一個關於springmvc的坑的故事。
某天晚上本打算一個小功能分分鍾搞定上線,但頁面總是報404錯誤,肉眼實在找不到原因。 各種手段折騰,斷點,重啟,重新打包,拍腦袋覺得代碼沒寫錯,url路徑也ok,真心沒問題，無數次f5就是不出來。
很多時候遇到一個bug越着急越搞不定，我就是這種情況，花了一兩個小時時間，眼看都過0點了，此時我正用最后的手段，引入spring源碼直接一步步debug，看起來也沒問題，那能不能更深入點，從spring啟動開始。
這時我突然想到了日志，平時線上的日志級別都是error，本地一般也很少改，大多數情況都是斷點debug，日志更多的是用來日后線上問題排查。所以我改了下spring的日志級別，看看他啟動干了啥。
因此，修改了下log4j的配置文件，將springmvc的日志級別改為debug，如果是logback的話，配置文件也是類似。
<logger name="org.springframework.web">
<level value="DEBUG"/>
</logger>
這樣的話啟動后，springmvc就會打印出它所加載的路徑映射，每次請求也會詳細打印出請求的參數，路徑等等。
然后，重啟，看到控制台打印出來的路徑和我實際訪問的路徑，問題一目了然了，原來我與顯示頁面只差一個字母大小寫的距離。看一下時間，已然是凌晨1點，默默的在心里說一句：WTF。然后倒頭就睡。
合理的日志級別
日志是我們經常用到的東西,但很多時候只有在遇到線上bug之類的情況才會想起有日志可以協助排查,但開發的時候一點點日志級別修改,就能避免某個bug調試到凌晨1點才發現與答案只差一個字母的距離。
我個人的經驗，在web項目時會把三個方面的日志級別改為debug
- webmvc框架：springmvc 或者struts2，主要查看請求路徑和參數，頁面400，404了，看看請求路徑和參數對不對；
- orm框架：如mybatis，debug級別會打印sql和參數，有sql異常通過日志就可以很快定位；
- 項目本身的業務日志，這個一般很少。
至於其他外部依賴的項目根據需要自行定義，root日志級別一般是error，不然很多其他日志混進來會導致很難查看。
對於struts2，日志級別是這么定義的。
<logger name="com.opensymphony.xwork2">
<level value="DEBUG"/>
</logger>
當然這是xml格式的配置文件，如果是properties，需要這么做
log4j.logger.com.opensymphony.xwork2=debug
mybatis的sql則可參考如下
log4j.logger.com.ibatis=debug
log4j.logger.java.sql.Connection=debug
log4j.logger.java.sql.PreparedStatement=debug
本文於2016-07-07 18:32:58從Chu Lung's blog自動同步同步,訪問原文