簡介這是一份基于Python的企查查爬蟲實現(xiàn)方案面向計算機科學、人工智能、通信工程、自動化、電子信息等專業(yè)學生及畢業(yè)設(shè)計、課程設(shè)計場景解決企業(yè)公開信息批量采集與結(jié)構(gòu)化整理問題同時適合有一定Python基礎(chǔ)、希望進階爬蟲實戰(zhàn)的開發(fā)者。資源包共2個文件以Python腳本和Markdown說明文檔為主爬蟲源碼包含請求發(fā)送、頁面解析、數(shù)據(jù)提取與結(jié)果保存的完整邏輯配套文檔說明環(huán)境配置與使用流程壓縮包整體僅3KB輕量易讀。目前已有2057人學習代碼經(jīng)測試運行成功可支撐畢設(shè)演示、作業(yè)提交或二次開發(fā)拓展。讀者可獲得可直接運行的爬蟲工程以及理解頁面結(jié)構(gòu)解析、數(shù)據(jù)清洗、異常處理等要點的注釋與說明便于快速上手也可在此基礎(chǔ)上增加新功能或結(jié)合企查查平臺規(guī)則調(diào)整采集策略用于學習與項目演練。1. 企查查爬蟲爬「完整的公司數(shù)據(jù)」前先搞清數(shù)據(jù)是怎么到你屏幕上的把企查查上的公司數(shù)據(jù)完整爬下來需要幾步搜一圈現(xiàn)成腳本大多數(shù)人第一次跑都會撞上同一個現(xiàn)象requests 發(fā)出去了狀態(tài)碼乖乖返回 200解析 JSON 卻拋異常把響應(yīng)體打出來才發(fā)現(xiàn)是一段登錄頁 HTML。企查查的前端是動態(tài)渲染的頁面上看到的字段大多是瀏覽器加載完成后由后臺 JSON 接口二次填充的這些接口藏在加密 JS、Cookie 校驗和頻率限制后面地址欄那個 URL 直接 GET 是拿不到數(shù)據(jù)的。理解這件事是整條爬取路線的第一步。這篇文章從抓包定位真實接口開始走一遍「搜索列表 → 公司詳情 → 完整字段落地」的最小可復(fù)現(xiàn)路徑再把驗證碼、字段缺失、登錄態(tài)失效這類高概率翻車點單獨鋪開最后落到增量更新和工程化習慣。適合會用 requests、想落地一套真實可用采集腳本的讀者全是細節(jié)沒有空話。2. 先看清企查查的數(shù)據(jù)接口形態(tài)動態(tài)渲染、加密參數(shù)與登錄態(tài)動手寫代碼之前先花半小時把瀏覽器開發(fā)者工具打開。這半小時能省掉后面一整天的逆向時間。企查查這類平臺前端結(jié)構(gòu)經(jīng)常改版拿一周前的選擇器套今天的頁面很可能一條數(shù)據(jù)都解不出來。2.1 用瀏覽器開發(fā)者工具定位真實數(shù)據(jù)來源很多人一上來就對著 Elements 面板抄 CSS 選擇器這是第一個坑。Elements 里看到的是最終渲染結(jié)果不是服務(wù)器原始返回。正確做法是把面板切到 Network網(wǎng)絡(luò)勾選 XHR/Fetch 篩選項然后在搜索框輸入一家公司名并回車。此時請求列表里會出現(xiàn)一批異步請求你要找的不是返回 HTML 的那個而是返回 JSON 的接口。判斷依據(jù)很簡單點擊響應(yīng)預(yù)覽看到creditCode、legalPerson、regStatus這組字段名基本就是真正取數(shù)接口。找到后右鍵該請求選擇 Copy → Copy as cURL粘貼到本地文本文件里。這段 cURL 完整保留了 URL、請求方法、請求頭和 Cookie是后面構(gòu)造 Python 請求最可靠的對照物。我一般會再把它粘到命令行實際跑一次確認還能返回數(shù)據(jù)才開始寫代碼。這里我要多說一句接口地址和參數(shù)名會隨前端改版變化代碼里的 URL 只作為樣例每次開工前以抓包結(jié)果為準這句話值得寫在項目 README 的第一行。提示接口地址和參數(shù)名會隨前端改版變化。正式開工前重新抓一次包把 URL、請求方法、請求頭、請求體四件套更新到配置里而不是沿用舊版本。2.2 加密參數(shù)與簽名不是所有參數(shù)都要逆向細看抓到的請求 URL可能會發(fā)現(xiàn)幾個看不懂的參數(shù)比如token、sig、timestamp。它們的來源不外乎兩種服務(wù)端下發(fā)到頁面里的或是前端 JS 運行時計算的。遇到這些參數(shù)先別急著上逆向。我的經(jīng)驗是分場景選方案如果只用 requests 裸調(diào)接口簽名參數(shù)必須過了逆向這一關(guān)需要定位到生成簽名的 JS 函數(shù)再做邏輯還原成本最高如果改用 Playwright 驅(qū)動真實瀏覽器簽名參數(shù)由頁面自己算好你只需要等待請求完成讀取渲染后的結(jié)果或者攔截響應(yīng)拿到 JSON。中小規(guī)模采集任務(wù)選后者代碼量少維護成本也低。還要注意一個反爬細節(jié)部分敏感字段在 HTML 里會被打散。手機號、郵箱這類信息頁面會拆成多個字符節(jié)點中間插入隱藏標簽直接用.text提取拿到的往往是碎片。正確做法是在解析時先把同屬一個字段的節(jié)點收集起來再拼接或者優(yōu)先找有沒有對應(yīng)的 JSON 接口。網(wǎng)上很多「爬到的數(shù)據(jù)是殘缺的」反饋其實都卡在這一步。2.3 Cookie 與登錄態(tài)給腳本續(xù)上「身份」企查查的搜索接口在未登錄狀態(tài)下能返回基礎(chǔ)列表但詳情頁里的股東、變更記錄、主要人員等多數(shù)字段要登錄后才看得到。如果目標只是列表數(shù)據(jù)可以暫時不處理登錄但只要目標是「完整公司數(shù)據(jù)」登錄態(tài)就是繞不開的前提。我的做法是手動登錄一次把登錄態(tài)保存成文件后續(xù)所有抓取直接加載它。保存有兩種方案用 Playwright 的storage_state把 cookie 和 localStorage 整體導(dǎo)出后續(xù)加載創(chuàng)建一個新上下文或者用瀏覽器擴展導(dǎo)出 cookie 成 JSON再手動塞進 requests 的Cookie頭。Playwright 方案在腳本里閉環(huán)不用來回切工具我一般選這個。登錄態(tài)會過期Cookie 的有效期從幾小時到幾天不等。如果腳本里沒有探活機制凌晨三點爬起來看日志會發(fā)現(xiàn)第一個請求就撞上了登錄墻后面全是無效數(shù)據(jù)。所以正式開工前先加一個「探活請求」隨機請求一個需要登錄的接口判斷響應(yīng)里有沒有登錄用戶標識字段。沒有就停下來提示重新登錄。這個動作很小卻能把整個任務(wù)的失敗模式從「靜默跑了一夜」變成「明確報錯」。另一個高發(fā)翻車點是指紋不一致。比如第一次用 Chrome 的 User-Agent 發(fā)了請求后面某個函數(shù)里又用了默認的 Python-requests UA這個差異很容易被風控識別。我的習慣是在項目里維護一個統(tǒng)一的 HEADERS 常量所有請求都從它復(fù)制避免各寫一份。Referer 同樣要固定企查查部分接口對 Referer 做了校驗缺失或來源異常時返回空列表。3. 用 requests 實現(xiàn)基礎(chǔ)版搜索公司列表與字段落地原理清楚了接下來寫能跑的東西。這一章先實現(xiàn)一個搜索列表采集它能解決第一階段 80% 的字段需求也是后面詳情頁采集的入口。3.1 最小可用代碼搜索接口與參數(shù)說明下面這份代碼以常見搜索接口為例子實際請求地址以你抓包結(jié)果為準。import time import requests # 以實際抓包為準這里只做示意 SEARCH_API https://www.qcc.com/api/search/company 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 ), Referer: https://www.qcc.com/, Accept: application/json, text/plain, */*, } def search_companies(keyword, pages1, sessionNone): 按關(guān)鍵詞搜索公司返回公司摘要列表。 s session or requests.Session() s.headers.update(HEADERS) result [] for page in range(1, pages 1): params {key: keyword, page: page} try: resp s.get(SEARCH_API, paramsparams, timeout10) resp.raise_for_status() data resp.json() except Exception as exc: print(f第 {page} 頁失敗: {exc}) break items data.get(result, {}).get(list, []) if not items: print(f第 {page} 頁沒有數(shù)據(jù)停止翻頁) break for item in items: result.append({ 公司名稱: item.get(name), 統(tǒng)一社會信用代碼: item.get(creditCode), 法定代表人: item.get(legalPerson), 成立日期: item.get(startDate), 登記狀態(tài): item.get(regStatus), 詳情鏈接: item.get(detailUrl), }) time.sleep(2.5) return result這段代碼里有四個值得說明的參數(shù)session用 requests.Session 而不是裸的 requests.get是為了把 UA、Referer、Cookie 統(tǒng)一管理避免每個請求反復(fù)傳 headers。timeout10不設(shè)超時遇到慢接口時線程會一直掛著批量抓取時會越積越多。time.sleep(2.5)最簡單的頻率控制。你可以把它換成random.uniform(2.5, 4.5)讓間隔有一點隨機擾動。改成 0.1 的話大概率幾十個請求后就會見到驗證碼。異常處理先打成 print正式工程里換成日志模塊第 6 章會給出統(tǒng)一的裝飾器方案。3.2 解析 JSON字段篩選、編碼與空值處理接口返回的 JSON 結(jié)構(gòu)大致長這樣實際字段名以抓包為準{ result: { list: [ { name: 某科技有限公司, creditCode: 91110000XXXXXXXXXX, legalPerson: 張三, startDate: 2020-01-01, regStatus: 存續(xù), detailUrl: https://www.qcc.com/firm/xxx.html } ] } }字段映射時我一般會做三個處理第一所有字段都走.get()拿不到就返回None避免 KeyError 中斷任務(wù)第二把信用代碼字段作為業(yè)務(wù)主鍵后續(xù)入庫去重都依賴它第三遇到嵌套結(jié)構(gòu)比如股東在列表接口里是{ name: 李四, ratio: 10% }先json.dumps存字符串等建好數(shù)據(jù)庫再拆表。落盤第一步我建議用 CSV方便在 Excel 里快速檢查字段完整性。一個容易忽視的細節(jié)文件編碼要用utf-8-sig而不是utf-8否則 Excel 打開 CSV 時中文字段名會亂碼。import csv def save_companies(items, pathcompanies.csv): 把公司列表寫入 CSV自動處理表頭。 if not items: print(沒有數(shù)據(jù)不生成文件) return fields list(items[0].keys()) with open(path, w, encodingutf-8-sig, newline) as f: writer csv.DictWriter(f, fieldnamesfields) writer.writeheader() writer.writerows(items)寫完 CSV 后主動讀出來打印前 5 行確認字段和中文正常再繼續(xù)。這一步看起來多余卻能提前發(fā)現(xiàn)字段錯位。3.3 頻率控制與異常重試把反爬當成延遲處理在爬蟲這件事上我一直堅持一個觀念控制頻率比追求速度重要。被封了不是最可怕的最麻煩的是封了之后可能幾小時內(nèi)都不讓你恢復(fù)整個任務(wù)節(jié)奏全被打亂。與其事后找后悔藥不如事前把節(jié)奏放慢。處理異常時先把錯誤分個類再決定動作響應(yīng)特征判定方向建議動作HTTP 200 JSON正常響應(yīng)解析入庫HTTP 200 HTML被反爬攔截或未登錄停止當前關(guān)鍵詞翻頁HTTP 302登錄態(tài)失效走重新登錄流程HTTP 4xx參數(shù)錯誤或被限制打印響應(yīng)體確認遇到偶發(fā)超時重試 3 次間隔遞增 1 秒、3 秒、8 秒連續(xù)失敗就跳過當前頁不要無限重試。遇到 JSON 解析失敗立刻停止當前關(guān)鍵詞的翻頁因為大概率已經(jīng)被反爬攔截繼續(xù)翻只會拉高風險。4. 從摘要到完整工商數(shù)據(jù)詳情頁、動態(tài)渲染與關(guān)聯(lián)數(shù)據(jù)入庫列表數(shù)據(jù)解決了接下來是重頭戲完整工商數(shù)據(jù)。這一章把詳情頁采集、登錄態(tài)管理和數(shù)據(jù)庫設(shè)計串起來。4.1 列表數(shù)據(jù)與詳情數(shù)據(jù)是兩套東西搜索接口返回的列表一般只有十幾個核心字段。你要的「完整數(shù)據(jù)」——注冊資本實繳、股東及出資比例、主要人員、變更記錄、分支機構(gòu)、對外投資——都在詳情頁或獨立的子接口里。很多初學教程只講列表采集導(dǎo)致有人以為自己「爬完了」交出去的核心字段卻遠遠不夠。詳情頁的數(shù)據(jù)來源通常分兩類一類直接嵌在返回的 HTML 里另一類是頁面加載時又發(fā)起的 JSON 接口。寫解析之前先打開 Network 把詳情頁的數(shù)據(jù)來源過一遍再用代碼去對號入座。選擇器最好用有語義的 class 或 id不要寫一整條從div到span的絕對路徑前端一改版就全部失效。4.2 用 Playwright 渲染詳情頁登錄態(tài)保存與等待策略對 HTML 部分用 BeautifulSoup 就夠?qū)Ξ惒郊虞d的部分直接用 Playwright 把整個頁面渲染完再提取更省事。先從手動登錄開始把登錄態(tài)存下來from playwright.sync_api import sync_playwright # 有頭模式手動登錄生成 storage_state.json with sync_playwright() as p: browser p.chromium.launch(headlessFalse) context browser.new_context() page context.new_page() page.goto(https://www.qcc.com/, timeout30000) input(請在彈出的瀏覽器里掃碼登錄完成后回到終端按回車...) context.storage_state(pathstorage_state.json) browser.close()這段代碼里的input()是給人留的操作窗口瀏覽器停在登錄頁你掃碼完成后回終端回車登錄態(tài)就寫進文件。后面抓取時重新加載這份登錄態(tài)from playwright.sync_api import sync_playwright def fetch_detail_html(detail_url, storage_statestorage_state.json): 渲染詳情頁返回最終 HTML。 with sync_playwright() as p: browser p.chromium.launch(headlessTrue) context browser.new_context( storage_statestorage_state, 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 ), ) page context.new_page() page.goto(detail_url, timeout30000) page.wait_for_load_state(networkidle) page.wait_for_selector(text統(tǒng)一社會信用代碼, timeout15000) html page.content() browser.close() return html這里有三個細節(jié)值得注意headlessTrue是無頭模式如果發(fā)現(xiàn)目標對無頭識別嚴格可以把 headless 設(shè)成 False用性能換可用性批量不大時是劃算的。wait_for_selector的等待條件最好選一個只有登錄后才能看到的文本比如「統(tǒng)一社會信用代碼」等錯元素會出現(xiàn)拿到半截 HTML 的情況。networkidle不是萬能的頁面如果有輪詢請求會一直等。遇到這種情況改用wait_for_function判斷關(guān)鍵字段已出現(xiàn)。拿到 HTML 后用 BeautifulSoup 做字段抽取from bs4 import BeautifulSoup def parse_detail(html): 從詳情頁 HTML 中抽取公司基本信息。 soup BeautifulSoup(html, html.parser) result {} name_el soup.select_one(h1#companyTopName) if name_el: result[公司名稱] name_el.text.strip() container soup.select_one(.company-info-wrapper) if container: for row in container.select(.info-item): label row.select_one(.info-label) value row.select_one(.info-value) if label and value: result[label.text.strip()] value.text.strip() return result選擇器要按目標網(wǎng)站的實際 HTML 結(jié)構(gòu)調(diào)整但解析思路是通用的找到字段容器循環(huán)取出「標簽—值」對。對股東這類需要點開列表的字段可以考慮攔截頁面加載時一并請求的 JSON 接口直接拿結(jié)構(gòu)化數(shù)據(jù)比模擬點擊更可靠。4.3 數(shù)據(jù)庫建表與關(guān)聯(lián)數(shù)據(jù)的外鍵設(shè)計字段多起來后CSV 就撐不住了。項目初期直接切 SQLite三張表起步company公司主表shareholder股東表change_record變更記錄表。CREATE TABLE company ( id INTEGER PRIMARY KEY AUTOINCREMENT, credit_code TEXT UNIQUE, name TEXT, legal_person TEXT, status TEXT, detail_url TEXT, created_at TEXT DEFAULT (datetime(now)) ); CREATE TABLE shareholder ( id INTEGER PRIMARY KEY AUTOINCREMENT, company_id INTEGER NOT NULL, shareholder_name TEXT, share_ratio TEXT, subscribed_amount TEXT, FOREIGN KEY (company_id) REFERENCES company(id) ); CREATE TABLE change_record ( id INTEGER PRIMARY KEY AUTOINCREMENT, company_id INTEGER NOT NULL, item TEXT, before_value TEXT, after_value TEXT, change_date TEXT, FOREIGN KEY (company_id) REFERENCES company(id) );用credit_code做 UNIQUE 的好處是同一家公司重復(fù)抓取時可以先查后插存在則跳過或走更新邏輯不存在才插入。這一條規(guī)則是后面增量爬蟲的基礎(chǔ)。入庫函數(shù)用ON CONFLICT處理主鍵沖突import sqlite3 def upsert_company(db_path, data): 按信用代碼插入或更新公司主表。 conn sqlite3.connect(db_path) sql INSERT INTO company (credit_code, name, legal_person, status, detail_url) VALUES (:credit_code, :name, :legal_person, :status, :detail_url) ON CONFLICT(credit_code) DO UPDATE SET legal_personexcluded.legal_person, statusexcluded.status conn.execute(sql, data) conn.commit() conn.close()股東和變更記錄按company_id外鍵關(guān)聯(lián)查詢時一次 join 就能拿到一家企業(yè)的完整畫像。5. 企查查爬蟲避坑指南驗證碼、字段缺失與登錄態(tài)失效的排查路線這一章是我和身邊同事反復(fù)踩過的坑按「現(xiàn)象 → 原因 → 解決」組織哪條命中了直接翻到對應(yīng)小節(jié)。5.1 坑一返回 200 卻解析不出 JSON響應(yīng)體是一段 HTML現(xiàn)象requests 請求后status_code是 200但resp.json()拋JSONDecodeError打印resp.text是一段帶html標簽的頁面里面經(jīng)常出現(xiàn)「訪問過于頻繁」「安全驗證」字樣。原因反爬層有意讓攔截頁也返回 200調(diào)用方只看狀態(tài)碼會誤以為成功實際上請求根本沒到達數(shù)據(jù)接口。這類偽裝響應(yīng)常伴隨 Cookie 失效或請求頭缺失。解決解析 JSON 之前先對響應(yīng)文本做特征判斷檢測到 HTML 標簽和驗證關(guān)鍵詞就直接中斷當前關(guān)鍵詞抓取并把狀態(tài)碼、響應(yīng)長度、文本摘要寫進日志方便事后定位。5.2 坑二滑塊驗證碼突然出現(xiàn)后續(xù)請求全軍覆沒現(xiàn)象連續(xù)跑三四十個請求后某個接口不再返回 JSON變成帶滑塊驗證碼的 HTML再繼續(xù)請求列表開始大量出現(xiàn)空數(shù)據(jù)。原因單位時間內(nèi)請求次數(shù)超過閾值或者請求頭的指紋組合不一致服務(wù)器把當前身份標記為高風險。解決立即停腳本等 510 分鐘再繼續(xù)不要硬沖。把固定 sleep 改成random.uniform(2.5, 4.5)所有請求保持一致的 User-Agent 和 Referer。如果驗證碼出現(xiàn)得越來越早說明間隔還不夠大繼續(xù)往上加。注意被反爬攔下后停下來是最有效的操作。連續(xù)刷新只會讓限制時間更長。5.3 坑三同一家公司兩次抓取字段不一致關(guān)鍵字段時有時無現(xiàn)象同一天對同一家公司抓兩次詳情第一次有注冊資本第二次該字段缺失手工刷新頁面數(shù)據(jù)又是完整的。原因詳情頁部分字段是異步加載的Playwright 等到了頁面主框架但某個具體字段的接口還在返回途中腳本已經(jīng)把 HTML 抓走了。解決等待條件從「選擇器出現(xiàn)」升級為「字段文本非空」。用page.wait_for_function判斷目標元素的innerText.length 0超時后記錄 warning不寫入空值。事后用「字段空值率」檢查哪些數(shù)據(jù)還需要補跑。5.4 坑四昨天能跑今天全是登錄墻Cookie 靜默過期現(xiàn)象前一天晚上還正常的爬蟲第二天啟動后所有詳情頁都跳轉(zhuǎn)到登錄首頁列表接口返回的也是登錄引導(dǎo)。原因cookie 過期或登錄態(tài)失效。企查查的登錄態(tài)有效期不長隔天運行是過期的高發(fā)時間點。解決爬蟲入口加一個登錄態(tài)探活函數(shù)先請求一個登錄后才可見的接口確認返回里包含登錄用戶標識再進入主任務(wù)。探活失敗就輸出明確的重新登錄提示而不是繼續(xù)跑無效請求。5.5 坑五字段對不上注冊資本帶了一堆前后綴符號現(xiàn)象CSV 里注冊資本一會兒是「100萬」一會兒是「100萬元人民幣」變更記錄里還帶著「從 50 萬元變更為 100 萬元」這類前后綴。原因同一個含義的數(shù)據(jù)在列表接口、詳情接口、變更記錄接口里用了不同展示格式頁面又做了一層格式化處理直接入庫自然不干凈。解決制定統(tǒng)一的字段清洗規(guī)則對貨幣字段做「數(shù)字 單位」拆分建立字段別名映射表把不同接口采集到的字段統(tǒng)一映射到標準字段名。清洗邏輯集中在一個函數(shù)里不要散落在各個解析代碼中。5.6 從現(xiàn)象定位根因的通用排查順序看到一個異常響應(yīng)時先別急著改代碼。按下面順序把現(xiàn)場信息湊齊再決定動哪里保存本次請求的完整響應(yīng)體和響應(yīng)頭而不是只看狀態(tài)碼判斷返回內(nèi)容是 JSON、偽裝成 200 的 HTML還是 302 跳轉(zhuǎn)用瀏覽器無痕模式手動執(zhí)行同一個操作確認是賬號問題還是代碼問題如果瀏覽器正常而腳本異常對比請求頭、Cookie、請求參數(shù)三個差異點。2025-01-01 03:12:44 ERROR page 5 fetch failed: JSONDecodeError, body starts with !DOCTYPE 2025-01-01 03:12:49 WARN keyword stopped, too many retries這條順序能覆蓋 80% 的爬蟲異常。剩下 20% 大概率是前端改版重新抓一次包就能解決。6. 把爬蟲工程化增量更新、限速裝飾器與合規(guī)紅線數(shù)據(jù)抓回來不是終點能持續(xù)更新才是。這一章補上工程化三件事增量更新、統(tǒng)一限速、合規(guī)邊界。6.1 增量抓取的三種策略與選擇策略適用場景實現(xiàn)成本注意點全量重抓數(shù)據(jù)量小、一次能抓完低請求量大反爬風險高時間窗增量有明確變更時間字段中依賴接口支持按時間篩選斷點續(xù)抓大規(guī)模抓取、需中斷恢復(fù)中維護單獨的進度表數(shù)據(jù)量在幾千條以內(nèi)全量重抓最省心數(shù)據(jù)量大了之后用進度表記錄每家企業(yè)的抓取時間每天只重抓最近有變更的企業(yè)其余時間平穩(wěn)輪詢。CREATE TABLE crawl_progress ( credit_code TEXT PRIMARY KEY, last_crawl_time TEXT, last_status TEXT );每次入庫前先查這張表決定新增還是更新這是把「爬蟲」變成「采集系統(tǒng)」的分水嶺。項目目錄可以這樣組織源碼和文檔一起維護qcc-crawler/ ├── config.py ├── storage_state.json ├── db.py ├── spiders/ │ ├── search.py │ └── detail.py └── docs/ ├── 接口字段說明.md └── 運行指南.md6.2 用裝飾器統(tǒng)一加限速與重試把限速邏輯抽成裝飾器讓每類請求都默認帶節(jié)流不用在函數(shù)體里到處寫 time.sleepimport time import functools import random def throttle(min_interval2.0): 給函數(shù)加最小調(diào)用間隔隨機抖動避免規(guī)整。 last_called [] def decorator(func): functools.wraps(func) def wrapper(*args, **kwargs): now time.time() if last_called: gap min_interval - (now - last_called[0]) if gap 0: time.sleep(gap random.uniform(0, 1)) last_called.clear() last_called.append(time.time()) return func(*args, **kwargs) return wrapper return decorator用法很簡單throttle(min_interval3.0) def fetch_company_detail(detail_url): ...這樣每次調(diào)用會自動間隔至少 3 秒又帶隨機擾動比把 sleep 寫在函數(shù)內(nèi)部更容易維護測試時還能臨時把間隔調(diào)成 0。6.3 合規(guī)紅線與工程習慣最后必須說清楚一件事技術(shù)能讓你爬到數(shù)據(jù)不代表你有權(quán)隨意使用這些數(shù)據(jù)。我自己的習慣是先確認是否有合法獲取這批數(shù)據(jù)的授權(quán)再用于學習或明確允許的內(nèi)部分析場景不用爬蟲惡意突破付費墻去抓本應(yīng)購買的字段也不把大批量數(shù)據(jù)打包公開傳播。采集頻率保持在合理范圍不給目標平臺造成明顯壓力這是基本的工程素養(yǎng)。最后說一個我自己的教訓有次為了趕進度把請求間隔壓到 0.5 秒結(jié)果抓了兩千條數(shù)據(jù)后整個入口被限制項目停滯了三天。從那以后「控制節(jié)奏」成了我寫采集代碼的默認習慣慢一點反而能跑得久一點。希望幫到你。本文還有配套的精品資源點擊獲取