今天下午在請求介面的時候，出現了乙個問題就是 傳參問題
介面是請求成功的200，但是修改後返回來的卻是500，這就很納悶怎麼會這樣了。
經過查詢，原來是因為傳參問題。將有乙個name:0 傳遞成了name:1;
又是怎麼確認是傳參的問題了。 不要去寫動態傳遞引數了。寫乙個死的引數
來測試這個死的引數有沒有問題，如果死引數沒有問題，就說明了是動態傳參出了問題，
過不奇然，就是引數出了問題。
總結：出了問題，乙個乙個的去定位，是哪乙個小模組出了問題。2019-12-12
false的注意點，是否要加引號
對於選擇語句，你一定要注意，**是否進入了這個if語句體裡面，如果沒有，
就說明了是if判斷條件出了問題，在有些時候，
後端返回來的flase是乙個布林型別的值，
這個if(false=="false")不要加引號，因為有可能不會進入這個語句體
如果false是乙個字串，加上引號，否者有些時候，它也不會走這個迴圈體。 2019-12-12
總結：從這兩個問題來看，要快速定位到問題出現在了**，而不是盲目的去找 2019-12-12
後端如何過濾敏感欄位傳參給前端
一 背景 之所以寫這篇文章是因為最近一次和前端除錯乙個介面的時候，返給前端的字段有些是比較隱私的，涉及到使用者的基本資訊以及賬戶相關資訊，因此是比較重要的，如果將這些資訊顯示在前端的話非常危險，因此我們需要把這些重要的字段隱藏掉。二 如何解決 如果你只需要給前端傳乙個欄位如username那麼你可以...
如何快速定位TempDB產生問題
tempdb的爭用壓力在等待篇中已經簡單介紹，等待的表現為 pagelatch 類等待，等待的資源是 2 x x tempdb所在磁碟的響應時間 乙個例項下只有乙個tempdb，也就是當你在乙個例項下建立了100個資料庫，這100個資料庫也只能用這乙個tempdb。你建立的臨時表，或sql執行語句所...
如何快速定位TempDB產生問題
tempdb的爭用壓力在等待篇中已經簡單介紹，等待的表現為 pagelatch 類等待，等待的資源是 2 x x tempdb所在磁碟的響應時間 乙個例項下只有乙個tempdb，也就是當你在乙個例項下建立了100個資料庫，這100個資料庫也只能用這乙個tempdb。你建立的臨時表，或sql執行語句所...