什麼是BUG
漏洞是在硬體、軟體、協議的具體實現或系統安全策略上存在的缺陷，從而可以使攻擊者能夠在未授權的情況下訪問或破壞系統。具體舉例來說，比如在Intel Pentium晶片中存在的邏輯錯誤，在Sendmail早期版本中的程式設計錯誤，在NFS協議中認證方式上的弱點，在Unix系統管理員設定匿名Ftp服務時配置不當的問題都可能被攻擊者使用，威脅到系統的安全。因而這些都可以認為是系統中存在的安全漏洞。bug狹義的概念是指軟體程式漏洞或缺陷，廣義的概念還包括測試工程師或使用者所發現和提出的軟體可更改的細節、或與需求文件存在差異的功能實現等。
簡單點說就是 程式不按照你的預期執行，或者程式直接報錯了。在每個程式設計師的職業生涯中都會碰到或多或少的bug，有人寫的程式bug就是少，有人寫的程式bug就是很多。這是因為每個人的對技術的廣度和深度都不同。知道技術的原理寫起來程式碼肯定bug會少些，不懂原理寫起來肯定錯誤百出。但是即便你精通各種技術還是會出現bug，這是不可避免的。
對待BUG的態度
我見過無數程式設計師一看到程式出錯了就很緊張，彷彿報錯要他命似的。亂了陣腳，其實報錯不可怕，報錯都是可以處理的。你看到哪裡報錯找哪裡，找到哪一行想想那一行為啥會報錯。直接debug不就可以了。報錯沒事，心態放平慢慢找，一點一點debug，找到為什麼報錯就可以了。其實做久了才知道，報錯的bug一點都不可怕，不報錯的bug才可怕，邏輯完全正確，但就是不按照你預期的走。這種bug往往搞得你懷疑人生。
如何找BUG
找bug的前提是復現問題，很多bug都是在特定的情況下才會出現的，就像我們經常碰到的在自己電腦上沒問題在別人電腦上就有問題，或者在外網環境沒問題，在內網環境就不行。我們碰到這種情況要第一時間復現問題，如果復現不了問題你肯定解決不了。切記不能自己悶著頭瞎除錯。你的環境沒問題你還在你電腦上除錯，能除錯出來才怪了。你要去有問題的環境找問題，內網有毛病你就去內網復現問題，復現了再比較和外網有啥區別慢慢解決，切不可產生畏戰心理，其實好多問題只要找到根源就豁然開朗了。
一個不太好找的BUG
去年冬天公司安排我去哈爾濱培訓，培訓前我們把要培訓的功能測試了一遍，其他有問題的很快改了，偏偏我就遇到了一個問題，有一個介面請求後臺，後臺從session裡面拿資料，但是後臺的session物件一直為null，這就讓人很費解。session預設過期時間是30分鐘而我一直在請求後臺，session是不可能失效的。我在本地怎麼測怎麼沒問題。先說一下我們的環境，開發的時候我們是前端一個專案後端一個專案，前端系統配置選單，前端直接請求後端拿資料。而我們釋出後就成了，前端加頁面需要去另一個系統加，另一個系統是一套.net的系統，我們在.net系統裡面配置前端頁面地址，選單名，許可權等。經常做後臺管理系統的同學應該知道一般是上邊一欄選單，左邊一欄選單。中間是功能頁面。中間頁面是iframe，是一個系統。而我們就不一樣了，上邊和左邊的選單欄是一個系統，中間的功能頁是嵌的我們前端系統的頁面地址，中間功能頁也是iframe。開始我感覺和這些沒問題，既然功能頁都是iframe應該沒區別。但是我在本地怎麼也復現不了。這就很無奈，找bug你一定要找到蛛絲馬跡。我就看前端頁面傳送的請求，看了半天才發現問題。
我們看響應頭有一個 Set-Cookie 這裡給瀏覽器了一個Cookie 。看似沒啥毛病，但是我發現每一次請求後端都會給瀏覽器一個key為JSESSIONID的Cookie，而且每次請求時請求頭都不會把這個Cookie傳送到後臺。這就讓人很費解。這樣我也就明白了為啥後臺用Session物件的時候為null了。現在我們就找為啥請求的時候不將Cookie傳送給後臺，知道了為啥不傳送也就知道了問題所在。後臺給瀏覽器Cookie的時候別的都挺正常的但是SameSite=lax這個東西我看不懂。
經過我的百度查到了問題知道了這個屬性是啥意思。
簡單點來說就是谷歌為了安全性，在瀏覽器80版本以後就不允許不同站點的原頁面和iframe頁面請求時傳送Cookie，因為我們內網釋出的選單欄和iframe是倆系統也就是倆站點，所以iframe的頁面傳送的請求都不帶著Cookie，自然也就導致後臺拿不到Session了。而外網開發環境選單欄和iframe是一個系統所以iframe頁面傳送的請求都帶著cookie，也就不會導致後臺取不到Session了。至此我們發現問題所在。接著想辦法解決就可以了。
其實這個BUG將出來看似很簡單，其實不然，首先你要復現問題，其次你一定要知道Session和Http協議的工作原理，如果你不懂這倆技術的原理是肯定找不到問題所在的。
系統不存在一會行一會不行
還有一個問題，就是我們一臺伺服器上部署了兩個後臺系統，一個是A系統佔用80埠，一個是B系統佔用8080埠。有些前端頁面請求了A系統的後臺，有些前端頁面請求了B系統的後臺。別人給我反映經常丟Session(也就是上面說的後臺拿不到Session物件)一會好使一會不好使，好幾個人都沒找到咋回事，找到我了，其實我也很懵。但是我不認同別人的說法，系統絕對不存在一會可以一會不可以，可以的時候一定有可以的原因，不可以的時候一定有不可以的原因。有因必有果。經過我的測試如果一直使用請求A系統的頁面是沒問題的，一直使用請求B系統的頁面也是可以的。但是開啟過請求B系統的頁面再開啟請求A系統的頁面必報錯。然後我發現了問題所在，第一次開啟請求B系統的頁面B系統會響應給瀏覽器一個key為JSESSIONID的Cookie，因為這個瀏覽器第一次請求B系統。但是JSESSIONID的Path屬性為/ 而且Cookie作用域和埠沒關係，如果這時候我們開啟請求A系統的頁面也會把這個JSESSIONID帶過去，而這個值和A系統沒關係，A系統也就會重新給瀏覽器一個JSESSIONID，自然A系統也就拿不到Session了。出現BUG第一步一定是要復現，如果復現不了肯定找不到，其次要找痕跡想辦法找到哪裡不正常，懂原理。如果我不懂Cookie的作用域和埠沒關係肯定找不到原因所在。
如果喜歡本篇文章不妨關注點贊收藏，有什麼困惑歡迎評論。
歡迎關注接地氣程式設計師，公眾號，掘金，部落格園，簡書，CSDN同名。