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