爬蟲bug的處理記錄

今天早上過來的時候，公司的運營反饋乙個問題，有乙個彩種一直抓不到資料。目前之剩下這乙個源，如果沒法抓取就沒有其他的源可以弄了。

因為有管理後台，登陸之後我就嘗試手工配置，我在她配置的基礎上做調整，發現確實是空了，然後我開始看日誌，發現test的scrapy走的是8032的乙個埠，但是docker上就沒有這個映象，那肯定不行，然後就配置了乙個映象，配置之後還是不行。就開始找**。

這裡犯了乙個錯誤，直接在伺服器找出錯的位置(**在本地其實是有拉取過的，雖然伺服器上可以找，但是還是有點麻煩)。然後就發現是頁面沒有抓取到。那個時候也猜到有js的問題了，不過把js給禁掉，還是能請求到資料。問了一下老大。得到的答案是第一次請求的時候，拿到了乙個cookie,所以後面有cookie之後就沒有這個問題了。當我清除session之後頁面上元素都沒了。

使用splash自帶的渲染，類似

curl 'http://localhost:8032/render.html?url='

這種方式，是可以拿到資料的。但是**裡面就是拿不到。我當時想法是，**應該不會錯，是不是引數**有問題，然後就開始找**渲染出來的源**。沒有找到問題。後來老大指導下才知道找錯了位置，發現返回的直接是乙個空白字串，也就是請求的時候沒有拿到資料。session不對，當時還有其他的報錯，有點被誤導了，浪費了一些時間。然後開始找session的問題，網上的版本很多，我嘗試照著官網的去做，沒有設定成功，返回的還是空白頁。後來就採用了planb, 把本地的session設定到線上去，因為這個輕易也不會清楚。也是照著官網做的，但因為是lua指令碼，有的地方又粗心搞錯了。。。然後就有點崩潰。就問了一下老大如何解決。

後來老大說:

有可能我們伺服器上的版本不支援這個寫法，總之現在報的錯是說你**寫錯了,而不是說這個思路走不通,你要搞清楚二者的區別,思路走不通才考慮換思路，**有問題應該改**,而不是**沒寫對就換思路

我嘗試了比較多，比如官網的，後來被發現是多打了乙個字母。

最後問題得以解決，老大是這麼說的:

發現問題->分析問題->找到問題關鍵->深入了解問題關鍵->針對關鍵點處理問題。你這個bug沒處理好的問題，粗心是乙個，不用多說了。更重要的是發現問題以後，沒有想辦法深入了解問題而是嘗試繞過問題，這個方**不對。

這裡我確實做的不好，好像那種再挖幾下就挖到泉水的時候，放棄了。可能是平時遇到的問題沒有這麼麻煩。挖的太深了，又出現了很多其他的情況，很多沒有想到的問題。如果是**問題，解決它，而不能因為報錯就轉而考慮其他方法，這個確實是問題。我之前鑽的很深，也導致一些好的方法就沒機會看。以後必須注意。

參考：

爬蟲bug的處理記錄

bug修復記錄

Bug記錄歸納

日常 bug記錄

爬蟲bug的處理記錄

bug修復記錄

Bug記錄 歸納

日常 bug記錄

相關推薦

Bug記錄歸納