習(xí)框架：從urllib到Scrapy的完整路線與避坑指南)
簡介這份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 從標準庫 urllib 起步的理由框架里明確建議先從 Python 自帶的 urllib 開始這個順序是有道理的。urllib 是內(nèi)置的 HTTP 請求庫不需要額外安裝能讓你直接看到請求構(gòu)造的底層細節(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 } # 目標 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負責(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 默認超時是 5 分鐘不設(shè)的話一個卡住的請求會拖死整批任務(wù)。常見做法是把并發(fā)數(shù)控制在 10 到 50 之間太高容易被目標站點限流。提示異步爬蟲的調(diào)試比同步麻煩異常堆棧不直觀。建議先用同步版本跑通邏輯再改寫成異步。3. 解析層實戰(zhàn)BeautifulSoup、lxml、pyquery 與正則的邊界3.1 四種解析方式的適用場景拿到 HTML 之后下一步是從中提取目標數(shù)據(jù)?？蚣芾锪辛怂姆N主流方案BeautifulSoup、pyquery、XPath配合 lxml、正則表達式。它們不是互相替代的關(guān)系而是各有各的舒適區(qū)。BeautifulSoup 的優(yōu)勢是容錯性強遇到標簽不閉合、屬性缺失的臟 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頁面臟亂、標簽不規(guī)范用 BeautifulSoup需要按文本內(nèi)容、屬性值做復(fù)雜篩選用 XPath只需要提取幾個固定格式的字符串比如電話號碼、日期用正則。3.2 用 pyquery 提取列表數(shù)據(jù)的完整示例假設(shè)要抓一個商品列表頁每個商品有標題、價格、鏈接。用 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()取屬性值。這里有個細節(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)碼或者拿到的是一個驗證碼頁面而不是目標內(nèi)容。原因最常見的是請求頭缺少User-Agent或者User-Agent用了默認的 Python-urllib 標識。其次是請求頻率太高觸發(fā)了目標站點的限流。還有一種情況是目標站點檢查了Referer或Cookie。解決補全請求頭至少包含User-Agent、Referer、Accept-Language。降低請求頻率在請求之間加time.sleep(random.uniform(1, 3))。如果目標站點需要登錄態(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 面板確認目標數(shù)據(jù)是否在初始 HTML 里。如果不在說明需要抓包分析真實請求或者用 Selenium 渲染。選擇器問題可以用print(doc)打印前 500 個字符肉眼確認結(jié)構(gòu)。編碼問題檢查resp.encoding必要時手動設(shè)為resp.apparent_encoding。5.3 數(shù)據(jù)重復(fù)寫入現(xiàn)象數(shù)據(jù)庫里出現(xiàn)大量重復(fù)記錄同一個商品被存了多次。原因爬蟲重跑時沒有做去重判斷或者去重邏輯只檢查了標題而標題有細微差異。解決用唯一標識通常是 URL 或商品 ID做去重鍵。MongoDB 建唯一索引配合upsertTrueMySQL 用INSERT ... ON DUPLICATE KEY UPDATECSV 在寫入前用 set 記錄已處理的鏈接。不要依賴標題去重標題可能因為空格、標點差異導(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ī)則或者請求頻率遠超正常用戶行為。解決抓取前先訪問https://目標站/robots.txt確認Disallow的路徑不要碰?？刂撇l(fā)數(shù)單機爬蟲建議不超過 10 個并發(fā)請求間隔至少 1 秒。框架里提到的 Robots 協(xié)議是爬蟲的基本規(guī)矩不是技術(shù)限制而是行為邊界越過這條線帶來的麻煩遠大于省下的那點時間。6. 從腳本到工程Scrapy 的落地姿勢與一個驗證習(xí)慣當(dāng)你用 requests BeautifulSoup 寫了十幾個針對不同站點的腳本之后會發(fā)現(xiàn)大量代碼在重復(fù)請求重試、去重、并發(fā)控制、數(shù)據(jù)管道。這時候就該上 Scrapy 了。框架里把 Scrapy 定位為「最靈活的定制化爬取」這個評價很準確——它的學(xué)習(xí)曲線比 requests 陡但一旦跑通擴展性和可維護性是腳本比不了的。Scrapy 的核心概念是 Spider、Item、Pipeline、Middleware。Spider 定義抓取邏輯Item 定義數(shù)據(jù)結(jié)構(gòu)Pipeline 負責(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實際對目標站點的壓力大約是每秒 5 個請求。如果目標站點響應(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 檢查字段完整性和去重情況確認沒問題再放開全量抓取。scrapy crawl product -s CLOSESPIDER_ITEMCOUNT20 -o sample.jsonCLOSESPIDER_ITEMCOUNT20表示抓到 20 條就自動停止-o sample.json把結(jié)果輸出到文件。打開sample.json檢查標題有沒有空值、價格格式是否統(tǒng)一、鏈接是否完整。這個習(xí)慣幫我省過很多次「跑了幾萬條才發(fā)現(xiàn)字段全錯」的后悔藥。從那以后我每次寫新 Spider都強制先跑 20 條樣本驗證再上全量。希望幫到你。本文還有配套的精品資源點擊獲取 Python爬蟲學(xué)習(xí)框架：從urllib到Scrapy的完整路線與避坑指南
簡介這份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 從標準庫 urllib 起步的理由框架里明確建議先從 Python 自帶的 urllib 開始這個順序是有道理的。urllib 是內(nèi)置的 HTTP 請求庫不需要額外安裝能讓你直接看到請求構(gòu)造的底層細節(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 } # 目標 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負責(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 默認超時是 5 分鐘不設(shè)的話一個卡住的請求會拖死整批任務(wù)。常見做法是把并發(fā)數(shù)控制在 10 到 50 之間太高容易被目標站點限流。提示異步爬蟲的調(diào)試比同步麻煩異常堆棧不直觀。建議先用同步版本跑通邏輯再改寫成異步。3. 解析層實戰(zhàn)BeautifulSoup、lxml、pyquery 與正則的邊界3.1 四種解析方式的適用場景拿到 HTML 之后下一步是從中提取目標數(shù)據(jù)?？蚣芾锪辛怂姆N主流方案BeautifulSoup、pyquery、XPath配合 lxml、正則表達式。它們不是互相替代的關(guān)系而是各有各的舒適區(qū)。BeautifulSoup 的優(yōu)勢是容錯性強遇到標簽不閉合、屬性缺失的臟 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頁面臟亂、標簽不規(guī)范用 BeautifulSoup需要按文本內(nèi)容、屬性值做復(fù)雜篩選用 XPath只需要提取幾個固定格式的字符串比如電話號碼、日期用正則。3.2 用 pyquery 提取列表數(shù)據(jù)的完整示例假設(shè)要抓一個商品列表頁每個商品有標題、價格、鏈接。用 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()取屬性值。這里有個細節(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)碼或者拿到的是一個驗證碼頁面而不是目標內(nèi)容。原因最常見的是請求頭缺少User-Agent或者User-Agent用了默認的 Python-urllib 標識。其次是請求頻率太高觸發(fā)了目標站點的限流。還有一種情況是目標站點檢查了Referer或Cookie。解決補全請求頭至少包含User-Agent、Referer、Accept-Language。降低請求頻率在請求之間加time.sleep(random.uniform(1, 3))。如果目標站點需要登錄態(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 面板確認目標數(shù)據(jù)是否在初始 HTML 里。如果不在說明需要抓包分析真實請求或者用 Selenium 渲染。選擇器問題可以用print(doc)打印前 500 個字符肉眼確認結(jié)構(gòu)。編碼問題檢查resp.encoding必要時手動設(shè)為resp.apparent_encoding。5.3 數(shù)據(jù)重復(fù)寫入現(xiàn)象數(shù)據(jù)庫里出現(xiàn)大量重復(fù)記錄同一個商品被存了多次。原因爬蟲重跑時沒有做去重判斷或者去重邏輯只檢查了標題而標題有細微差異。解決用唯一標識通常是 URL 或商品 ID做去重鍵。MongoDB 建唯一索引配合upsertTrueMySQL 用INSERT ... ON DUPLICATE KEY UPDATECSV 在寫入前用 set 記錄已處理的鏈接。不要依賴標題去重標題可能因為空格、標點差異導(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ī)則或者請求頻率遠超正常用戶行為。解決抓取前先訪問https://目標站/robots.txt確認Disallow的路徑不要碰?？刂撇l(fā)數(shù)單機爬蟲建議不超過 10 個并發(fā)請求間隔至少 1 秒。框架里提到的 Robots 協(xié)議是爬蟲的基本規(guī)矩不是技術(shù)限制而是行為邊界越過這條線帶來的麻煩遠大于省下的那點時間。6. 從腳本到工程Scrapy 的落地姿勢與一個驗證習(xí)慣當(dāng)你用 requests BeautifulSoup 寫了十幾個針對不同站點的腳本之后會發(fā)現(xiàn)大量代碼在重復(fù)請求重試、去重、并發(fā)控制、數(shù)據(jù)管道。這時候就該上 Scrapy 了。框架里把 Scrapy 定位為「最靈活的定制化爬取」這個評價很準確——它的學(xué)習(xí)曲線比 requests 陡但一旦跑通擴展性和可維護性是腳本比不了的。Scrapy 的核心概念是 Spider、Item、Pipeline、Middleware。Spider 定義抓取邏輯Item 定義數(shù)據(jù)結(jié)構(gòu)Pipeline 負責(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實際對目標站點的壓力大約是每秒 5 個請求。如果目標站點響應(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 檢查字段完整性和去重情況確認沒問題再放開全量抓取。scrapy crawl product -s CLOSESPIDER_ITEMCOUNT20 -o sample.jsonCLOSESPIDER_ITEMCOUNT20表示抓到 20 條就自動停止-o sample.json把結(jié)果輸出到文件。打開sample.json檢查標題有沒有空值、價格格式是否統(tǒng)一、鏈接是否完整。這個習(xí)慣幫我省過很多次「跑了幾萬條才發(fā)現(xiàn)字段全錯」的后悔藥。從那以后我每次寫新 Spider都強制先跑 20 條樣本驗證再上全量。希望幫到你。本文還有配套的精品資源點擊獲取