1. 為什么我選擇用Java啃下招聘網(wǎng)站這塊硬骨頭做數(shù)據(jù)分析和求職輔助工具的人繞不開的一個需求就是批量獲取招聘崗位信息。我最早用Python的requests加BeautifulSoup寫過一版跑得挺順但后來項目要集成到一個已有的Java后臺管理系統(tǒng)里團隊技術棧清一色Java再維護兩套語言成本太高索性把采集模塊整個用Java重寫了一遍。這篇文章就是那次重寫過程中沉淀下來的完整思路和踩坑記錄。招聘類網(wǎng)站的數(shù)據(jù)價值不用多說——崗位名稱、薪資范圍、學歷要求、經(jīng)驗門檻、技能標簽、公司規(guī)模、融資階段這些字段組合起來能做很多事分析某個技術方向的市場需求走勢、對比不同城市的薪資差異、給求職者做崗位匹配推薦、甚至幫培訓機構判斷該開什么課。但這類網(wǎng)站的數(shù)據(jù)不是白給的它們有反爬機制、有登錄墻、有動態(tài)渲染直接硬來基本是碰一鼻子灰。Java做網(wǎng)絡爬蟲的優(yōu)勢在于生態(tài)成熟、并發(fā)能力強、和業(yè)務系統(tǒng)集成方便。HttpClient負責發(fā)請求Jsoup負責解析HTMLJackson或Fastjson負責處理JSON再加上線程池做并發(fā)控制一套組合拳下來能覆蓋絕大多數(shù)采集場景。這篇文章適合有Java基礎、想動手做數(shù)據(jù)采集的開發(fā)者也適合已經(jīng)寫過簡單爬蟲但遇到反爬就卡住的人。我會從目標分析、請求構造、頁面解析、反爬應對、數(shù)據(jù)存儲這幾個維度把整個流程拆開講透代碼可以直接參考復現(xiàn)。需要提前說明的是本文討論的技術方案僅用于學習和技術研究目的實際使用時請遵守目標網(wǎng)站的服務條款和相關法律法規(guī)控制采集頻率不要對目標服務器造成壓力。技術本身是中性的怎么用取決于使用的人。2. 動手之前先把目標網(wǎng)站的請求鏈路摸清楚2.1 從瀏覽器開發(fā)者工具里挖出真正的數(shù)據(jù)接口很多人寫爬蟲的第一步是直接拿URL去請求HTML然后發(fā)現(xiàn)返回的內(nèi)容里根本沒有崗位數(shù)據(jù)。這是因為現(xiàn)代招聘網(wǎng)站基本都是前后端分離架構頁面骨架是靜態(tài)的崗位列表是JavaScript異步加載的。你右鍵查看網(wǎng)頁源代碼看到的可能只是一堆div容器真正的數(shù)據(jù)藏在XHR請求的響應里。正確的做法是打開瀏覽器的開發(fā)者工具切到Network面板篩選XHR或Fetch請求然后刷新頁面或滾動加載更多崗位。你會看到一系列接口請求響應格式通常是JSON。找到那個返回崗位列表的接口把它的請求URL、請求方法、請求頭、請求參數(shù)全部記錄下來。這一步是整個爬蟲的地基地基沒打?qū)竺嫒踪M。以我實際分析的某招聘平臺為例它的崗位搜索接口大致是這樣的結構一個GET請求URL里帶了query參數(shù)搜索關鍵詞、city參數(shù)城市編碼、page參數(shù)頁碼請求頭里必須帶User-Agent、Referer、Cookie等字段。響應是一個JSON對象里面有個data字段data里又有jobList數(shù)組每個元素包含jobName、salaryDesc、jobLabels、skills、experienceName等字段。這些字段名就是后面解析時的key。注意不同招聘平臺的接口結構差異很大有的用POST有的參數(shù)做了加密簽名有的需要登錄態(tài)。不要照搬某個平臺的方案一定要自己動手分析目標平臺的實際請求。2.2 請求頭里哪些字段是必須帶的分析接口的時候重點看請求頭。以下幾個字段通常缺一不可User-Agent標識客戶端類型不帶的話服務器可能直接返回403。建議用真實瀏覽器的UA字符串不要用Java默認的。Referer告訴服務器你是從哪個頁面發(fā)起的請求很多網(wǎng)站會校驗這個字段。Cookie維持會話狀態(tài)有些接口需要登錄后才能訪問Cookie里帶著身份憑證。Accept聲明期望的響應格式一般設為application/json或text/html。X-Requested-With部分網(wǎng)站用它判斷是不是Ajax請求設為XMLHttpRequest。我習慣在代碼里把這些請求頭集中管理用一個Map或者配置類存起來方便統(tǒng)一修改。下面是一個典型的請求頭配置示例MapString, String headers new HashMap(); headers.put(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); headers.put(Referer, https://example.com/job/search); headers.put(Accept, application/json, text/plain, */*); headers.put(Accept-Language, zh-CN,zh;q0.9); headers.put(Cookie, 你的Cookie字符串);2.3 分頁參數(shù)與城市編碼的對應關系招聘網(wǎng)站的搜索接口通常支持分頁page參數(shù)從1開始遞增。但要注意有些平臺對翻頁深度有限制比如只允許查看前30頁或前100條記錄。超過限制后要么返回空數(shù)據(jù)要么要求登錄。這個限制在做數(shù)據(jù)量評估時必須提前確認否則你寫了個循環(huán)跑了幾百頁結果后面全是重復數(shù)據(jù)或空響應。城市編碼是另一個容易踩坑的地方。招聘網(wǎng)站一般用內(nèi)部編碼表示城市比如北京可能是101010100上海是101020100這些編碼不會直接顯示在頁面上需要從接口請求參數(shù)里抓取或者從網(wǎng)站的城市列表接口獲取。我的做法是先手動搜索一次目標城市在Network面板里找到實際發(fā)出的請求把city參數(shù)的值記下來硬編碼到一個枚舉或配置文件中。public enum CityEnum { BEIJING(101010100, 北京), SHANGHAI(101020100, 上海), GUANGZHOU(101280100, 廣州), SHENZHEN(101280600, 深圳); private final String code; private final String name; CityEnum(String code, String name) { this.code code; this.name name; } public String getCode() { return code; } public String getName() { return name; } }3. 用HttpClient構建一個能扛住壓力的請求層3.1 連接池配置與超時設置的門道Java原生的HttpURLConnection用起來太原始Apache HttpClient是更成熟的選擇。但很多人直接new一個CloseableHttpClient就開跑沒配連接池沒設超時跑幾十個請求還行上千個請求就開始報連接超時或資源耗盡。正確的做法是用PoolingHttpClientConnectionManager管理連接池設置最大連接數(shù)和每個路由的最大連接數(shù)。超時方面要分三層設置connectTimeout建立TCP連接的超時、socketTimeout等待數(shù)據(jù)的超時、connectionRequestTimeout從連接池獲取連接的超時。這三個超時各有用途缺一不可。PoolingHttpClientConnectionManager connManager new PoolingHttpClientConnectionManager(); connManager.setMaxTotal(100); connManager.setDefaultMaxPerRoute(20); RequestConfig requestConfig RequestConfig.custom() .setConnectTimeout(5000) .setSocketTimeout(10000) .setConnectionRequestTimeout(3000) .build(); CloseableHttpClient httpClient HttpClients.custom() .setConnectionManager(connManager) .setDefaultRequestConfig(requestConfig) .build();實測下來connectTimeout設5秒、socketTimeout設10秒是比較穩(wěn)妥的區(qū)間。設太短容易誤殺正常請求設太長遇到死連接會拖慢整體進度。連接池的maxTotal根據(jù)你的并發(fā)線程數(shù)來定一般設成線程數(shù)的2到3倍就夠了。3.2 重試機制不是簡單加個循環(huán)網(wǎng)絡請求失敗是常態(tài)尤其是采集大量數(shù)據(jù)的時候。但重試不是無腦for循環(huán)重試三次就完事要區(qū)分哪些異常值得重試哪些重試也沒用。值得重試的情況連接超時、讀取超時、服務器返回502/503/504。不值得重試的情況403禁止訪問、404不存在、401未授權。前者是臨時性故障重試可能成功后者是權限或資源問題重試一百次結果一樣。HttpClient自帶了一個HttpRequestRetryHandler可以自定義重試邏輯HttpRequestRetryHandler retryHandler (exception, executionCount, context) - { if (executionCount 3) { return false; } if (exception instanceof ConnectTimeoutException) { return true; } if (exception instanceof SocketTimeoutException) { return true; } if (exception instanceof NoHttpResponseException) { return true; } return false; };把retryHandler設置到HttpClientBuilder上就能自動處理重試。但要注意重試之間最好加個短暫的等待避免瞬間密集重試觸發(fā)風控。3.3 代理IP的合理使用方式采集量大了之后單IP請求頻率過高會被限制。這時候需要引入代理IP池。代理的來源可以是商業(yè)代理服務也可以自建。使用方式是在請求配置里設置代理HttpHost proxy new HttpHost(代理IP, 端口); RequestConfig config RequestConfig.custom() .setProxy(proxy) .build();代理池的管理是個獨立話題核心思路是維護一個可用代理列表每次請求隨機選一個請求失敗則標記該代理不可用并剔除定期補充新代理。我一般會寫一個ProxyPool類內(nèi)部用一個阻塞隊列存代理后臺線程定期檢測代理可用性。提示代理IP的質(zhì)量參差不齊免費代理基本不能用商業(yè)代理也要先小批量測試。建議在正式采集前用一批代理跑一輪測試請求統(tǒng)計成功率和響應時間篩選出可用的再投入生產(chǎn)。4. 解析JSON響應與字段提取的實戰(zhàn)細節(jié)4.1 用Jackson做JSON反序列化的正確姿勢拿到接口返回的JSON字符串后下一步是解析出需要的字段。Jackson是Java生態(tài)里最常用的JSON庫性能好、功能全。基本用法是構建ObjectMapper然后readTree成JsonNode再按路徑逐層取值。ObjectMapper mapper new ObjectMapper(); JsonNode rootNode mapper.readTree(responseBody); JsonNode jobList rootNode.path(data).path(jobList); for (JsonNode job : jobList) { String jobName job.path(jobName).asText(); String salary job.path(salaryDesc).asText(); String experience job.path(experienceName).asText(); String degree job.path(degreeName).asText(); // 技能標簽是一個數(shù)組 ListString skills new ArrayList(); JsonNode skillsNode job.path(skills); if (skillsNode.isArray()) { for (JsonNode skill : skillsNode) { skills.add(skill.asText()); } } }用path()而不是get()的好處是當字段不存在時path()返回MissingNodeasText()返回空字符串不會拋NullPointerException。這在字段結構不穩(wěn)定的接口里特別重要。4.2 薪資字段的清洗與結構化招聘網(wǎng)站返回的薪資通常是一個字符串比如15-25K·13薪、20-40K、8-12K·14薪這種格式。直接存字符串沒法做數(shù)值分析需要拆解成最低薪資、最高薪資、薪資月數(shù)三個字段。public class SalaryParser { public static SalaryInfo parse(String salaryStr) { SalaryInfo info new SalaryInfo(); // 處理·13薪部分 int months 12; if (salaryStr.contains(·)) { String[] parts salaryStr.split(·); salaryStr parts[0]; String monthStr parts[1].replace(薪, ); months Integer.parseInt(monthStr); } // 處理15-25K部分 salaryStr salaryStr.replace(K, ).replace(k, ); if (salaryStr.contains(-)) { String[] range salaryStr.split(-); info.setMinSalary(Double.parseDouble(range[0])); info.setMaxSalary(Double.parseDouble(range[1])); } else { double single Double.parseDouble(salaryStr); info.setMinSalary(single); info.setMaxSalary(single); } info.setMonths(months); return info; } }實際數(shù)據(jù)里還會遇到面議、薪資面議這種非數(shù)值的情況解析時要單獨處理標記為未知或跳過。另外有些崗位標注的是日薪或時薪單位不是K這些都要在解析邏輯里做兼容。4.3 技能標簽的歸一化處理崗位的技能標簽是最有價值的數(shù)據(jù)之一但不同公司寫的標簽五花八門。同樣是Java開發(fā)有的寫Java有的寫JAVA有的寫java開發(fā)有的寫Java工程師。如果不做歸一化后續(xù)統(tǒng)計出來的結果會很亂。我的做法是維護一個映射表把常見變體映射到標準名稱MapString, String skillNormalizeMap new HashMap(); skillNormalizeMap.put(java, Java); skillNormalizeMap.put(JAVA, Java); skillNormalizeMap.put(spring, Spring); skillNormalizeMap.put(springboot, Spring Boot); skillNormalizeMap.put(spring boot, Spring Boot); skillNormalizeMap.put(mysql, MySQL); skillNormalizeMap.put(redis, Redis);歸一化之后再做詞頻統(tǒng)計結果就干凈多了。這個映射表需要根據(jù)實際采集到的數(shù)據(jù)不斷補充完善一開始不用追求大而全先覆蓋高頻技能即可。5. 反爬機制識別與應對策略的完整排查鏈路5.1 從403到驗證碼一次完整的踩坑記錄我第一次跑批量采集的時候前50個請求一切正常第51個開始全部返回403。當時第一反應是IP被封了換了代理繼續(xù)跑結果新IP跑了幾十個請求又被封。這說明不是IP的問題是請求特征被識別了。排查過程是這樣的先用單個請求手動測試確認請求頭和參數(shù)沒問題能正常返回數(shù)據(jù)。然后逐步增加請求頻率發(fā)現(xiàn)當QPS超過某個閾值時開始出現(xiàn)403。接著檢查響應內(nèi)容發(fā)現(xiàn)403頁面里有一段JavaScript代碼是網(wǎng)站的反爬腳本在檢測瀏覽器環(huán)境。再進一步分析發(fā)現(xiàn)網(wǎng)站還校驗了Cookie中的某些字段這些字段是頁面加載時由JavaScript生成的。這個排查鏈路告訴我們反爬不是單一維度的而是多維度組合的。頻率限制、請求頭校驗、Cookie校驗、JavaScript挑戰(zhàn)可能同時存在。應對策略也要分層頻率控制解決QPS問題請求頭偽裝解決特征識別問題Cookie維護解決會話校驗問題。5.2 請求頻率控制的工程化實現(xiàn)控制頻率最粗暴的方式是Thread.sleep()但這樣會阻塞線程浪費資源。更好的方式是用Guava的RateLimiter做令牌桶限流RateLimiter rateLimiter RateLimiter.create(2.0); // 每秒2個請求 public String fetchWithRateLimit(String url) { rateLimiter.acquire(); // 獲取令牌不夠就等待 return doFetch(url); }RateLimiter.create(2.0)表示每秒生成2個令牌acquire()會阻塞直到拿到令牌。這樣既能控制速率又不會像sleep那樣浪費固定時間。實際采集時建議把QPS控制在1到3之間具體看目標網(wǎng)站的容忍度。我一般會先小批量測試從QPS1開始逐步提高觀察什么時候開始出現(xiàn)異常響應然后把生產(chǎn)環(huán)境的QPS設成臨界值的一半。5.3 Cookie的獲取與維護策略需要登錄態(tài)的接口Cookie是繞不過去的。獲取Cookie有兩種方式一是手動登錄后從瀏覽器復制二是用程序模擬登錄流程自動獲取。手動方式簡單但Cookie會過期適合短期采集自動方式復雜但可持續(xù)適合長期運行。手動獲取的Cookie一般有效期幾小時到幾天過期后需要重新獲取。我的做法是把Cookie存在配置文件或數(shù)據(jù)庫里程序啟動時加載運行中檢測到401或403且確認是Cookie過期導致的就發(fā)通知提醒更新。自動登錄涉及模擬表單提交、處理驗證碼等環(huán)節(jié)復雜度較高。如果目標網(wǎng)站有驗證碼還需要接入打碼服務或做OCR識別。這部分展開講篇幅太大這里只提一個思路用Selenium或Playwright驅(qū)動真實瀏覽器完成登錄然后從瀏覽器上下文里提取Cookie再交給HttpClient使用。這樣既繞過了JavaScript加密的登錄參數(shù)又能拿到有效的會話憑證。5.4 遇到IP封禁時的應急處理即使做了頻率控制長時間采集還是可能觸發(fā)IP封禁。封禁的表現(xiàn)通常是所有請求返回403或者返回一個特殊的驗證頁面。這時候需要切換到備用IP。代理池的切換邏輯要做得平滑主IP被封后自動從池中取下一個可用IP繼續(xù)未完成的任務。同時記錄被封的IP和封禁時間過一段時間后再檢測是否解封。如果所有IP都被封了程序應該暫停并告警而不是繼續(xù)無效請求。public class ProxyManager { private BlockingQueueProxy availableProxies; private SetProxy bannedProxies; public Proxy getProxy() { Proxy proxy availableProxies.poll(); if (proxy null) { throw new RuntimeException(代理池已耗盡); } return proxy; } public void reportBanned(Proxy proxy) { bannedProxies.add(proxy); // 延遲后重新加入可用池 scheduledExecutor.schedule(() - { bannedProxies.remove(proxy); availableProxies.offer(proxy); }, 30, TimeUnit.MINUTES); } }6. 數(shù)據(jù)存儲方案選型與批量寫入優(yōu)化6.1 存文件還是存數(shù)據(jù)庫根據(jù)數(shù)據(jù)量做決定采集到的數(shù)據(jù)存哪里取決于數(shù)據(jù)量和使用場景。如果只是幾千條數(shù)據(jù)做一次性分析存CSV或JSON文件就夠了簡單直接。如果要持續(xù)采集、數(shù)據(jù)量到幾十萬上百萬條或者需要頻繁查詢和關聯(lián)分析那就得上數(shù)據(jù)庫。我的建議是采集階段先落地到文件JSON Lines格式每行一個JSON對象這樣即使程序崩潰也不會丟數(shù)據(jù)而且方便排查問題。采集完成后再批量導入數(shù)據(jù)庫做后續(xù)處理。JSON Lines的好處是追加寫入方便不需要讀取整個文件再修改。public void saveToFile(JobInfo job, String filePath) { try (BufferedWriter writer new BufferedWriter( new FileWriter(filePath, true))) { ObjectMapper mapper new ObjectMapper(); writer.write(mapper.writeValueAsString(job)); writer.newLine(); } catch (IOException e) { log.error(寫入文件失敗, e); } }6.2 MySQL表結構設計與索引優(yōu)化如果選擇MySQL存儲表結構設計要考慮查詢場景。崗位信息表的核心字段包括崗位ID唯一標識、崗位名稱、公司名稱、薪資范圍、城市、經(jīng)驗要求、學歷要求、技能標簽、采集時間。CREATE TABLE job_info ( id BIGINT AUTO_INCREMENT PRIMARY KEY, job_id VARCHAR(64) NOT NULL COMMENT 崗位唯一標識, job_name VARCHAR(128) NOT NULL COMMENT 崗位名稱, company_name VARCHAR(128) COMMENT 公司名稱, salary_min DECIMAL(10,2) COMMENT 最低薪資(K), salary_max DECIMAL(10,2) COMMENT 最高薪資(K), salary_months INT DEFAULT 12 COMMENT 薪資月數(shù), city VARCHAR(32) COMMENT 城市, experience VARCHAR(32) COMMENT 經(jīng)驗要求, degree VARCHAR(32) COMMENT 學歷要求, skills VARCHAR(512) COMMENT 技能標簽逗號分隔, crawl_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT 采集時間, UNIQUE KEY uk_job_id (job_id), INDEX idx_city (city), INDEX idx_job_name (job_name), INDEX idx_crawl_time (crawl_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;job_id上建唯一索引是為了去重重復采集時用INSERT IGNORE或ON DUPLICATE KEY UPDATE避免重復插入。city和job_name上建普通索引是為了加速按城市和崗位名稱的查詢。crawl_time索引用于按時間范圍篩選。6.3 批量插入的性能對比實測逐條INSERT在數(shù)據(jù)量大時性能很差每條都要走一次網(wǎng)絡往返和事務提交。批量插入能顯著提升吞吐量。我實測過三種方式的性能差異插入方式1萬條耗時說明逐條INSERT約45秒每條一個事務批量INSERT500條一批約3秒需設置rewriteBatchedStatementstrueLOAD DATA INFILE約1秒需要文件權限適合超大批量批量插入的關鍵是在JDBC URL里加上rewriteBatchedStatementstrue否則MySQL驅(qū)動不會真正合并SQL語句。代碼層面用addBatch()和executeBatch()String sql INSERT INTO job_info (job_id, job_name, company_name, salary_min, salary_max, city, experience, degree, skills) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?); try (PreparedStatement pstmt conn.prepareStatement(sql)) { conn.setAutoCommit(false); int count 0; for (JobInfo job : jobList) { pstmt.setString(1, job.getJobId()); pstmt.setString(2, job.getJobName()); // ... 設置其他參數(shù) pstmt.addBatch(); if (count % 500 0) { pstmt.executeBatch(); conn.commit(); } } pstmt.executeBatch(); conn.commit(); }注意批量插入時如果某條數(shù)據(jù)違反唯一約束整個批次可能失敗。用INSERT IGNORE可以跳過重復數(shù)據(jù)但會忽略其他錯誤。更穩(wěn)妥的做法是先用SELECT查出已存在的job_id過濾后再批量插入。7. 并發(fā)采集的線程模型與任務調(diào)度設計7.1 用線程池管理采集任務單線程采集太慢假設每個請求耗時500毫秒采集1萬條數(shù)據(jù)需要5000秒將近一個半小時。用10個線程并發(fā)理論上能壓縮到9分鐘左右。但線程不是越多越好太多線程會導致請求頻率過高觸發(fā)風控也會增加上下文切換開銷。我的經(jīng)驗是線程數(shù)控制在5到10之間配合RateLimiter做全局限流。線程池用ThreadPoolExecutor手動創(chuàng)建不要用Executors.newFixedThreadPool()因為后者用的是無界隊列任務積壓時可能OOM。ThreadPoolExecutor executor new ThreadPoolExecutor( 5, // 核心線程數(shù) 10, // 最大線程數(shù) 60L, TimeUnit.SECONDS, // 空閑線程存活時間 new LinkedBlockingQueue(1000), // 有界隊列 new ThreadFactoryBuilder().setNameFormat(crawler-%d).build(), new ThreadPoolExecutor.CallerRunsPolicy() // 拒絕策略 );CallerRunsPolicy表示隊列滿了之后由提交任務的線程自己執(zhí)行這樣能起到背壓作用防止任務無限堆積。7.2 分頁任務的拆分與結果聚合采集任務可以按頁碼拆分每個線程負責若干頁。比如總共100頁10個線程每個線程負責10頁。但要注意頁碼的分配要考慮請求間隔不能讓所有線程同時請求相鄰頁那樣請求特征太明顯。更好的方式是用一個共享的AtomicInteger作為頁碼計數(shù)器每個線程從計數(shù)器里取下一頁的頁碼取完就加一。這樣線程之間自然錯開不會重復采集同一頁。AtomicInteger pageCounter new AtomicInteger(1); int totalPages 100; Runnable task () - { while (true) { int page pageCounter.getAndIncrement(); if (page totalPages) { break; } try { ListJobInfo jobs fetchPage(page); saveJobs(jobs); } catch (Exception e) { log.error(采集第{}頁失敗, page, e); } } };結果聚合方面每個線程采集到的數(shù)據(jù)先存到線程本地的List里最后統(tǒng)一匯總。或者直接用線程安全的ConcurrentLinkedQueue收集避免鎖競爭。7.3 采集進度的監(jiān)控與斷點續(xù)傳長時間運行的采集任務需要進度監(jiān)控否則你不知道跑到哪了、還剩多少、有沒有卡住。簡單的做法是每完成一頁就打印日志記錄當前頁碼和已采集數(shù)量。更完善的做法是用AtomicLong統(tǒng)計成功和失敗的數(shù)量定期輸出統(tǒng)計信息。斷點續(xù)傳是另一個實用功能。程序意外中斷后重新啟動時能從上次中斷的頁碼繼續(xù)而不是從頭再來。實現(xiàn)方式是把已完成的頁碼記錄到文件或Redis里啟動時讀取并跳過這些頁碼。public class ProgressTracker { private SetInteger completedPages new HashSet(); private String progressFile progress.txt; public void load() { // 從文件加載已完成的頁碼 try (BufferedReader reader new BufferedReader(new FileReader(progressFile))) { String line; while ((line reader.readLine()) ! null) { completedPages.add(Integer.parseInt(line.trim())); } } catch (IOException e) { // 文件不存在則忽略 } } public void markCompleted(int page) { completedPages.add(page); // 追加寫入文件 try (BufferedWriter writer new BufferedWriter(new FileWriter(progressFile, true))) { writer.write(String.valueOf(page)); writer.newLine(); } catch (IOException e) { log.error(記錄進度失敗, e); } } public boolean isCompleted(int page) { return completedPages.contains(page); } }8. 采集過程中的幾個實用技巧與避坑經(jīng)驗8.1 請求間隔的隨機化處理固定間隔的請求模式很容易被識別。比如你每隔1秒發(fā)一個請求連續(xù)發(fā)100個這個模式太規(guī)律了風控系統(tǒng)一眼就能看出來。解決辦法是在基礎間隔上疊加隨機抖動public void randomDelay() { // 基礎間隔1000ms隨機浮動500ms long delay 1000 (long)(Math.random() * 500); try { Thread.sleep(delay); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } }這樣請求間隔在1000到1500毫秒之間隨機分布看起來更像人工操作。如果配合RateLimiter使用可以把RateLimiter的速率設得稍高一些然后用隨機延遲做二次控制。8.2 響應內(nèi)容的編碼問題中文網(wǎng)站經(jīng)常遇到編碼問題返回的JSON里中文變成亂碼。原因是服務器返回的Content-Type里聲明的編碼和實際編碼不一致或者HttpClient沒有正確識別。解決辦法是手動指定編碼String responseBody EntityUtils.toString(entity, StandardCharsets.UTF_8);如果UTF-8還是亂碼試試GBK。有些老網(wǎng)站用的是GB2312或GBK編碼。可以在響應頭里看Content-Type字段的charset值按那個來設置。8.3 日志記錄的分級與脫敏采集程序的日志要分級記錄INFO級別記錄每頁的采集結果WARN級別記錄重試和異常ERROR級別記錄失敗和需要人工介入的問題。日志里不要打印完整的Cookie和請求頭這些包含敏感信息泄露出去有安全風險。log.info(第{}頁采集完成獲取{}條數(shù)據(jù), page, jobs.size()); log.warn(第{}頁請求失敗準備第{}次重試, page, retryCount); log.error(第{}頁采集失敗已重試{}次, page, maxRetry);8.4 數(shù)據(jù)去重的時機與策略去重可以在三個環(huán)節(jié)做采集時去重、入庫時去重、分析時去重。采集時去重最省資源但需要維護一個已采集ID的集合內(nèi)存占用隨數(shù)據(jù)量增長。入庫時去重用數(shù)據(jù)庫唯一索引簡單可靠但會增加數(shù)據(jù)庫壓力。分析時去重最靈活但每次分析都要處理重復數(shù)據(jù)。我的建議是入庫時去重為主采集時去重為輔。采集時用一個布隆過濾器或Redis Set記錄已采集的job_id快速判斷是否重復入庫時用唯一索引兜底確保最終數(shù)據(jù)不重復。// 用Redis Set做采集時去重 public boolean isDuplicate(String jobId) { Boolean added redisTemplate.opsForSet().add(crawled_job_ids, jobId); return added null || !added; }8.5 異常情況的兜底處理采集過程中會遇到各種異常網(wǎng)絡超時、JSON解析失敗、字段缺失、數(shù)據(jù)庫連接斷開。每個環(huán)節(jié)都要有兜底處理不能讓一個異常導致整個程序崩潰。網(wǎng)絡異常用重試機制處理重試多次仍失敗則記錄到失敗隊列后續(xù)單獨處理。JSON解析失敗通常是接口結構變了這時候要記錄原始響應內(nèi)容方便排查。字段缺失用默認值填充不要拋異常。數(shù)據(jù)庫連接斷開用連接池自動重連或者捕獲異常后重新獲取連接。try { ListJobInfo jobs parseResponse(responseBody); saveToDatabase(jobs); } catch (JsonParseException e) { log.error(JSON解析失敗原始響應{}, responseBody, e); saveFailedRecord(responseBody); } catch (SQLException e) { log.error(數(shù)據(jù)庫寫入失敗, e); saveToFile(jobs); // 降級到文件存儲 }這套采集方案我在幾個內(nèi)部項目里跑過單機每天穩(wěn)定采集幾萬條數(shù)據(jù)沒有問題。核心不在于代碼寫得多復雜而在于對目標網(wǎng)站的理解夠不夠深、對異常情況的考慮夠不夠全。先把請求鏈路摸清楚再把反爬策略研究透最后把工程細節(jié)做扎實剩下的就是耐心跑數(shù)據(jù)了。