簡介這份PDF面向零基礎(chǔ)到進階的Python爬蟲學(xué)習(xí)者系統(tǒng)梳理了從入門到實戰(zhàn)的完整學(xué)習(xí)框架幫助初學(xué)者解決「學(xué)什么、怎么學(xué)、在哪里學(xué)」的困惑。內(nèi)容圍繞爬蟲三部曲展開獲取數(shù)據(jù)環(huán)節(jié)講解urllib、requests、aiohttp等請求庫及異步抓取思路解析數(shù)據(jù)環(huán)節(jié)覆蓋BeautifulSoup、pyquery、XPath與正則表達式的定位技巧存儲數(shù)據(jù)環(huán)節(jié)則涉及TXT、JSON、CSV及MySQL、MongoDB等方案并延伸至代理IP、請求頭偽裝、Selenium動態(tài)渲染與分布式爬蟲等進階話題同時提醒Robots協(xié)議與合規(guī)邊界。資源為單個PDF文件壓縮包約2.1MB輕量便攜適合隨時查閱。目前已有174人學(xué)習(xí)可作為爬蟲知識體系搭建與查漏補缺的參考框架。1. 從一份學(xué)習(xí)框架說起為什么有人兩周上手有人卡在環(huán)境配置很多人第一次接觸 Python 爬蟲都是從收藏一份「完整學(xué)習(xí)框架」開始的。這份《2023年最新Python爬蟲的完整學(xué)習(xí)框架.pdf》就是典型代表——它不是某個具體項目的源碼包而是一張把「請求庫、解析庫、存儲方案、工程化框架」串起來的學(xué)習(xí)路線圖。我見過太多人把這類 PDF 存進網(wǎng)盤吃灰也見過有人照著框架兩周就能穩(wěn)定抓取主流站點數(shù)據(jù)。差別不在天賦在于有沒有把框架里的每個節(jié)點落到可運行的代碼上。這份資料解決的核心問題是告訴你學(xué)什么、按什么順序?qū)W、每個階段用什么庫。它把爬蟲拆成「獲取數(shù)據(jù) → 解析數(shù)據(jù) → 存儲數(shù)據(jù)」三部曲再往上延伸到 Scrapy、PySpider、Nutch 這類工程化框架。適合兩類人一是剛學(xué)完 Python 基礎(chǔ)語法、想找個明確路徑的初學(xué)者二是寫過零散腳本、但沒形成體系、遇到反爬就翻車的半熟手。如果你指望它是一份「復(fù)制粘貼就能跑」的代碼合集那會失望但如果你想少走彎路、知道每個階段該翻哪份文檔這份框架的參考價值很高。2. 請求層選型urllib、requests、aiohttp 到底先學(xué)哪個2.1 從標(biāo)準(zhǔn)庫 urllib 起步的理由框架里明確建議先從 Python 自帶的 urllib 開始這個順序是有道理的。urllib 是內(nèi)置的 HTTP 請求庫不需要額外安裝能讓你直接看到請求構(gòu)造的底層細(xì)節(jié)——URL 編碼、請求頭設(shè)置、超時處理、異常捕獲。很多人一上來就用 requests寫起來確實爽但遇到編碼問題、重定向異常時完全不知道底層發(fā)生了什么。用 urllib 發(fā)一個最基礎(chǔ)的 GET 請求代碼長這樣import urllib.request import urllib.parse # 構(gòu)造請求頭模擬瀏覽器 headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36 } # 目標(biāo) URL帶查詢參數(shù) params {q: python爬蟲, page: 1} url https://example.com/search? urllib.parse.urlencode(params) # 構(gòu)造 Request 對象并發(fā)送 req urllib.request.Request(url, headersheaders) try: with urllib.request.urlopen(req, timeout10) as resp: html resp.read().decode(utf-8) print(html[:500]) except urllib.error.HTTPError as e: print(fHTTP錯誤: {e.code}) except urllib.error.URLError as e: print(fURL錯誤: {e.reason})這段代碼的關(guān)鍵點有三個urlencode負(fù)責(zé)把字典轉(zhuǎn)成合法的查詢字符串避免手動拼接出錯Request對象承載請求頭User-Agent是最基礎(chǔ)的偽裝timeout參數(shù)必須設(shè)否則遇到不響應(yīng)的服務(wù)器會一直掛著。參數(shù)方面timeout10是秒數(shù)一般設(shè) 5 到 15 之間太短容易誤判超時太長會拖慢整體節(jié)奏。2.2 requests 的簡潔與 aiohttp 的異步提速當(dāng)你用 urllib 寫過十幾個請求之后切到 requests 會明顯感覺到效率提升。requests 自帶 JSON 解析、會話保持、編碼自動識別同樣的請求三行就能搞定import requests session requests.Session() session.headers.update({ User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36 }) resp session.get(https://example.com/api/list, params{page: 1}, timeout10) data resp.json() # 自動解析 JSON print(data.get(items, [])[:3])Session對象的好處是復(fù)用 TCP 連接和請求頭批量請求時比每次新建連接快不少。resp.json()直接返回字典省去手動json.loads。但同步請求的天花板很明顯?？蚣芾锾岬揭粋€數(shù)據(jù)請求同一個頁面 100 次同步方式最少 30 秒異步方式只需 3 秒左右。這個差距在批量抓取時就是能不能跑完的區(qū)別。aiohttp 配合async/await寫法能把并發(fā)請求壓到很低的時間成本import aiohttp import asyncio async def fetch(session, url): async with session.get(url, timeoutaiohttp.ClientTimeout(total10)) as resp: return await resp.text() async def main(urls): async with aiohttp.ClientSession() as session: tasks [fetch(session, u) for u in urls] results await asyncio.gather(*tasks) return results urls [fhttps://example.com/page/{i} for i in range(1, 21)] htmls asyncio.run(main(urls)) print(f抓取完成共 {len(htmls)} 頁)asyncio.gather把 20 個請求同時發(fā)出去總耗時接近最慢的那一個而不是累加。注意ClientTimeout要顯式設(shè)置aiohttp 默認(rèn)超時是 5 分鐘不設(shè)的話一個卡住的請求會拖死整批任務(wù)。常見做法是把并發(fā)數(shù)控制在 10 到 50 之間太高容易被目標(biāo)站點限流。提示異步爬蟲的調(diào)試比同步麻煩異常堆棧不直觀。建議先用同步版本跑通邏輯再改寫成異步。3. 解析層實戰(zhàn)BeautifulSoup、lxml、pyquery 與正則的邊界3.1 四種解析方式的適用場景拿到 HTML 之后下一步是從中提取目標(biāo)數(shù)據(jù)?？蚣芾锪辛怂姆N主流方案BeautifulSoup、pyquery、XPath配合 lxml、正則表達式。它們不是互相替代的關(guān)系而是各有各的舒適區(qū)。BeautifulSoup 的優(yōu)勢是容錯性強遇到標(biāo)簽不閉合、屬性缺失的臟 HTML 也能解析而且自動處理編碼轉(zhuǎn)換。缺點是速度偏慢大文檔解析時明顯。pyquery 用 jQuery 風(fēng)格的 CSS 選擇器前端基礎(chǔ)好的人上手極快底層用 lxml 解析器速度比 BeautifulSoup 快。XPath 是功能最全的支持超過 100 個內(nèi)置函數(shù)能做字符串處理、數(shù)值比較、節(jié)點定位適合結(jié)構(gòu)復(fù)雜的頁面。正則表達式速度最快但寫起來最費勁頁面結(jié)構(gòu)一變就得重寫。我一般會這樣選頁面結(jié)構(gòu)規(guī)整、需要快速出結(jié)果用 pyquery頁面臟亂、標(biāo)簽不規(guī)范用 BeautifulSoup需要按文本內(nèi)容、屬性值做復(fù)雜篩選用 XPath只需要提取幾個固定格式的字符串比如電話號碼、日期用正則。3.2 用 pyquery 提取列表數(shù)據(jù)的完整示例假設(shè)要抓一個商品列表頁每個商品有標(biāo)題、價格、鏈接。用 pyquery 的寫法from pyquery import PyQuery as pq import requests html requests.get(https://example.com/products, timeout10).text doc pq(html) items [] for li in doc(.product-list .item).items(): title li.find(.title).text().strip() price li.find(.price).attr(data-price) # 從屬性取價格 link li.find(a).attr(href) if title and price: items.append({title: title, price: price, link: link}) print(f共提取 {len(items)} 條) for it in items[:3]: print(it)doc(.product-list .item)是 CSS 選擇器層級關(guān)系用空格表示。.items()返回可迭代對象逐個處理。.text()取文本內(nèi)容.attr()取屬性值。這里有個細(xì)節(jié)價格放在>from lxml import etree html requests.get(https://example.com/products, timeout10).text tree etree.HTML(html) # XPath篩選>import csv data [ {title: 商品A, price: 199, link: https://example.com/a}, {title: 商品B, price: 299, link: https://example.com/b}, ] with open(products.csv, w, newline, encodingutf-8-sig) as f: writer csv.DictWriter(f, fieldnames[title, price, link]) writer.writeheader() writer.writerows(data)encodingutf-8-sig是為了讓 Excel 打開時不亂碼這個坑我踩過好幾次。newline防止 Windows 下多出空行。DictWriter按字典鍵寫入字段順序由fieldnames控制。4.2 MongoDB 存非結(jié)構(gòu)化數(shù)據(jù)的優(yōu)勢當(dāng)你要存的是評論、文章正文、圖片鏈接這類長度不固定、結(jié)構(gòu)不統(tǒng)一的數(shù)據(jù)時MongoDB 比 MySQL 更合適。它不需要預(yù)先定義表結(jié)構(gòu)直接存 JSON 文檔。用 PyMongo 操作from pymongo import MongoClient, errors client MongoClient(mongodb://localhost:27017/, serverSelectionTimeoutMS5000) db client[spider_db] col db[products] # 插入前先建唯一索引防止重復(fù)抓取 col.create_index(link, uniqueTrue) docs [ {title: 商品A, price: 199, link: https://example.com/a, tags: [數(shù)碼, 熱銷]}, {title: 商品B, price: 299, link: https://example.com/b, tags: [家居]}, ] for doc in docs: try: col.update_one({link: doc[link]}, {$set: doc}, upsertTrue) except errors.PyMongoError as e: print(f寫入失敗: {e}) print(f當(dāng)前集合文檔數(shù): {col.count_documents({})})update_one配合upsertTrue是冪等寫入的關(guān)鍵——同一個鏈接重復(fù)抓取時更新而不是重復(fù)插入。create_index(link, uniqueTrue)在數(shù)據(jù)庫層面兜底即使代碼邏輯有漏洞也不會產(chǎn)生重復(fù)數(shù)據(jù)。serverSelectionTimeoutMS設(shè)短一點連不上時快速失敗而不是干等。Redis 在框架里被定位為分布式爬蟲的數(shù)據(jù)存儲主要用來做請求隊列去重和緩存。單機爬蟲用不上但如果你要擴展到多臺機器協(xié)同抓取Redis 的 set 結(jié)構(gòu)做 URL 去重非常高效。5. 避坑與排查請求被拒、解析為空、數(shù)據(jù)重復(fù)的常見原因5.1 返回 403 或驗證碼頁面現(xiàn)象請求返回 403 狀態(tài)碼或者拿到的是一個驗證碼頁面而不是目標(biāo)內(nèi)容。原因最常見的是請求頭缺少User-Agent或者User-Agent用了默認(rèn)的 Python-urllib 標(biāo)識。其次是請求頻率太高觸發(fā)了目標(biāo)站點的限流。還有一種情況是目標(biāo)站點檢查了Referer或Cookie。解決補全請求頭至少包含User-Agent、Referer、Accept-Language。降低請求頻率在請求之間加time.sleep(random.uniform(1, 3))。如果目標(biāo)站點需要登錄態(tài)用Session保持 Cookie?？蚣芾锾岬降?Selenium 方案適合處理 JavaScript 渲染后才能拿到數(shù)據(jù)的頁面但它的開銷比純 HTTP 請求大得多能不用就不用。5.2 解析結(jié)果為空列表現(xiàn)象代碼沒報錯但提取到的數(shù)據(jù)是空列表或空字符串。原因三種可能——選擇器寫錯了數(shù)據(jù)是 JavaScript 動態(tài)加載的初始 HTML 里根本沒有頁面編碼不是 UTF-8中文變成亂碼導(dǎo)致匹配失敗。解決先在瀏覽器里用CtrlU查看頁面源代碼不是 Elements 面板確認(rèn)目標(biāo)數(shù)據(jù)是否在初始 HTML 里。如果不在說明需要抓包分析真實請求或者用 Selenium 渲染。選擇器問題可以用print(doc)打印前 500 個字符肉眼確認(rèn)結(jié)構(gòu)。編碼問題檢查resp.encoding必要時手動設(shè)為resp.apparent_encoding。5.3 數(shù)據(jù)重復(fù)寫入現(xiàn)象數(shù)據(jù)庫里出現(xiàn)大量重復(fù)記錄同一個商品被存了多次。原因爬蟲重跑時沒有做去重判斷或者去重邏輯只檢查了標(biāo)題而標(biāo)題有細(xì)微差異。解決用唯一標(biāo)識通常是 URL 或商品 ID做去重鍵。MongoDB 建唯一索引配合upsertTrueMySQL 用INSERT ... ON DUPLICATE KEY UPDATECSV 在寫入前用 set 記錄已處理的鏈接。不要依賴標(biāo)題去重標(biāo)題可能因為空格、標(biāo)點差異導(dǎo)致判斷失效。5.4 異步爬蟲報「Event loop is closed」現(xiàn)象aiohttp 腳本跑完一批請求后再跑第二批時報RuntimeError: Event loop is closed。原因asyncio.run()每次調(diào)用都會創(chuàng)建新的事件循環(huán)并在結(jié)束時關(guān)閉如果ClientSession在循環(huán)外創(chuàng)建第二次使用時循環(huán)已經(jīng)關(guān)了。解決把ClientSession的創(chuàng)建和關(guān)閉都放在async函數(shù)內(nèi)部用async with管理生命周期?；蛘哒麄€腳本只調(diào)用一次asyncio.run()把所有任務(wù)放在同一個main函數(shù)里。5.5 Robots 協(xié)議與訪問頻率現(xiàn)象爬蟲跑了一段時間后 IP 被封鎖或者收到站點的警告郵件。原因沒有遵守robots.txt的抓取規(guī)則或者請求頻率遠(yuǎn)超正常用戶行為。解決抓取前先訪問https://目標(biāo)站/robots.txt確認(rèn)Disallow的路徑不要碰?？刂撇l(fā)數(shù)單機爬蟲建議不超過 10 個并發(fā)請求間隔至少 1 秒?？蚣芾锾岬降?Robots 協(xié)議是爬蟲的基本規(guī)矩不是技術(shù)限制而是行為邊界越過這條線帶來的麻煩遠(yuǎn)大于省下的那點時間。6. 從腳本到工程Scrapy 的落地姿勢與一個驗證習(xí)慣當(dāng)你用 requests BeautifulSoup 寫了十幾個針對不同站點的腳本之后會發(fā)現(xiàn)大量代碼在重復(fù)請求重試、去重、并發(fā)控制、數(shù)據(jù)管道。這時候就該上 Scrapy 了。框架里把 Scrapy 定位為「最靈活的定制化爬取」這個評價很準(zhǔn)確——它的學(xué)習(xí)曲線比 requests 陡但一旦跑通擴展性和可維護性是腳本比不了的。Scrapy 的核心概念是 Spider、Item、Pipeline、Middleware。Spider 定義抓取邏輯Item 定義數(shù)據(jù)結(jié)構(gòu)Pipeline 負(fù)責(zé)清洗和存儲Middleware 處理請求和響應(yīng)的攔截。一個最小可運行的 Spiderimport scrapy class ProductSpider(scrapy.Spider): name product start_urls [https://example.com/products?page1] custom_settings { DOWNLOAD_DELAY: 1.5, # 請求間隔秒 CONCURRENT_REQUESTS: 8, # 并發(fā)數(shù) RETRY_TIMES: 3, # 重試次數(shù) USER_AGENT: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36, } def parse(self, response): for item in response.css(.product-list .item): yield { title: item.css(.title::text).get(default).strip(), price: item.attrib.get(data-price, ), link: response.urljoin(item.css(a::attr(href)).get()), } # 翻頁找到下一頁鏈接繼續(xù)抓 next_page response.css(a.next::attr(href)).get() if next_page: yield response.follow(next_page, callbackself.parse)custom_settings里的DOWNLOAD_DELAY和CONCURRENT_REQUESTS是最需要調(diào)的兩個參數(shù)。DOWNLOAD_DELAY1.5表示每個請求之間等 1.5 秒配合CONCURRENT_REQUESTS8實際對目標(biāo)站點的壓力大約是每秒 5 個請求。如果目標(biāo)站點響應(yīng)慢或者有限流跡象把并發(fā)降到 4、延遲加到 3 秒。RETRY_TIMES3讓失敗的請求自動重試省去手動寫重試邏輯。response.follow會自動處理相對 URL 和域名過濾比手動拼urljoin再yield Request簡潔。callbackself.parse表示下一頁返回的數(shù)據(jù)仍然用同一個解析函數(shù)處理形成遞歸抓取。Scrapy 跑起來之后驗證數(shù)據(jù)質(zhì)量有個習(xí)慣我一直在用先跑-s CLOSESPIDER_ITEMCOUNT20限制只抓 20 條把輸出導(dǎo)成 JSON 檢查字段完整性和去重情況確認(rèn)沒問題再放開全量抓取。scrapy crawl product -s CLOSESPIDER_ITEMCOUNT20 -o sample.jsonCLOSESPIDER_ITEMCOUNT20表示抓到 20 條就自動停止-o sample.json把結(jié)果輸出到文件。打開sample.json檢查標(biāo)題有沒有空值、價格格式是否統(tǒng)一、鏈接是否完整。這個習(xí)慣幫我省過很多次「跑了幾萬條才發(fā)現(xiàn)字段全錯」的后悔藥。從那以后我每次寫新 Spider都強制先跑 20 條樣本驗證再上全量。希望幫到你。本文還有配套的精品資源點擊獲取