什么是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同名。