在實作之前，我們必須了解一些關於玩爬蟲會用到的網頁基本原則和爬蟲技巧：

1. 任何 request 都是無狀態機制 (Stateless)

在大部分的狀況下，每個 request 應該將它當成是單一事件，他不會有前後 request 的影響。

舉個例子，常常有網站是需要登入才能取得使用者資料，假設登入是一個 request，取得使用者資料是一個 request，那麼正常的流程我們都會是先執行「登入 request」後，再執行「取得使用者 request」。但事實上，能正常執行「取得使用者 request」並非你必須先執行「登入 request」，而是在你發送「取得使用者 request」的時候，同時送出一個驗證過的 cookie。這代表說，無論任何人，在何時何地，只要透過任何方式擁有這個 cookie，那麼他不需要執行「登入 request」，只要付上這個 cookie，都能直接使用你的身份來成功送出「取得使用者 request」。

基本原則是，若是你能模擬出完全一樣的 request，那麼基本上所得到的回傳結果也應該是要一樣的，但若可能 server 那端有其他的驗證機制，例如鎖 IP 等，那麼以上就不見得成立。若我們送出一模一樣的 request 之後可以得到跟人為操作一模一樣的結果，那接下來我們的任務就很單純，就是將這個 request 所有要送出的主要條件一個一個把它搜集齊全。

2. header 裡的資訊

可以設身處地的想一下，若是我們製作一個網站，但會做基本的使用者驗證，那麼我們會怎麼做？可能會有使用者帳號密碼的驗證，然後將資訊存在 session 裡面，在 client 使用 cookie 存放 session ID，或者單純地用 basic auth， 以上這些資訊，都必須看 request header 才會知道，尤其是 response header。這也表示，任何 header 裡面的資訊可能都是蛛絲馬跡，我們可以一個一個嘗試 header 的 key value 是不是 server 會檢查的，適時的用刪去法，一個一個 header 刪掉，若出現的結果不同，那我們就能很肯定的知道 server 有檢查這項 header。

3. Server 的限制

在我們研究爬蟲的過程當中，很容易就造成攻擊 server 的狀況，例如一個迴圈沒寫好，就變成 ddos，所以通常 server 也都會有一些限制連線。像是 FB api 都有 rate limits，或是某些網站會將你的連線 ip 記錄在 session 裡面，然後在發出 request 的時候再反驗證 ip，有些會是去檢查 request 的 refer 是不是屬於同一個網域，這些都是在爬蟲過程當中我們必須注意的。當有遇到這類的限制狀況，我們在處理爬蟲的時候就會針對不同的限制有不同的機制。

4. 前端 render 與後端 render

目前的網頁製作方式可以分成前端 render、後端 render、和兩種混合模式。前端 render 就是由在 request 送出後，只拿到網頁的 template，然後會再透過 js 去產生真正的 html；後端 render 就在 request 送出後，就直接得到後端組好的 html；混合方式就是一開始使用後端 render，然後使用者在和網頁互動時，改成前端 render 的方式。

一般來說，爬蟲很容易去抓取後端 render 的資料，但若我們要抓取的網站是前端 render，那麼我們勢必要模擬 js 的執行才有可能組出正確的 html。解決辦法簡單分兩種，一種是我們真正的去 trace js 程式碼，這樣做會比較扎實，但相對來說會耗費許多時間在 research and testing，另一種就是模擬 browser 執行，我們可以使用上一篇所介紹的 high-level browser automation 套件 nightmare.js，可以快速的幫助我們抓取前端 render 的資料。

5. 留意 network，找尋 API

因為目前前端 render 的網站很多，很常網站是使用 api 作為與後端資料的交換，若我們能觀察到這些 api，那就能很輕鬆的直接抓取我們所需要的資料。在我們點擊網頁上任何互動時，都應該去想想看這個動作會不會是 ajax request，例如送出按鈕、換頁按鈕、讀取更多按鈕，在我們點擊這些按你的同時，都應該把 network 打開，同時觀察點擊的時候是不會會送出 ajax request 給後端，若有送出，那八九不離十肯定資料就在這個 response 裡面。

6. captcha 是天敵

在實作爬蟲的過程當中，大致上都能透過模擬人類動作而爬取資料，但有一種事情是無法模擬的，那就是驗證碼。因為我們是玩爬蟲，不是玩影像識別，所以大部分遇到這種狀況也就只能摸摸鼻子找下一個主題。不過，並不全然都得放棄，有以下幾種做法可以突破：

1. 繞路
   通常一個網站的流程不見得只有一條路，可能他在這條路上設置了 captcha，但其他路線卻沒有設置，例如網頁大小網，通常 mobile 版本的網站為了使用者體驗會拿掉驗證碼。
2. 對決
   我們可以使用 ocr 的軟體來協助破解，像是 opensource 的 opencv，但如何使用和如何 train 又是另外一個課題了。或者，我們可以使用有一些網路上面的 service 來做辨識，但大多必須付費才能使用，例如 http://www.deathbycaptcha.com 就是一個還挺好用的服務，每 1000 個成功驗證只需要 1 美元。
3. 鑽洞
   這種狀況很少，但我就曾經遇過網站的 captcha 是做假的，也曾經遇過網站將驗證內容寫入 cookie，或者直接使用圖片名稱來當作驗證內容。