簡介該開源項(xiàng)目是一個(gè)基于Python的LinkedIn爬蟲工具核心功能是根據(jù)用戶輸入的公司名稱自動抓取該公司在LinkedIn上的員工公開資料覆蓋職位、地點(diǎn)、教育背景、工作經(jīng)歷等字段。主要面向需要批量獲取職業(yè)數(shù)據(jù)的研究人員、數(shù)據(jù)分析師、招聘人員與市場調(diào)研者也適合想學(xué)習(xí)網(wǎng)絡(luò)爬蟲開發(fā)的中高級Python開發(fā)者。壓縮包總共3個(gè)文件包括主爬蟲腳本、說明文檔和配置文件整體大小約5KB代碼結(jié)構(gòu)清晰便于快速閱讀、修改與二次部署。項(xiàng)目完整演示了從構(gòu)造搜索請求、解析HTML頁面、逐頁翻轉(zhuǎn)到訪問個(gè)人頁深度抓取的流程并涉及驗(yàn)證碼、IP限制、User-Agent檢測等反爬機(jī)制的應(yīng)對思路。同時(shí)用到了requests、BeautifulSoup、selenium、pandas等常用庫的搭配可幫助使用者理解真實(shí)爬蟲項(xiàng)目的落地方式。目前已有1601人瀏覽學(xué)習(xí)適合作為開源爬蟲研究與人才數(shù)據(jù)采集的參考模板但使用時(shí)務(wù)必遵循LinkedIn服務(wù)條款注意請求頻率與隱私合規(guī)。1. LinkedinSpider為什么“按公司抓員工”這件事值得自己動手拿到LinkedinSpider這個(gè)標(biāo)題時(shí)我第一反應(yīng)是這又是一個(gè)被各家“數(shù)據(jù)服務(wù)商”明碼標(biāo)價(jià)的接口活兒。企業(yè)做人才盤點(diǎn)、銷售找決策人、獵頭摸底目標(biāo)公司都會問同樣一個(gè)問題——這家公司有哪些關(guān)鍵崗位的人在領(lǐng)英上外包一條接口報(bào)價(jià)不低按需拉一次數(shù)據(jù)還可能涉及合規(guī)風(fēng)險(xiǎn)。自己用爬蟲按公司名去抓最大的價(jià)值不是省那點(diǎn)錢而是每次抓完數(shù)據(jù)都留在本地字段可以自己重新定義壞了可以重新跑。這個(gè)方案適合三類人需要定期做競品人才地圖的HRBP、做B2B銷售線索的開發(fā)人員、以及想給內(nèi)部系統(tǒng)接“公司-員工”關(guān)系數(shù)據(jù)的后端工程師。我默認(rèn)你的環(huán)境是Python 3.8以上能正常訪問領(lǐng)英網(wǎng)頁其余前置條件在下面幾章逐步補(bǔ)。這條路的可行性建立在領(lǐng)英當(dāng)前的產(chǎn)品機(jī)制上公司主頁下的People列表是公開可見的不需要互為好友搜索時(shí)能看到姓名、職位頭銜、所在地、公司、部分經(jīng)歷摘要。LinkedinSpider要做的就是用程序替代人肉搜索拿到公司名→解析出該公司主頁ID→基于公司維度做人員列表請求而不是用普通的關(guān)鍵詞空間搜索。整條鏈路拆開來看沒有哪個(gè)環(huán)節(jié)是不可逾越的真正的坑在登錄態(tài)、參數(shù)結(jié)構(gòu)和頻率限制的后半段。接下來我會按“機(jī)制—準(zhǔn)備—實(shí)現(xiàn)—合規(guī)—避坑—進(jìn)階”的順序把從零到能用的完整路徑講清楚。2. 先搞清楚抓取對象領(lǐng)英的“公司維度”數(shù)據(jù)是怎么暴露給爬蟲的2.1 公開可見不等于隨便抓登錄態(tài)與訪問邊界的真實(shí)關(guān)系領(lǐng)英站內(nèi)有兩套數(shù)據(jù)暴露邏輯。一套是面向搜索引擎和未登錄訪客的“公開檔案視圖”能看到姓名縮寫、公司名、職位名但看不到完整履歷和聯(lián)系方式另一套是登錄后看到的完整列表視圖People搜索結(jié)果頁會返回更完整的姓名和職位。LinkedinSpider這類工具能拿到可用的姓名當(dāng)前公司職位級別靠的就是登錄視圖。很多人誤以為不登錄也能抓全量實(shí)測結(jié)果是未登錄狀態(tài)下連續(xù)翻頁十幾次就會被重定向到登錄墻而且返回的JSON里名字是亂碼縮寫。我的做法是手動在瀏覽器登錄一次把Cookie導(dǎo)出來給腳本用。這里要區(qū)分兩個(gè)Cookie體系。一個(gè)是網(wǎng)頁端的li_at它是長期會話憑證有效期一般在30天左右另一個(gè)是JSESSIONID屬于短期會話標(biāo)識。爬蟲請求時(shí)推薦帶上完整的Cookie請求頭而不是只帶一兩個(gè)關(guān)鍵項(xiàng)。原因在于領(lǐng)英的風(fēng)控會校驗(yàn)Cookie的鍵值對完整性缺失任何一個(gè)常用鍵都有可能觸發(fā)安全校驗(yàn)頁。一個(gè)可復(fù)現(xiàn)的判斷方法是請求返回200但內(nèi)容是一段包含challenge字樣的HTML就說明Cookie攜帶不全或者已經(jīng)過期而不是IP被封。2.2 公司統(tǒng)一標(biāo)識Company URN是整條抓取鏈路的鑰匙按公司名搜索員工核心不是存公司名的字符串而是先找到領(lǐng)英內(nèi)部的Company URN。這個(gè)數(shù)值ID長這樣urn:li:organization:12345678中間那一串?dāng)?shù)字是這家公司在領(lǐng)英內(nèi)的唯一標(biāo)識。為什么一定要這個(gè)ID因?yàn)镻eople列表的查詢參數(shù)用的是currentCompany[ID]而不是公司名字符串用名稱去查系統(tǒng)會走一次模糊匹配返回結(jié)果不穩(wěn)定且漏掉改過名的公司。拿到Company URN有兩種常見做法第一種直接訪問公司主頁URL比如linkedin.com/company/公司英文名頁面源碼的og:title和meta標(biāo)簽里有organizationId第二種用領(lǐng)英的/voyager/api/organization/companies接口按名稱模糊搜索。第一種不用額外接口解析HTML即可但公司名要精確匹配URL里的slug第二種對拼寫容忍度高適合公司全稱和簡稱不一致的場景。我一般優(yōu)先用第二種因?yàn)樗跊]拿到主頁URL時(shí)也能反查而且返回的JSON里直接帶URN和公司主頁地址兩個(gè)字段。2.3 員工列表的數(shù)據(jù)來源不是頁面HTML而是接口JSON領(lǐng)英的People列表頁背后有獨(dú)立的接口端點(diǎn)。普通搜索和公司維度搜索走的是同一個(gè)/voyager/api/search/blended接口區(qū)別只在查詢參數(shù)。這個(gè)接口默認(rèn)返回混合內(nèi)容要在JSON節(jié)點(diǎn)elements里找到typeSEARCH_CARD且entityUrn以urn:li:people:開頭的條目每條里包含name姓名、headline職位頭銜、subOccupation次級職位、location所在地、publicIdentifier個(gè)人主頁尾號。比較關(guān)鍵的是接口返回的職位頭銜有些是自動規(guī)范化過的有些是用戶自填的字段名和含義在解析時(shí)最容易翻車后面避坑章會展開講。接口的翻頁邏輯和網(wǎng)頁端搜索框完全一致用page參數(shù)控制頁碼每頁默認(rèn)25條。filters里的currentCompany或company列表決定按公司過濾keywords留空即表示只看該公司全員。這個(gè)接口沒有公開的官方文檔可查參數(shù)名是通過瀏覽器開發(fā)者工具抓到的不同賬號、不同地區(qū)看到的參數(shù)結(jié)構(gòu)可能有差異所以下文實(shí)現(xiàn)的腳本里我會把請求參數(shù)集中放在一個(gè)配置區(qū)方便你對照自己的抓包結(jié)果做微調(diào)。3. 動手前的準(zhǔn)備清單Cookie獲取、環(huán)境安裝與目標(biāo)規(guī)則定義3.1 手動獲取登錄Cookie這一步無法全自動安全可控爬蟲腳本本身無法繞過登錄驗(yàn)證所以第一步用瀏覽器手動登錄領(lǐng)英然后從開發(fā)者工具里復(fù)制Cookie。操作路徑打開瀏覽器開發(fā)者工具F12→切到Network面板→刷新一次領(lǐng)英首頁→在請求列表里點(diǎn)任意一條領(lǐng)英自身的XHR請求→在Request Headers里找到cookie字段→完整復(fù)制值。不要只復(fù)制li_at整段復(fù)制最省事。粘到腳本里時(shí)注意Windows機(jī)換行有時(shí)會帶\r記得清洗掉。獲取Cookie時(shí)有三個(gè)檢查點(diǎn)第一確認(rèn)這個(gè)Cookie是從www.linkedin.com域下拿的別從第三方域名的頁面拿第二確認(rèn)賬號處于登錄態(tài)驗(yàn)證方式是復(fù)制Cookie后在Incognito窗口貼到領(lǐng)英頁面能直接進(jìn)入Feed第三Cookie有有效期腳本里做成從環(huán)境變量讀取而不是硬編碼便于過期后快速替換。# 安裝依賴只需要三個(gè)基礎(chǔ)庫 pip install requests beautifulsoup4# cookie_loader.py import os def load_cookie() - str: 從環(huán)境變量讀取 Cookie避免明文硬編碼進(jìn)代碼庫 用法: export LINKEDIN_COOKIEli_atxxx; JSESSIONIDyyy; ... cookie os.getenv(LINKEDIN_COOKIE) if not cookie: raise RuntimeError(請先設(shè)置環(huán)境變量 LINKEDIN_COOKIE) return cookie這段代碼做了兩件事一是規(guī)定Cookie只從環(huán)境變量進(jìn)入程序二是給出一個(gè)標(biāo)準(zhǔn)化讀取入口。參數(shù)說明環(huán)境變量名LINKEDIN_COOKIE可自定注意Shell里復(fù)制Cookie時(shí)若包含單引號需要在導(dǎo)出時(shí)改用雙引號包裹或用轉(zhuǎn)義符否則變量值會被截?cái)?。養(yǎng)成這個(gè)從環(huán)境變量讀取的習(xí)慣后續(xù)把腳本放到定時(shí)任務(wù)或容器里都不用改代碼。3.2 確定目標(biāo)公司名和抓取深度先列清單再定邊界抓取前把公司名的變體問題先解決。同一家公司在領(lǐng)英上可能出現(xiàn)多個(gè)主頁比如“某某科技中國”和“某某科技總部”是兩個(gè)獨(dú)立Company URN員工列表完全不重疊。LinkedinSpider按公司名抓取時(shí)如果只抓其中一個(gè)數(shù)據(jù)天然不全如果同名兩個(gè)都抓又會重復(fù)。所以出發(fā)前建一個(gè)“公司入圍表”字段包括公司中文全稱、領(lǐng)英主頁slug、Company URN如果能查到、抓取頁碼上限。抓取深度上我一般建議先跑一頁25條驗(yàn)證解析正確再放量到全量。全量翻頁不是越多越好——單次會話內(nèi)翻頁超過30頁觸發(fā)安全校驗(yàn)的概率指數(shù)上升。如果目標(biāo)公司員工總量超過750人建議拆成“按地區(qū)過濾”或“按職能關(guān)鍵詞過濾”分批拉取避免一個(gè)會話翻太多頁。這個(gè)上限沒有官方數(shù)字是團(tuán)隊(duì)在多次抓取中測試出的經(jīng)驗(yàn)值和賬號權(quán)重、操作習(xí)慣都有關(guān)系。3.3 請求頭偽裝與請求頻率從第一行代碼就做對請求頭直接決定第一印象。最低配置是User-Agent、Accept、Accept-Language三項(xiàng)其中User-Agent務(wù)必用當(dāng)前瀏覽器真實(shí)版本不要用Python默認(rèn)的python-requests標(biāo)識。Accept-Language建議設(shè)成zh-CN,zh;q0.9,en;q0.8和瀏覽器常規(guī)行為一致。Accept字段用text/html,application/xhtmlxml,...而不是application/json因?yàn)榈谝徊浇馕龉綰RN走得是HTML頁面。頻率控制方面兩個(gè)隨機(jī)暫停點(diǎn)一個(gè)是每次翻頁后的延遲我習(xí)慣設(shè)為4到9秒的隨機(jī)值另一個(gè)是每完成5頁后加一次20到35秒的長暫停。不要用固定延遲固定間隔在時(shí)間序列上的方差為零更容易被頻率分析識別。更穩(wěn)妥的做法是把每次請求的時(shí)間戳和延遲間隔寫進(jìn)本地日志方便事后回溯“哪一段時(shí)間連續(xù)請求觸發(fā)了限制”。這些參數(shù)都會體現(xiàn)在第四章的完整腳本里。4. 核心實(shí)現(xiàn)解析公司URN、循環(huán)抓員工列表、清洗落庫4.1 公司反查接口按公司名獲取Company URN公司反查這一步可以走搜索接口也可以走頁面解析這里給出更易復(fù)現(xiàn)的頁面解析方案。核心邏輯請求領(lǐng)英公司名的公開主頁URL從HTML的meta標(biāo)簽中讀出organizationId再拼出完整的urn:li:organization:{id}。這種方式不需要額外的搜索接口權(quán)限只要公司名的slug拼對就能出結(jié)果。如果公司名的slug帶特殊字符如、數(shù)字組合用urllib.parse.quote做一次編碼再拼接URL。# resolve_company.py import re import requests def resolve_company_urn(slug: str, cookie: str) - tuple[str, str]: 按公司slug解析Company URN和公司全稱 slug示例: acme-corp從公司主頁URL尾部復(fù)制 url fhttps://www.linkedin.com/company/{slug} headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36, Accept-Language: zh-CN,zh;q0.9,en;q0.8, Cookie: cookie, } resp requests.get(url, headersheaders, timeout15) if resp.status_code ! 200: raise RuntimeError(f公司主頁請求失敗: status{resp.status_code}) # organizationId 出現(xiàn)在meta content{數(shù)字} nameorganizationId里 m re.search(rnameorganizationId\scontent(\d), resp.text) if not m: raise RuntimeError(未找到organizationId可能是slug錯(cuò)誤或頁面結(jié)構(gòu)有變) org_id m.group(1) # 公司全稱從 og:title 拿后面做結(jié)果標(biāo)注用 t re.search(rpropertyog:title\scontent(.*?)\s*\|, resp.text) company_name t.group(1).strip() if t else slug return furn:li:organization:{org_id}, company_name這段代碼有一個(gè)設(shè)計(jì)細(xì)節(jié)正則只匹配nameorganizationId這種屬性順序?qū)嶋H頁面里content可能出現(xiàn)在name前面如果你的頁面結(jié)構(gòu)不同需要調(diào)換正則里的屬性順序。邏輯說明返回值是URN和公司全稱的二元組URN用于后續(xù)員工查詢參數(shù)公司全稱用于給抓取結(jié)果打標(biāo)簽。參數(shù)說明timeout設(shè)為15秒是兼顧慢網(wǎng)絡(luò)和快速失敗如果公司slug里包含中文或空格需要先做URL編碼。注意這里只處理了單次請求如果公司主頁是/company/acme-corp/people/結(jié)構(gòu)slug仍取路徑里company/與/之間那段不受結(jié)尾people影響。4.2 員工列表拉取參數(shù)組織、翻頁循環(huán)與JSON解析公司URN到手后接下來的核心請求是/voyager/api/search/blended接口。這個(gè)接口用GET請求就能返回JSON但參數(shù)必須嚴(yán)格按照web端抓包結(jié)構(gòu)來。接口地址、查詢參數(shù)模板和關(guān)鍵字段說明如下# fetch_employees.py import json import random import time import requests def build_people_params(company_urn: str, page: int) - dict: 構(gòu)造員工列表查詢參數(shù) company_urn: resolve_company_urn返回的完整URN page: 頁碼從1開始 return { keywords: , # 留空表示該公司全員不為空時(shí)做關(guān)鍵詞過濾 currentCompany: [company_urn], # 公司維度過濾可以是列表支持多公司合并 origin: GLOBAL_SEARCH_HEADER, # 來源標(biāo)識復(fù)制自web端影響返回字段完整度 page: page, # 從1開始超過30頁風(fēng)控概率升高 spellCorrectionEnabled: false, # 關(guān)閉拼寫糾正避免返回?zé)o關(guān)結(jié)果 } def fetch_employee_page(session: requests.Session, params: dict) - list[dict]: api https://www.linkedin.com/voyager/api/search/blended resp session.get(api, paramsparams, timeout20) if resp.status_code ! 200: # 200說明正常429限流403多半是Cookie失效或風(fēng)控校驗(yàn) raise RuntimeError(f員工列表請求失敗: status{resp.status_code}) try: data resp.json() except json.JSONDecodeError: # 返回的不是JSON時(shí)有可能命中了安全頁面整頁HTML會混進(jìn)來 raise RuntimeError(響應(yīng)不是JSON請檢查Cookie或是否觸發(fā)風(fēng)控) employees [] # elements節(jié)點(diǎn)里嵌套了多層的元素列表需要逐層遍歷 for element in data.get(elements, []): for item in element.get(elements, []): if not item.get(entityUrn, ).startswith(urn:li:people:): continue employees.append({ name: item.get(name, ), headline: item.get(headline, ), sub_occupation: item.get(subOccupation, {}).get(text, ), location: item.get(location, ), public_id: item.get(publicIdentifier, ), profile_url: fhttps://www.linkedin.com/in/{item.get(publicIdentifier, )}, }) return employees這段代碼的解析邏輯拆開看第一層elements對應(yīng)混合搜索結(jié)果里面每個(gè)element再展開一層elements才是單條人員卡片用entityUrn的前綴做類型過濾強(qiáng)制只保留人員條目把公司、職位、課程等混雜結(jié)果全部排除。參數(shù)說明currentCompany傳列表形式是官方web端的格式即使只查一家公司也要保持[urn:... ]傳純字符串會導(dǎo)致部分賬號請求直接返回空。origin參數(shù)的取值也很關(guān)鍵不同來源標(biāo)識影響返回載荷的字段完整度這里用GLOBAL_SEARCH_HEADER能穩(wěn)定拿到subOccupation換成SEARCH_BUTTON會少這個(gè)字段。如果拿不到location字段嘗試在headers里補(bǔ)上CSRF-Token和csrf-token兩個(gè)請求頭值從Cookie的JSESSIONID中提取。4.3 翻頁循環(huán)與數(shù)據(jù)落地輸出CSV同時(shí)保留原始JSON單頁解析沒問題后把循環(huán)邏輯串起來。翻頁不是簡單加一就完事需要判斷“是否有下一頁”判據(jù)是當(dāng)前頁返回條數(shù)是否為0或是否達(dá)到預(yù)設(shè)上限。同時(shí)每頁返回后要檢查data里是否有elements為空但請求成功的情況——這種情況通常是參數(shù)結(jié)構(gòu)有問題不是公司沒人盲目翻頁只會浪費(fèi)請求次數(shù)。循環(huán)中把原始JSON落盤一份方便后續(xù)重新清洗不必每次重抓。# run_spider.py import csv import json import os import random import time from fetch_employees import build_people_params, fetch_employee_page from resolve_company import resolve_company_urn from cookie_loader import load_cookie COOKIE load_cookie() COMPANY_SLUG acme-corp # 替換成目標(biāo)公司的slug MAX_PAGE 10 # 建議上限不要超過30 OUTPUT_CSV employees.csv RAW_DIR raw_json def main(): session requests.Session() session.headers.update({ User-Agent: Mozilla/5.0 ... AppleWebKit/537.36, Accept-Language: zh-CN,zh;q0.9,en;q0.8, Cookie: COOKIE, }) # 1. 解析URN company_urn, company_name resolve_company_urn(COMPANY_SLUG, COOKIE) print(f[info] 目標(biāo)公司: {company_name}, URN: {company_urn}) # 2. 翻頁抓取 os.makedirs(RAW_DIR, exist_okTrue) all_rows [] for page in range(1, MAX_PAGE 1): params build_people_params(company_urn, page) rows fetch_employee_page(session, params) if not rows: print(f[info] 第{page}頁無數(shù)據(jù)停止翻頁) break all_rows.extend(rows) # 原始JSON留檔字段后續(xù)解析時(shí)再做二次擴(kuò)展 with open(os.path.join(RAW_DIR, fpage_{page}.json), w, encodingutf-8) as f: json.dump(rows, f, ensure_asciiFalse, indent2) # 4-9秒隨機(jī)延遲每5頁加一次長暫停 time.sleep(random.uniform(4, 9)) if page % 5 0: time.sleep(random.uniform(20, 35)) # 3. 寫CSV with open(OUTPUT_CSV, w, newline, encodingutf-8-sig) as f: writer csv.DictWriter(f, fieldnames[ name, headline, sub_occupation, location, profile_url ]) writer.writeheader() writer.writerows(all_rows) print(f[done] 總計(jì)抓取 {len(all_rows)} 條已寫入 {OUTPUT_CSV}) if __name__ __main__: main()循環(huán)邏輯里有兩個(gè)容易被忽略的點(diǎn)第一是break條件如果第一頁就是空列表說明不是公司沒人而是參數(shù)或Cookie有問題直接停止比反復(fù)重試穩(wěn)妥第二是CSV的編碼這里用utf-8-sig而不是utf-8這樣生成的CSV用Excel打開時(shí)中文不會出現(xiàn)亂碼。參數(shù)說明MAX_PAGE設(shè)10只是默認(rèn)值按員工量調(diào)整如果公司就幾十個(gè)人跑到第二頁就自動停了RAW_DIR建議固定存放而不做清理原始JSON對比解析后CSV的字段排查問題時(shí)能快速定位是清洗邏輯還是來源問題。這個(gè)腳本已經(jīng)夠日常小批量使用接下來看合規(guī)和風(fēng)控邊界怎么拿捏。5. 抓取頻率、數(shù)據(jù)合規(guī)與賬號風(fēng)控LinkedinSpider能活多久取決于這幾點(diǎn)5.1 合規(guī)紅線爬取個(gè)人信息的合法邊界不在技術(shù)在用途LinkedinSpider抓的是個(gè)人姓名、職位、公司、所在城市這些字段在法律上屬于個(gè)人信息。技術(shù)能不能抓到是一回事抓下來怎么用是另一回事。如果抓來用于招聘人才尋訪在多數(shù)司法轄區(qū)屬于正當(dāng)商業(yè)目的但要控制數(shù)據(jù)量且不要抓聯(lián)系方式字段如果抓來用于營銷推送、批量電話銷售風(fēng)險(xiǎn)非常高。我在團(tuán)隊(duì)里定的紅線是不抓郵箱、不抓手機(jī)號、不抓個(gè)人主頁里的詳細(xì)經(jīng)歷文本只保留姓名、職位、公司這些“名片級”信息且數(shù)據(jù)定期清理。另外一點(diǎn)領(lǐng)英的用戶協(xié)議明確禁止未經(jīng)授權(quán)的數(shù)據(jù)抓取爬蟲賬號被發(fā)現(xiàn)后輕則封禁重則影響同IP段其他賬號。所以合規(guī)上要做的不是“不讓抓”而是“抓得少、抓得禮貌、只用于明確用途”。每批數(shù)據(jù)抓完后打上“抓取日期用途標(biāo)簽”兩個(gè)字段后續(xù)審計(jì)時(shí)能說清楚這批數(shù)據(jù)的來路和去處這是從業(yè)者最容易被忽略的一環(huán)。5.2 風(fēng)控觸發(fā)條件與頻率參數(shù)把速度控制在“像人在操作”第4章的代碼已經(jīng)做了隨機(jī)延遲和長暫停但還不夠。領(lǐng)英的風(fēng)控不只盯請求頻率還有三個(gè)維度每日總量、翻頁連續(xù)性、單號活躍時(shí)段。單賬號單日建議控制在300頁以內(nèi)翻頁時(shí)不要連續(xù)無間隔每翻一頁至少等夠4秒以上活躍時(shí)段盡量落在當(dāng)?shù)貢r(shí)間工作日白天凌晨批量操作最容易觸發(fā)校驗(yàn)。這里有一個(gè)常見的認(rèn)識誤區(qū)降低頻率就能無限安全不是。用戶的搜索行為和爬蟲的“機(jī)械翻頁”在行為序列上存在明顯差異——人翻到第二頁看到結(jié)果后往往會點(diǎn)開兩三個(gè)主頁看看爬蟲只會一路翻到底。因此我建議在翻頁到第3、7、11頁時(shí)隨機(jī)間隔地訪問一兩條員工主頁詳情只訪問不解析也行讓行為序列更接近真人。這個(gè)“訪問錨點(diǎn)”的成本極低但對風(fēng)控特征的弱化很有效屬于值得做的小動作。5.3 多賬號與代理的邊界不建議自己做優(yōu)先降低單號壓力談到大規(guī)模抓取很多人的第一想法是買一批賬號輪換。這個(gè)方向我不建議在小團(tuán)隊(duì)里做賬號注冊時(shí)的設(shè)備指紋、支付信息、使用習(xí)慣都會關(guān)聯(lián)一個(gè)號觸發(fā)校驗(yàn)會拖累一批號維護(hù)成本和翻車概率不成比例。更合理的做法是把單賬號的抓取量壓到安全區(qū)間配合“分時(shí)段分職能關(guān)鍵詞”的方式拉長整體周期。比如目標(biāo)公司800人不要一天拉完分成4天每天按“工程師”“銷售”“市場”三個(gè)關(guān)鍵詞各拉一小批。總量不變但單日行為曲線平緩得多。代理方面市面上的數(shù)據(jù)中心IP與領(lǐng)英普通用戶的IP屬性差異較大容易直接觸發(fā)登錄校驗(yàn)住宅IP成本又高。所以第4章的腳本里沒有寫代理支持就是為了讓你先跑通單賬號低頻模式確認(rèn)業(yè)務(wù)數(shù)據(jù)質(zhì)量后再討論要不要scale。不要一開始就上多號多代理多數(shù)早期項(xiàng)目的失敗原因不是規(guī)模不夠而是確定性不夠。6. LinkedinSpider常見問題排查6個(gè)實(shí)際踩過的坑與修復(fù)方法6.1 返回200但elements為空列表不是公司沒人是參數(shù)結(jié)構(gòu)不對有一類典型現(xiàn)象請求響應(yīng)是200JSON正常返回但elements里一個(gè)人員條目都沒有。一開始我以為是這家公司員工都沒寫領(lǐng)英后來檢查抓包數(shù)據(jù)發(fā)現(xiàn)是currentCompany傳成了字符串而不是列表。領(lǐng)英接口對這個(gè)參數(shù)的類型要求非常嚴(yán)格傳urn:li:organization:123456字符串大概率返回空結(jié)果傳[urn:li:organization:123456]單元素列表才正常。排查路徑先看響應(yīng)里有沒有error字段其次把參數(shù)原樣打印出來和瀏覽器抓包對比最后檢查origin參數(shù)是否被改成了不存在的值導(dǎo)致返回體結(jié)構(gòu)變化。6.2 JSONDecodeError頻繁出現(xiàn)命中HTML安全校驗(yàn)頁現(xiàn)象是連續(xù)抓到第15頁左右突然拋“響應(yīng)不是JSON”把返回內(nèi)容打印出來會發(fā)現(xiàn)是一整頁HTML里面有px-challenge字樣。原因分析請求頭里Cookie不完整或頻率超標(biāo)領(lǐng)英返回了安全校驗(yàn)頁而不是JSON接口響應(yīng)。解決的思路分兩步走第一步短繃帶——檢查Cookie里的li_at是否還在有效期內(nèi)重新導(dǎo)出并替換有條件就換一個(gè)網(wǎng)絡(luò)出口第二步治本——把MAX_PAGE降下來并開啟第5章說的“翻頁中途隨機(jī)訪問錨點(diǎn)”如果腳本連續(xù)兩次在第15頁附近翻車說明頻率還是太快把隨機(jī)延遲從4~9秒加到8~15秒再測。這類問題沒有一勞永逸的解法每次遇到都要重新調(diào)參。6.3 抓到的headline全是“xx公司高級工程師”但沒有具體職權(quán)還有一類常見現(xiàn)象是頭部字段和預(yù)期不同。比如公司是某商業(yè)銀行但員工headline多數(shù)是“Analyst”沒寫細(xì)分小組或者職位頭銜是系統(tǒng)自動填的“Associate”和本人自填的“MA Associate”不一致。原因在于領(lǐng)英的搜索接口返回的headline是用戶公開資料當(dāng)前值部分賬號的職業(yè)頭銜經(jīng)過系統(tǒng)規(guī)范化而subOccupation字段往往保存了更精確的自填內(nèi)容。解析時(shí)不要只取headline把subOccupation字段一并入庫后續(xù)在做職位分組統(tǒng)計(jì)時(shí)用subOccupation做補(bǔ)充。代碼里我已經(jīng)放了這段邏輯但注意subOccupation在前端是可選字段缺失時(shí)會是空字符串不是None。6.4 公司重名導(dǎo)致URN解析到錯(cuò)誤主頁按slug解析URN時(shí)一個(gè)經(jīng)典翻車場景是公司全稱不同但領(lǐng)英URL的slug完全相同。比如某地產(chǎn)公司和某咨詢公司同時(shí)用了“XX-partners”這個(gè)slug實(shí)際是兩家完全獨(dú)立的企業(yè)。resolve_company_urn函數(shù)只按URL拿ID不校驗(yàn)公司名匹配度所以解析后要用og:title的返回值對比一次——如果你在函數(shù)第25行那一步能拿到的公司全稱和預(yù)期不一致就要換slug。這個(gè)校驗(yàn)邏輯在第4章代碼里是做成打印提示的實(shí)際使用建議改成拋異常或記錄警告。另外注意領(lǐng)英上公司主頁有“關(guān)注數(shù)、員工數(shù)”的預(yù)估聚合頁這類頁面不是公司主頁格式更復(fù)雜不適用于這個(gè)解析流程。6.5 相同公司兩次抓取結(jié)果條數(shù)不一致員工列表本身就是動態(tài)的今天抓了150條一周后再抓只剩148條或變成155條看起來像是數(shù)據(jù)丟失或腳本bug。原因領(lǐng)英的員工列表反映的是員工在領(lǐng)英上填寫的“當(dāng)前公司”字段有人離職改了公司有人新入職補(bǔ)填了資料還有一部分人設(shè)了隱私不對搜索引擎暴露但登錄可見列表本身每天都在變。解決方式每次抓取把結(jié)果存成一個(gè)帶日期的目錄或文件名對比時(shí)按“快照”概念處理不要期望兩次結(jié)果完全一致。抓“趨勢”要用后續(xù)第7章的增量更新方案不是重跑全量再diff。6.6 中文公司名編碼報(bào)錯(cuò)或URL拼接失敗公司名是中文時(shí)拼slug會遇到一個(gè)問題領(lǐng)英公司URL的slug一般是最初提交公司主頁時(shí)填寫的英文名稱生成的中文本名并不直接存在URL里。直接拿中文去拼URL必然404。解決方法是先用領(lǐng)英搜索框反查請求/voyager/api/search/blended帶keywords中文公司名從返回里過濾typeCOMPANY的條目拿slug再走resolve流程。這樣要兩次請求但穩(wěn)定。注意中文名搜索接口返回的首頁推薦公司可能有多頁建議取第一條按粉絲數(shù)排序的其余公司條目標(biāo)記為候選公司在CSV里輸出一行一個(gè)候選供人工確認(rèn)。7. 進(jìn)階用法從“按公司名抓全量”到“按職位關(guān)鍵詞過濾增量更新”7.1 給員工列表加職位關(guān)鍵詞過濾把抓取目標(biāo)從“全員”變成“關(guān)鍵角色”前文的抓取是公司維度全量拉取。實(shí)際業(yè)務(wù)中需求往往是“抓這家公司的Java工程師”或“華東區(qū)銷售負(fù)責(zé)人”。領(lǐng)英接口支持在build_people_params里同時(shí)傳currentCompany和keywords兩者的關(guān)系是AND即“該公司含關(guān)鍵詞”的人。關(guān)鍵詞匹配作用于職位頭銜和工作經(jīng)歷相當(dāng)于一次縮小范圍的預(yù)篩選減少翻頁量。def build_filtered_params(company_urn: str, page: int, keyword: str) - dict: params build_people_params(company_urn, page) params[keywords] keyword # 增加崗位相關(guān)過濾減少不相關(guān)結(jié)果 params[filters] {role: [ENGINEERING, PRODUCT]} return params參數(shù)說明filters里支持傳入role職位職能類、seniority資歷級別、location地域等維度取值枚舉需要從接口返回的facet字段里讀取同一份響應(yīng)里會附帶可用的過濾值列表。這個(gè)擴(kuò)展的代價(jià)是要額外讀取facet做映射首次使用建議先跑一次不帶filters的接口把返回的facet打印出來對照著填不要憑文檔硬拼。7.2 增量更新用“上次抓取時(shí)間”避免每天重復(fù)全量拉取重跑全量在頻率上是浪費(fèi)的改進(jìn)思路是維護(hù)一個(gè)“公司員工快照表”按publicIdentifier做主鍵每次抓取只更新已有員工的headline變化和發(fā)現(xiàn)新員工不重復(fù)下載未變化的舊數(shù)據(jù)。這樣單日翻頁量可以大幅壓降同時(shí)也讓風(fēng)控更安全。實(shí)現(xiàn)思路抓取后的數(shù)據(jù)統(tǒng)一進(jìn)SQLite先按publicIdentifier的集合求差集只抓新增部分舊數(shù)據(jù)每30天才重刷一次。# incremental.py import sqlite3 def init_db(db_path: str) - None: conn sqlite3.connect(db_path) conn.execute( CREATE TABLE IF NOT EXISTS employee_snapshot ( public_id TEXT PRIMARY KEY, name TEXT, headline TEXT, location TEXT, profile_url TEXT, company_urn TEXT, first_seen_at TEXT DEFAULT CURRENT_TIMESTAMP, last_updated_at TEXT DEFAULT CURRENT_TIMESTAMP ) ) conn.commit() conn.close() def upsert_employees(db_path: str, employees: list[dict], company_urn: str) - int: conn sqlite3.connect(db_path) updated 0 for emp in employees: cur conn.execute( SELECT 1 FROM employee_snapshot WHERE public_id ?, (emp[public_id],) ) if cur.fetchone(): conn.execute( UPDATE employee_snapshot SET headline ?, location ?, last_updated_at CURRENT_TIMESTAMP WHERE public_id ? , (emp[headline], emp[location], emp[public_id])) else: conn.execute( INSERT INTO employee_snapshot (public_id, name, headline, location, profile_url, company_urn) VALUES (?, ?, ?, ?, ?, ?) , (emp[public_id], emp[name], emp[headline], emp[location], emp[profile_url], company_urn)) updated 1 conn.commit() conn.close() return updated邏輯說明public_id對應(yīng)個(gè)人主頁URL尾號是穩(wěn)定的唯一標(biāo)識主鍵沖突時(shí)走更新分支不沖突時(shí)走插入分支天然完成增量合并。first_seen_at和last_updated_at兩個(gè)時(shí)間戳是給后續(xù)“員工離職監(jiān)測”用的——當(dāng)某條數(shù)據(jù)超過30天沒刷新且查詢接口搜不到該public_id時(shí)標(biāo)記為“可能已離職”這只是推斷值不能當(dāng)成事實(shí)寫入對外報(bào)告。參數(shù)說明company_urn存了來源公司處理跨公司兼職場景時(shí)就靠這個(gè)字段區(qū)分歸屬。7.3 驗(yàn)證數(shù)據(jù)質(zhì)量抽檢率與字段完整性腳本跑完后別急著交付至少做三項(xiàng)抽檢第一用抓取結(jié)果里的profile_url隨機(jī)抽3%直接人工打開確認(rèn)姓名和當(dāng)前公司和結(jié)果一致第二檢查headline字段中文占比與預(yù)期相符比如某中國區(qū)公司如果有80%以上的headline顯示英文有可能是公司主頁選錯(cuò)了多語言公司主頁常見第三檢查location字段是否為空的比例是否異常正常應(yīng)低于15%如果空值過多說明接口返回的字段有缺失可能需要補(bǔ)請求subOccupation或改用搜索接口從elements外層取位置信息。這三步大概花十幾分鐘但能攔住大部分“數(shù)據(jù)看似正常但字段錯(cuò)位”的返工。7.4 從抓取到內(nèi)部系統(tǒng)數(shù)據(jù)格式規(guī)范化與字段映射CSV落地后進(jìn)入企業(yè)系統(tǒng)前通常要做字段的標(biāo)準(zhǔn)化映射。比如headline里含有“資深”或“Sr.”的映射為“資深/高級”級別location按城市名映射到區(qū)域profile_url統(tǒng)一轉(zhuǎn)成內(nèi)部系統(tǒng)的聯(lián)系人鏈接。這些映射規(guī)則不是技術(shù)難點(diǎn)但直接影響下游使用方的體驗(yàn)。我習(xí)慣在腳本的最后加一個(gè)normalize.py模塊專門做字段映射把“抓取邏輯”和“清洗邏輯”分開維護(hù)——爬蟲結(jié)構(gòu)變了只改fetch部分業(yè)務(wù)字段規(guī)則變了只改normalize部分互不干擾。這套抓取方案的現(xiàn)實(shí)收獲是某個(gè)模擬項(xiàng)目里我花了兩個(gè)晚上把腳本改成公司關(guān)鍵詞過濾結(jié)果整體翻頁量降了70%數(shù)據(jù)準(zhǔn)確率提升到可用水平。把本文章代碼保存為三個(gè)文件依次執(zhí)行第一周小批量參數(shù)調(diào)順第二周就可以給業(yè)務(wù)方交付第一版人才地圖。如果你在操作時(shí)碰到頁數(shù)一多就校驗(yàn)報(bào)錯(cuò)別急著懷疑IP和代理先把延遲參數(shù)調(diào)大、把錨點(diǎn)請求加上——很多時(shí)候問題不在“速度不夠慢”而在“行為不夠像人”。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取