requests 和 scrapy 在不同的爬蟲應用中，各自有什麼優勢？
requests 是一個http框架，可以用來做爬蟲
scrapy 是一個專業的爬蟲框架我是個python新手，研究怎麼爬人家網站，朋友推薦我學requests，果然看了下文檔，幾分鐘就能開始爬了
但是我看scrapy 這個爬蟲框架，被很多人喜歡，我想這個東西一定有他的獨特之處，
我目前使用requests爬的時候，先用其他方法得到cookies，然後把cookies共享給requests，然後爬網站的時候，用起來算很得心應手，但是爬過來的數據，我要自己寫邏輯代碼，進行解析，進行編碼處理，進行入庫
或許就是因為它只是一個http庫吧！然後我在思考，scrapy是一個框架，是不是在爬蟲應用中，會比requests更好用呢
我要爬的網站有40多個， 如果我改用scrapy框架，
能給我帶來多大的好處呢
分別會從哪些方面給我帶來好處呢請知友幫忙解答疑惑
-------------------------------------
請大家幫忙邀請一些牛人 謝謝
用 requests 庫發請求的爬蟲相比用 scrapy 框架寫的爬蟲，就好比組裝機之於品牌機。
對於大部分普通 PC 用戶，品牌機是一個不錯的選擇，因為品牌機提供了整套的打包方案，你不需要知道很詳細的細節就可以抱回家一台各方面表現均衡的電腦，不過，這台電腦僅僅是各方面表現均衡，如果你想在自己預算內買一台某方面滿足自己特定需求的電腦，可能就有些力不從心了。
而組裝機可以根據自己需求對特定硬體特殊處理，比如有大內存需求可以單獨買更大內存，或者可以單獨買更快速的硬碟等等。但是組裝機需要用戶比較了解電腦硬體，否則很容易被商家坑錢，相比品牌機花更多錢買回更不好用的電腦。而如果你是高級用戶，則組裝機可以幫你花可能更少的錢買回更適合自己的電腦。
當然，品牌機也可以再多加根內存條或者換個硬碟，不過，那不就跟組裝機一個意思了嗎。
這麼講，你能明白它們各自的優勢了嗎？職業採集。
爬蟲寫代碼中最耗時的是反爬蟲的問題。。開始寫代碼之前先檢查。。你可以先用scrapy的shell去請求你這個四十個網站的數據頁面，如果都能拿，那說明反爬蟲很一般，就直接scrapy來寫，因為這樣寫的代碼復用率很高，一般改正則和隊列即可。
但是在職業生涯中也就剛開始寫入門項目用scrapy，後來就因為要爬的網站一個比一個難搞，這時候用框架就不夠靈活了，，總是要改寫中間間也麻煩。。
比如
比如頁面有驗證碼怎麼辦？頁面檢查js能力怎麼辦？頁面數據後期載入怎麼辦？更改請求的ip有7種但是scrapy 只能直接內置使用其中三種。
再後來就自己手寫各種模塊然後復用自己的代碼。。畢竟框架只是為了好用，自己的代碼雖然渣了點，但是各種反爬蟲的技術點都趟過水。寫起來也方便。。
關於反爬蟲可以看看這個開源庫。。提供各種反爬蟲技術的樣例代碼。
https://github.com/luyishisi/Anti-Anti-Spider之前寫了篇文章講scrapy，題主可以我之前寫的一篇文章知乎專欄。
正如很多人說的，requests是庫，scrapy是框架，題主可能是對框架這個概念不太熟悉。
我們可以看看scrapy的框架圖：
這一框架就像一條爬蟲流水線，有工作隊列、有下載器、有分配任務的引擎，有對爬取數據寫邏輯的地方、也有寫保存處理數據的資料庫SQL的地方。對於scrapy而言，更多的時候是在配置scrapy。先要繼承一個spider寫爬蟲的主體，然後還要在setting里寫配置，在pipeline里寫資料庫。而且還要注意在主函數parse里的返回值，返回item時是交給pipline做數據處理，返回Request回調函數時是向爬取隊列註冊二級鏈接等等。
這樣看scrapy使用時比requests要繁瑣很多，後者只需要調用一下requests類，然後配置一下成員變數就可以使用，但獲取到html後其他的事情就都得你自己處理，自己寫的代碼還不是最好的。而scrapy在配置好後就可以很順暢的跑起來，還會自動處理很多東西，而且往往效率比自己造的輪子效率高。
所以如果是寫個小爬蟲，用request就可以了，如果代碼量級稍大一點，不想費心管理了，就可以用scrapy，當然也可以自己造輪子。
requests是庫，scrapy是框架。後者可以讓你少寫很多代碼
Requests只是一個構建網頁請求，獲取網頁響應的模塊，並不是框架。
在構建request方面，簡單易實現，且功能強大。
Requests 完全滿足如今網路的需求。
- 國際化域名和 URLs
- Keep-Alive 連接池
- 持久的 Cookie 會話
- 類瀏覽器式的 SSL 加密認證
- 基本/摘要式的身份認證
- 優雅的鍵/值 Cookies
- 自動解壓
- Unicode 編碼的響應體
- 多段文件上傳
- 連接超時
- 支持 .netrc
- 適用於 Python 2.6—3.4
- 線程安全
requests能夠實現的功能，scrapy也能便捷地實現。
scrapy是一個功能非常強大的爬蟲框架，它不僅能便捷地構建request，還有強大的selector能夠方便地解析response，然而它最受歡迎的還是它的性能，既抓取和解析的速度，它 的downloader是多線程的，request是非同步調度和處理的。這兩點使它的爬取速度非常之快。
另外還有內置的logging，exception，shell等模塊，為爬取工作帶來了很多便利。
在開始學習爬蟲的時候requests是個很好的選擇，後期實踐需要爬取大量的真實數據的時候，scrapy是個讓人信服的好框架 (☆_☆) ， 也是非常流行的大殺器。
我只知道requests的郵件列表把我gmail快刷爆了，一覺醒來手機顯示57未讀。作者對於各種問題的回答各種神速，甚至在traveling時也一樣。用requests售後超棒哦。
摺疊吧。純吐槽。這幾天requests發布2.3.0，我快被恭賀新禧的郵件弄吐了。
關於你的現狀
1scrapy一樣需要你請求解析入庫
2scrapy可以幫你提高效率
3你爬取40多個網站我不覺得sxrapy更容易管理
別著急，等你有需求的時候，就會用上scrapy了。
再此之前，先用requests
其實不同的需求對應不同的東西，在搞清楚用什麼之前，最先要知道，這個東西是什麼。那麼究竟什麼是這幫人整天念念不忘的scrapy？
在解決這個問題之前，我們要搞清楚另外一個問題，如果這個世界上有最快的爬蟲，它就究竟是什麼樣子的？
我不知道你有沒有想過，我覺得最快的爬蟲，應該是』cpu利用率達到100%，不斷的和對方伺服器進行通訊。而不是每一次請求之後都在等待伺服器響應。
好這種爬蟲就叫做非同步爬蟲，也就是說，假如一個伺服器等待5s才返回，我才不會傻傻的等著，我會一股腦的把爬蟲請求發出去，然後慢慢處理返回的請求。
當然，這是一個比較簡單的情況。scrapy就是這樣一種爬蟲。他底層用twisted這個非同步框架，保證爬蟲能更大效率的爬取。
但是啊，我不覺得這玩意有什麼好的。首先，我不太清楚他怎麼用多核心。其次，我覺得他流程做的非常噁心，寫起來也不太好調試。
我覺得唯一的好處就是他的callback很爽，但是我更喜歡node
所以，我更喜歡協程這種東西。
等有一天，你會從開始用scrapy然後又扔掉他，開始用是因為它是提高效率最快的方式，扔掉是因為，他開始讓你變慢。
那個時候就自己擼吧。scrapy是封裝起來的框架，他包含了下載器，解析器，日誌及異常處理，基於多線程， twisted的方式處理，對於固定單個網站的爬取開發，有優勢，但是對於多網站爬取 100個網站，並發及分散式處理方面，不夠靈活，不便調整與括展。
request 是一個HTTP庫， 它只是用來，進行請求，對於HTTP請求，他是一個強大的庫，下載，解析全部自己處理，靈活性更高，高並發與分散式部署也非常靈活，對於功能可以更好實現。
Requests allows you to send organic, grass-fed HTTP/1.1 requests, without the need for manual labor.
這是http庫啊，只能說是爬蟲的一個基礎部分，和scrapy這種框架怎麼比..
"
謝邀
這兩個完全不是一個東西啊……怎麼比啊！一個是爬蟲框架，一個是 http 庫。
推薦閱讀：