No TLD files were found in resource path [/WEB-INF/].
(注意：這個問題不影響項目啓動）
簡介：
tld是taglib description 的縮寫(jsp中的自定義標籤的解析文件，指出標籤與標籤實現類的關係)
詳細的請看這個文章：https://blog.csdn.net/liaoxiaohua1981/article/details/6856307
定位問題的方法：（沒時間就不用看了）
案例：
昨天幫別人調試一個問題, 他說項目訪問不了, 我clone下來項目, 嘗試啓動, idea的控制檯沒有自定義的日誌信息。沒有啥有用的輸出，沒有報錯，只有標題的那個告警。但網上又沒找到跟什麼標題相關的文章，當時感覺不是那個問題，但項目接口就是訪問不了。接口調用返回302狀態碼。
思來想去，idea看起來是部署成功了，302不可能無緣無故地返回回來。
第一想法就是去驗證項目最外層的index.jsp。如果能訪問成功說明項目啓動是沒有問題的。
很尷尬的是我的也返回302.
於是我想到了外部請求進入項目的流程：tomcat接收到context匹配的請求，然後會按順序依次執行web.xml的filter、interceptor，於是，我選了最上面的一個filter，看了下里面的邏輯，裏面除了項目健康檢查不需要鑑權外，其他所有url都需要鑑權，包括了index.jsp。如果鑑權不通過，返回了http狀態碼302。沒有日誌打印，尷尬。
解決問題
這其中反映了很多問題：
- 研發的代碼在必要的地方還是需要打印一下日誌（log，不是system.out.print）。比如上面在返回302的時候，可以打印請求的url、入參，簡要打印異常情況（比如鑑權失敗），日誌可以讓別人快速調試定位你的bug（生產環境的關鍵部分的日誌尤爲重要，但也不能瘋狂打印日誌，不然日誌文件會佔滿你的硬盤導致服務掛掉）
- http狀態碼不能亂用，3xx的http狀態碼代表重定向的意思，很明顯上面的業務屬於鑑權失敗，應該是401狀態碼纔對。（《http權威指南》可以腦補一下）
- 自己定位問題的思路有待優化，請求沒有到達controller層。說明請求從發起端–>controller中間出現了問題。應該先分析整個請求的鏈路，請求發起–> 網絡–>tomcat -->filter --> interceptor --> spring容器–>業務controller層，根據二分法，可以在filter看下是左半部分還是右半部分的問題。上面的場景裏面，filter裏面就直接找到了問題所在。如果還沒有找到問題，就再繼續二分法。
理論方法
-
二分法 + 本地調試
是我認爲效率比較高的定位問題的方法了。二分法能大體確定問題出現在哪個部位。至於方法內，就只能調試或者看日誌了。（感覺能解決90%的問題） -
如果作者不是自己而且未離職，自己瞎折騰了大概10~20分鐘依舊沒解決後，果斷找他。
-
如果作者已經離職，而且自己沒有什麼思路的時候，找個老練的組員當小黃鴨。看下能不能提供些思路。