做郵件自動化的朋友應(yīng)該都遇到過這個需求想把163郵箱收件箱里的郵件列表抓下來或者進一步提取正文、附件用于自動收驗證碼、整理訂閱郵件、做郵件監(jiān)控。我早期接到這個需求時第一反應(yīng)就是寫爬蟲但163郵箱網(wǎng)頁版的登錄和渲染遠比想象中麻煩試過 urllib、requests、selenium 三種方案后發(fā)現(xiàn)它們各有各的適用場景也存在各自的坑。這篇文章把三種方案的路數(shù)和取舍講清楚另外附上一個我后來才意識到的更優(yōu)解直接用 IMAP 協(xié)議讀郵件從根本上繞開網(wǎng)頁爬取的各種麻煩。如果你正準備用 Python 處理 163 郵箱或者對 Web 自動化的技術(shù)選型感興趣這篇總結(jié)應(yīng)該能幫你省下不少時間。我會直接貼出可用代碼和踩坑記錄也會說明哪些地方需要你根據(jù)當前頁面結(jié)構(gòu)做適配。1. 先把趨勢看明白爬郵箱網(wǎng)頁版的本質(zhì)是什么1.1 郵件系統(tǒng)的動態(tài)渲染趨勢純請求越來越難很多人的第一反應(yīng)是收件箱不就是個列表頁面嗎直接拿 requests 請求 HTML 再解析不就行了理論上確實是這樣但實際操作中你會發(fā)現(xiàn) 163 郵箱網(wǎng)頁版經(jīng)過了多次改版頁面大量使用異步加載。你請求回來的 HTML 里郵件列表的數(shù)據(jù)可能并不完整需要在瀏覽器中執(zhí)行 JavaScript 后才會渲染出來。這就引出了 Web 爬蟲里最核心的分水嶺目標頁面是服務(wù)端渲染還是客戶端渲染。早年的郵箱 Web 端會在 HTML 里直接輸出郵件表格requests 一把梭就能搞定現(xiàn)在的郵箱頁面普遍是前后端分離列表數(shù)據(jù)往往通過內(nèi)部的 JSON 接口異步返回或者用類似 iframe 內(nèi)嵌子頁面的方式組織。用 requests 抓回來的 HTML要么只是個骨架要么數(shù)據(jù)結(jié)構(gòu)復(fù)雜到你懷疑人生。所以在動手之前先花幾分鐘打開瀏覽器開發(fā)者工具看 Network 面板里頁面加載了哪些真實請求HTML 里到底包不包含郵件列表數(shù)據(jù)。這一步?jīng)Q定了你后面選擇哪條技術(shù)路線也避免你寫完一版 regex 解析后頁面一改就全線崩潰。1.2 三種 Web 方案的橫向?qū)Ρ萿rllib、requests、selenium 是處理 Web 自動化的三個典型層級urllib 是 Python 標準庫自帶的 HTTP 客戶端功能最底層幾乎所有細節(jié)都要手動處理比如 Cookie 存儲、請求頭拼接、重定向跟隨等。適合用來理解 HTTP 協(xié)議工作原理但寫業(yè)務(wù)代碼效率低。requests 是對 HTTP 的極佳封裝Session 自動管理 Cookie代碼簡潔直觀是目前爬蟲腳本的主力。適合接口調(diào)試、服務(wù)端渲染頁面的抓取以及配合內(nèi)部 JSON 接口使用。selenium 直接驅(qū)動真實瀏覽器能完整執(zhí)行頁面 JavaScript處理復(fù)雜交互幾乎可以模擬真人操作。缺點是重、慢且依賴 ChromeDriver 等瀏覽器驅(qū)動版本匹配。三者不是替代關(guān)系而是遞進關(guān)系。能不用瀏覽器就不用在瀏覽器里跑這是爬蟲工程師的基本素養(yǎng)因為瀏覽器的開銷和穩(wěn)定性問題會讓你在批量任務(wù)里吃盡苦頭。1.3 有一條更優(yōu)路徑IMAP 協(xié)議在繼續(xù)講三種 Web 方案之前我必須先劇透一個結(jié)論如果你只是想讀自己的郵件那 IMAP 協(xié)議才是更合理的方案。IMAP 是郵件客戶端與郵件服務(wù)器之間的標準協(xié)議163 郵箱本來就支持。你在網(wǎng)頁上看到的“收件箱”其實就是 IMAP 服務(wù)器上的 INBOX 文件夾。用 Python 標準庫 imaplib 就能直接連上去像操作本地隊列一樣拉取主題、發(fā)件人、時間、正文代碼量只有 Web 爬蟲的三分之一還不用擔心登錄加密、驗證碼、頁面改版之類的問題。我把 Web 方案放在前面講是因為很多人明確要求“用爬蟲”或者需要適配的不是郵件協(xié)議而是網(wǎng)頁端功能比如標記已讀、管理文件夾。但從選型角度你至少應(yīng)該知道 IMAP 這條路的存在具體對比我會在第 5 部分展開。2. 方案一urllib——最原始的 HTTP 模擬適合理解原理2.1 核心思路CookieJar 保持會話 POST 表單登錄urllib 做爬蟲的思路其實和 requests 類似只是所有事情都要自己動手。核心是兩件事第一用 http.cookiejar.CookieJar 構(gòu)造一個帶有 Cookie 管理能力的 opener因為登錄后服務(wù)器會通過 Set-Cookie 頭下發(fā)會話憑證后續(xù)請求必須攜帶這個 Cookie 才能被識別為登錄狀態(tài)第二向登錄接口提交表單數(shù)據(jù)模擬用戶在網(wǎng)頁上的登錄動作。163 郵箱的登錄頁面向來不是單純 POST 用戶名密碼就能過的中間還有加密和驗證碼環(huán)節(jié)。我在最初用 urllib 實戰(zhàn)時卡得最久的就是這一步。網(wǎng)易統(tǒng)一登錄頁會通過 JavaScript 對密碼做 RSA 加密后再提交密鑰由服務(wù)端動態(tài)下發(fā)。這意味著你光靠 urllib 發(fā)請求是不夠的還得先抓取頁面上的加密公鑰然后在 Python 里復(fù)刻一遍加密算法。這里我給一個折中思路可以先手動在瀏覽器登錄 163 郵箱然后把登錄后的 Cookie 字符串提取出來直接塞進 urllib 的請求頭里。這種方式對個人腳本來說完全夠用雖然登錄這一步還是手動的但之后抓取收件箱列表的過程是自動化的。2.2 urllib 實現(xiàn)收件箱列表解析的完整代碼我直接貼一段基于手動 Cookie 的 urllib 獲取收件箱列表的示例。這段代碼的核心是請求收件箱所在的實際 URL然后將返回的 HTML 通過正則或簡單的字符串處理提取郵件主題和發(fā)件人。import urllib.request import re # 手動從瀏覽器開發(fā)者工具中復(fù)制的 Cookie cookie_str your_cookie_here url https://mail.163.com/js6/s?funcmbox:listMessages headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36, Cookie: cookie_str, Referer: https://mail.163.com/ } req urllib.request.Request(url, headersheaders) resp urllib.request.urlopen(req, timeout10) html resp.read().decode(utf-8, errorsignore) # 假設(shè)郵件列表中的主題和發(fā)件人通過特定 class 或者屬性輸出 # 不同時期頁面結(jié)構(gòu)差異很大需要按實際 DOM 調(diào)整 subjects re.findall(rsubject:(.*?), html) senders re.findall(rsender:(.*?), html) for idx, (subject, sender) in enumerate(zip(subjects, senders), 1): print(f{idx}. 發(fā)件人: {sender} | 主題: {subject})實際運行時會發(fā)現(xiàn)一個問題163 郵箱網(wǎng)頁版的郵件列表數(shù)據(jù)非常喜歡用 JSON 格式內(nèi)嵌在script標簽里或者通過單獨的接口返回。用正則雖然能快速提取但只要你沒逃過字符轉(zhuǎn)義問題比如主題里出現(xiàn)引號解析就會出錯。所以我建議 urllib 方案只作為研究 HTTP 流向的教學(xué)工具真正用來做業(yè)務(wù)還是得靠 requests 更穩(wěn)定的解析手段。2.3 urllib 方案的真實局限性可能有人會覺得urllib 什么都能做為什么大家還是更愿意用 requests差別在于開發(fā)效率和代碼可讀性。urllib 處理 Cookie 要引入專門的 CookieJar重定向行為需要額外配置請求頭一個沒寫全就可能被服務(wù)器拒絕參數(shù)編碼也得手動調(diào)用 urllib.parse.urlencode。這些在 requests 里都是非常自然的操作。另外urllib 并不天然支持連接池和 Session 這種抽象每次請求都像第一次見面一樣重建連接性能和穩(wěn)定性都不理想。如果你的任務(wù)是循環(huán)翻頁抓取多個文件夾的郵件列表urllib 的代碼會寫得越來越長而 requests 只需要在同一 Session 上換 URL 就行。所以我對 urllib 的定位是用它寫一兩次腳本搞清楚 HTTP 請求構(gòu)成和 Cookie 機制就夠了真正干活不用它。3. 方案二requests——日常自動化任務(wù)的主力方案3.1 requests.Session 與 urllib 的差異requests 的設(shè)計思路和 urllib 最大的不同就是 Session 機制。Session 對象相當于一個持久化客戶端自動保存 Cookie自動處理請求頭如 Referer連接復(fù)用也有底層 urllib3 連接池頂著。對于需要登錄態(tài)的接口調(diào)用你只需要登錄一次后續(xù)請求全部走同一個 Session代碼干凈思維負擔小。在 163 郵箱這個場景里requests 的優(yōu)勢尤其明顯郵件列表數(shù)據(jù)如果是異步接口返回的你可以直接對接口發(fā)請求拿 JSON不用再浪費時間寫正則如果是服務(wù)端渲染的 HTML也可以配合 BeautifulSoup 做結(jié)構(gòu)化解析。相比 urllib解析準確度和維護性上升一個臺階。3.2 登錄難題網(wǎng)易的統(tǒng)一登錄和密碼加密雖然 requests 寫請求很爽但登錄 163 郵箱依然是繞不開的坎。網(wǎng)易統(tǒng)一登錄地址在 reg.163.com 域名下頁面會加載一段加密腳本。正常情況下提交登錄表單時密碼字段已經(jīng)變成 RSA 加密后的密文同時頁面還會校驗驗證碼常見的是滑塊驗證。直接拿明文密碼 POST 是過不了服務(wù)器的。有兩條路可以走第一種完整復(fù)刻登錄流程。先去頁面源碼里找到 RSA 公鑰然后使用 rsa 庫對密碼進行加密再模擬提交。這一步還要處理驗證碼問題?；瑝K驗證碼的自動化識別復(fù)雜且不穩(wěn)定我建議不要硬碰硬可以在檢測到驗證碼時手動完成一次之后 Cookie 就駐留在 Session 里了。第二種更務(wù)實仍然采用“瀏覽器手動登錄一次導(dǎo)出 Cookie 給 requests 用”的方式。這種方式適合抓取頻率不高、運行環(huán)境不固定的個人腳本省去所有加密和驗證碼的麻煩。把 Cookie 導(dǎo)入 requests 的姿勢很簡單我直接貼代碼。這種做法的核心就是構(gòu)造一個 requests.cookies.RequestsCookieJar 對象把鍵值對塞進去然后掛在 Session 上。import requests session requests.Session() session.headers.update({ User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 }) # 手動從瀏覽器復(fù)制 Cookie 字符串格式類似 name1value1; name2value2 cookie_str name1value1; name2value2 for item in cookie_str.split(;): key, value item.strip().split(, 1) session.cookies.set(key, value) resp session.get(https://mail.163.com/, timeout10) print(resp.status_code)這里有個細節(jié)163 郵箱頂部可能還有一個主域名跳轉(zhuǎn)第一次請求 163.com 后服務(wù)器會下發(fā)新的 Cookie所以如果你發(fā)現(xiàn)某些接口提示未登錄可能是跳轉(zhuǎn)過程中漏掉了中間域的 Cookie。最簡單的辦法是把所有域名下的 Cookie 都復(fù)制進 session包括 .163.com、.mail.163.com 等。3.3 用 requests 獲取收件箱列表的代碼和解析容錯登錄問題解決后抓取收件箱列表就簡單了。下面是我用 requests 加 BeautifulSoup 解析郵件列表的示例。注意頁面結(jié)構(gòu)會隨版本變化所以我在代碼里做了多級容錯先嘗試從 JSON 接口拿數(shù)據(jù)失敗再去解析 HTML。import requests from bs4 import BeautifulSoup import json def fetch_inbox(session, folder_url): resp session.get(folder_url, timeout10) resp.encoding utf-8 # 方式一如果能直接從接口拿到 JSON try: data resp.json() messages data.get(var, {}).get(list, []) for msg in messages: print(msg.get(subject), msg.get(sender)) return except ValueError: pass # 方式二解析 HTML soup BeautifulSoup(resp.text, html.parser) mail_items soup.select(.mailListItem) # 選擇器根據(jù)實際頁面調(diào)整 for item in mail_items: subject_node item.select_one(.subject) sender_node item.select_one(.sender) if subject_node: print(subject_node.get_text(stripTrue), |, sender_node.get_text(stripTrue))如果你是直接對內(nèi)部的異步接口發(fā)起請求那么拿到的基本都是 JSON 格式。163 郵箱的接口返回值通常經(jīng)過一層 JSONP 封裝可能在變量賦值里也可能在 callback 函數(shù)里。遇到這種情況可以用正則先抽取 JSON 對象再交給 json.loads 解析。import re match re.search(rvar listData (.*?);, resp.text, re.S) if match: data json.loads(match.group(1)) for msg in data.get(list, []): print(msg.get(subject), msg.get(from))這個方案跑起來很穩(wěn)缺點是接口地址和返回字段名可能改版。我建議在代碼里加上“字段不存在時的兜底邏輯”比如用 msg.get(subject) 而不是 msg[subject]避免單個字段異常導(dǎo)致整個腳本中斷。4. 方案三selenium——瀏覽器兜底動態(tài)渲染也不怕4.1 為什么還需要 selenium有些場景下requests 方案會走到死胡同頁面里某個關(guān)鍵數(shù)據(jù)怎么都找不到接口或者必須點擊某個按鈕后才出現(xiàn)文件夾列表又或者登錄驗證碼太復(fù)雜連人工介入都不方便。這時候 selenium 就是最后一層兜底。selenium 的價值在于它是真實瀏覽器環(huán)境用戶能看到操作過程調(diào)試直觀對反爬蟲的擾動更小。163 郵箱網(wǎng)頁版雖然絕大多數(shù)數(shù)據(jù)接口都能直接拿到 JSON但如果你對接口不熟悉最快驗證頁面行為的方式就是用 selenium 跑一遍。另外如果需要模擬用戶操作比如自動打開某封郵件、點擊加載更多、切換文件夾selenium 都是最直接的工具。代價也很明顯啟動瀏覽器大約消耗上百 M 內(nèi)存每次操作多一步等待跑批量任務(wù)時的速度遠比不上 requests。4.2 selenium 操作 163 收件箱的完整流程selenium 的關(guān)鍵是先解決瀏覽器驅(qū)動問題。我用 Chrome 舉例確保本機 Chrome 版本和 chromedriver 匹配否則啟動就會報 SessionNotCreatedException。驅(qū)動裝好以后核心步驟就是打開登錄頁、輸入賬號密碼、等待登錄成功、跳轉(zhuǎn)到收件箱、提取郵件列表元素。登錄 163 郵箱時有個比較煩人的點登錄框可能在 iframe 里。你在主頁面找不到輸入框需要先切換進 iframe 才能操作。這一步卡住過很多人我貼一段兼容 iframe 的登錄代碼。from selenium import webdriver from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC driver webdriver.Chrome() wait WebDriverWait(driver, 10) driver.get(https://mail.163.com/) # 郵箱登錄頁一般有 iframe需要切換 driver.switch_to.frame(login-frame) # frame id 或 name 按實際調(diào)整 # 等賬號輸入框出現(xiàn) user_input wait.until(EC.presence_of_element_located((By.NAME, email))) user_input.send_keys(your_username163.com) password_input driver.find_element(By.NAME, password) password_input.send_keys(your_password) # 登錄按鈕可能有多個選擇可見的那個 login_button driver.find_element(By.CSS_SELECTOR, a#dologin) login_button.click() # 等待登錄完成回到默認內(nèi)容 driver.switch_to.default_content() wait.until(EC.url_contains(mail.163.com)) print(登錄成功) # 進入收件箱 driver.get(https://mail.163.com/js6/main.jsp)登錄成功后提取郵件列表的核心操作是等待列表元素的出現(xiàn)。目標元素通常是包含主題、發(fā)件人、時間的行容器用 XPath 或 CSS 選擇器遍歷。注意郵箱頁面為了性能列表行可能部分復(fù)用元素數(shù)量和郵件數(shù)量不是嚴格的對應(yīng)關(guān)系需要配合滾動來加載更多內(nèi)容。4.3 WebDriverWait 顯式等待與 iframe/彈窗處理selenium 最大的坑就是“元素還沒渲染出來你去點它”。163 郵箱的網(wǎng)絡(luò)請求多尤其是第一次登錄后列表數(shù)據(jù)加載需要時間。如果代碼里全部用 time.sleep(5) 這種固定等待要么等太久要么網(wǎng)絡(luò)慢時依然超時。正確姿勢是顯式等待也就是 WebDriverWait 配合 expected_conditions。例如等待某個主題文本出現(xiàn)wait.until(EC.presence_of_element_located((By.XPATH, //div[classd]//span[classsubject])))還有 iframe 的嵌套問題。163 郵箱的郵件詳情頁也可能使用 iframe處理思路和登錄 iframe 一樣先 switch_to.frame 進入解析完再 switch_to.default_content 退出。如果你在頁面里怎么都找不到元素第一反應(yīng)應(yīng)該是檢查當前上下文是否還在正確 frame。彈窗方面163 郵箱偶爾會有引導(dǎo)浮層。如果你的腳本被浮層擋住點擊可以用 EC.element_to_be_clickable先等待元素可點擊再執(zhí)行 click?；蛘呤謩雨P(guān)閉浮層try: close_btn wait.until(EC.element_to_be_clickable((By.CSS_SELECTOR, .close-btn))) close_btn.click() except Exception: pass這種“能關(guān)就關(guān)關(guān)不掉忽略”的邏輯在自動化腳本里非常實用。4.4 divulli 組合定位與上傳文件等細節(jié)熱搜詞里有一個很典型的場景頁面元素不是原生下拉框而是由 div、ul、li 組合出來的自定義下拉框。這在 163 郵箱的文件夾切換里很常見。遇到這種控件selenium 的 Select 類是失效的你需要先點擊觸發(fā)下拉展開的 div再定位 ul 下的 li 項。# 假設(shè)點擊一個自定義下拉框然后選擇“收件箱” driver.find_element(By.CSS_SELECTOR, div.select-wrapper).click() time.sleep(1) driver.find_element(By.XPATH, //ul[classselect-options]/li[text()收件箱]).click()另外selenium 上傳本地文件也是個常見需求。很多人以為要先打開文件選擇對話框再用 pywin32 或 AutoIT 操作窗口但實際上 selenium 提供了最簡方式只要 input 標簽存在直接用 send_keys 傳入本地文件絕對路徑即可。file_input driver.find_element(By.CSS_SELECTOR, input[typefile]) file_input.send_keys(C:/path/to/attachment.txt)這些細節(jié)看似皮毛但在自動化測試或采集腳本里經(jīng)常是卡住進度的關(guān)鍵點。5. 繞開網(wǎng)頁爬取直接通過 IMAP 協(xié)議讀郵件5.1 IMAP 是什么為什么推薦如果你可以接受不使用“網(wǎng)頁爬蟲”的形式那么 IMAP 協(xié)議是最省心的路子。IMAP 是郵件客戶端與郵件服務(wù)器之間的標準協(xié)議你用的網(wǎng)易郵箱客戶端、手機自帶郵件 App 底層就是走 IMAP或 POP3。Python 標準庫 imaplib 已經(jīng)實現(xiàn)了客戶端邏輯你只需要處理字符串解析不用關(guān)心網(wǎng)頁結(jié)構(gòu)。IMAP 的這種“繞過瀏覽器操作”優(yōu)勢非常明顯第一不依賴頁面 DOM網(wǎng)易怎么改版都不影響你的流程第二請求量小通常一次 select 加一次 search 就能拿到整個收件箱的郵件 ID 列表再按需 fetch 內(nèi)容對服務(wù)器的壓力遠小于 Web 自動化第三協(xié)議穩(wěn)定接口幾乎不變代碼可以長期使用。說白了聽到“爬郵件”這個詞第一反應(yīng)不應(yīng)該是 selenium而是 IMAP。正如我在第 1 部分提到的那樣Web 爬蟲通常是在沒有郵件服務(wù)器權(quán)限或者需要操作特定網(wǎng)頁功能時才必須使用。5.2 163 郵箱開啟 IMAP 服務(wù)并獲取授權(quán)碼用 IMAP 連 163 郵箱有一個關(guān)鍵前提需要在網(wǎng)頁端設(shè)置里開啟 IMAP/SMTP 服務(wù)并且用“授權(quán)碼”而不是郵箱密碼登錄。這是 163 的安全策略目的是避免你的郵箱密碼直接暴露給第三方客戶端。具體操作路徑登錄 163 郵箱網(wǎng)頁版進入設(shè)置 - POP3/SMTP/IMAP開啟 IMAP 服務(wù)。開啟過程中會要求發(fā)送一條短信驗證驗證通過后會生成一個 16 位授權(quán)碼。這個授權(quán)碼只顯示一次保存好。后面 imaplib 登錄時“密碼”這個位置填的就是授權(quán)碼。這個點我當初踩過坑直接用郵箱密碼去連 imap.163.com一直報認證失敗后來才意識到需要開啟服務(wù)和授權(quán)碼。如果你發(fā)現(xiàn) login 一直失敗第一反應(yīng)就檢查這個。5.3 imaplib 獲取收件箱列表和郵件正文的完整示例下面的代碼用 imaplib 連接 163 郵箱的 IMAP 服務(wù)器選擇 INBOX搜索所有郵件然后拉取最近幾封郵件的發(fā)件人和主題。import imaplib import email from email.header import decode_header def decode_mime_header(raw): if raw is None: return decoded decode_header(raw) result [] for text, charset in decoded: if isinstance(text, bytes): charset charset or utf-8 result.append(text.decode(charset, errorsignore)) else: result.append(text) return .join(result) HOST imap.163.com APP_PASSWORD your_authorization_code # 不是郵箱密碼 conn imaplib.IMAP4_SSL(HOST, 993) conn.login(your_username163.com, APP_PASSWORD) conn.select(INBOX) # 搜索所有郵件返回的是郵件 ID 列表 status, data conn.search(None, ALL) mail_ids data[0].split() # 拉取最近 5 封 for mail_id in mail_ids[-5:]: status, msg_data conn.fetch(mail_id, (RFC822)) msg email.message_from_bytes(msg_data[0][1]) subject decode_mime_header(msg.get(Subject)) sender decode_mime_header(msg.get(From)) print(f主題: {subject} | 發(fā)件人: {sender}) conn.logout()這段代碼注意幾點郵件主題和發(fā)件人可能是 MIME 編碼過的比如 ?UTF-8?B?...? 這種所以要用 email.header.decode_header 解碼fetch 返回的報文是 bytes用 email.message_from_bytes 轉(zhuǎn)換搜索條件可以更精確比如用 UNSEEN 拿未讀郵件或用 SINCE 限定日期這樣每次拉取的就只是增量郵件效率更高。5.4 三種 Web 方案 vs IMAP 的選型對照表我根據(jù)自己的經(jīng)驗做了一張選型對照表方便你按實際需求挑方案方案登錄難度解析穩(wěn)定性請求速度是否推薦長期使用適用場景urllib難需手動加密/帶Cookie差頁面改版就崩中不推薦學(xué)習(xí)HTTP原理、救急requests中建議手動Cookie中依賴接口和結(jié)構(gòu)快視情況接口明確、結(jié)構(gòu)穩(wěn)定的抓取selenium中需處理iframe/滑塊高只要元素能找到就行慢不推薦長期批量頁面交互復(fù)雜、臨時兜底IMAP低開服務(wù)授權(quán)碼高協(xié)議穩(wěn)定非常快強烈推薦各類郵件讀取、監(jiān)控、歸檔可以看到IMAP 在絕大多數(shù)需要“讀郵件”的場景下都是最合適的。requests 適合調(diào)試接口和做輕量驗證selenium 則適合作為最后手段千萬別一上來就把項目壓在 selenium 上那會浪費大量時間在等待和元素抖動上。6. 常見問題與排查技巧實錄6.1 429 too many requests請求太頻繁被限流怎么處理如果你用 requests 或 urllib 頻繁請求 163 郵箱相關(guān)接口大概率會遇到 429 狀態(tài)碼錯誤信息通常類似exceeded retry limit, last status: 429 too many requests。這是服務(wù)器在做限流說明你在短時間內(nèi)請求量太大被識別為風險行為。解決辦法也很樸素給請求之間加隨機延時比如time.sleep(random.uniform(1, 3))。控制整體并發(fā)別用多線程或者多進程同時開太多 Session。實際項目中如果并發(fā)量超過 5我就建議改用 IMAP 協(xié)議因為 IMAP 一次連接可以連續(xù)處理大批郵件對服務(wù)端更友好。請求到達一定次數(shù)后強制休息 30 秒到 1 分鐘讓限流窗口過去。一定要設(shè)置重試機制遇到 429 時等待一段時間后重試不要無限重試。import requests import time def get_with_retry(session, url, max_retries3): for i in range(max_retries): resp session.get(url, timeout10) if resp.status_code 429: wait 2 ** i print(f收到 429等待 {wait} 秒后重試) time.sleep(wait) continue return resp raise RuntimeError(重試多次依然被限流)這種指數(shù)退避的策略非常管用既簡單又有效。實際跑的時候建議在日志里記錄每次請求的狀態(tài)碼和耗時方便事后分析。6.2 登錄失敗、驗證碼彈窗真實場景下的處理姿勢登錄失敗是 163 郵箱腳本最常見的痛點。如果你用 requests 模擬登錄提示密碼錯誤先檢查是不是加密環(huán)節(jié)出了問題。最簡單驗證方式抓取網(wǎng)頁版登錄成功后產(chǎn)生的 Cookie直接復(fù)用繞開加密邏輯而不是死磕 JS 逆向。如果登錄時彈出了滑塊驗證碼千萬不要想著完全自動化識別?；瑝K識別成本高、容易被風控而且對普通腳本來說根本沒有必要。我建議的方案是程序負責把瀏覽器窗口彈出來人手動拖一下滑塊然后腳本繼續(xù)跑。這種方式既穩(wěn)定又不會被封號。如果是 selenium 場景登錄成功后注意等待頁面跳轉(zhuǎn)完成不要立刻去點其他元素。163 郵箱登錄成功后會有一個短暫的過渡頁可能還會彈出“設(shè)置密保/綁定手機”之類的引導(dǎo)。如果你的腳本執(zhí)行太快很容易點到不該點的東西。6.3 元素定位不到、Cookie 失效、郵件變 base64 的排查清單元素定位不到第一先看頁面是否加載完用顯式等待代替 sleep第二看元素是否在 iframe 里需要先 switch_to.frame第三看是否為隱藏元素可能需要先點擊某個父元素觸發(fā)顯示。Cookie 失效Cookie 通常有幾個小時到幾天的有效期取決于你抓取的接口。如果腳本突然報未登錄重新手動登錄一次并更新 Cookie 即可。我習(xí)慣把 Cookie 保存到本地 JSON 文件每天開始運行前檢查是否過期。郵件正文顯示成 base64郵件正文可能使用了 base64 編碼傳輸。用 email 庫解析時需要判斷 payload 是否為 base64然后進行解碼。判斷方法是在頭部查看 Content-Transfer-Encoding 字段。IMAP 場景下處理這個比較簡單因為 email 庫自帶 decode 邏輯只要你用 email.message_from_bytes 解析就能自動處理大部分情況。還有一個我在實戰(zhàn)中發(fā)現(xiàn)的規(guī)律爬 163 郵箱網(wǎng)頁版時盡量選擇內(nèi)部接口而不是解析整張 HTML 頁面。內(nèi)部接口返回的數(shù)據(jù)結(jié)構(gòu)雖然初期需要摸索但一旦找到穩(wěn)定性遠超脆弱的 DOM 解析。最后再說點實在的我這個項目實際落地時最終選型是 IMAP 少量 requests。IMAP 負責郵件列表、正文、附件的拉取requests 只用來處理網(wǎng)頁端特有的操作比如某些設(shè)置頁的修改。selenium 只是前期確認頁面結(jié)構(gòu)時用過一次后來就再也沒有出現(xiàn)在正式腳本里。如果你在多個方案之間糾結(jié)我的建議很簡單先考慮郵件協(xié)議再考慮網(wǎng)頁接口最后才考慮瀏覽器自動化。這樣不僅能省力還能讓你的腳本活得更久。另外一個小技巧無論你用哪種方案請務(wù)必加日志和異常收集。郵件項目最容易出問題的地方是單個郵件解析失敗導(dǎo)致整個任務(wù)中斷。我在寫 imaplib 腳本時會對每一封郵件的解析做 try-except失敗時把郵件 ID 記錄下來繼續(xù)下一封最后統(tǒng)一查看失敗列表。這個習(xí)慣讓我少熬了很多夜推薦給你。