與避坑指南)
簡介基于Selenium的12306自動搶票腳本全套資料面向計算機相關專業(yè)學生、教師及企業(yè)開發(fā)者可解決購票腳本設計、自動化測試與實戰(zhàn)演練等需求。壓縮包共18個文件涵蓋7個Python源碼、5個XML工程配置、3個文本說明及YAML環(huán)境配置等其中py文件實現(xiàn)核心搶票邏輯、車站信息獲取、參數配置與郵件提醒等模塊yaml與xml用于配置和工程管理md與txt提供詳細使用文檔。資源已通過運行測試并獲導師認可、答辯評審95分適合用于畢業(yè)設計、課程設計、項目初期演示或Selenium進階學習。目前已有129人學習下載配套詳細文檔能幫助讀者快速理解自動化購票流程包括余票查詢、提交訂單等關鍵環(huán)節(jié)目錄結構清晰便于按模塊閱讀和二次開發(fā)。1. 基于Selenium的12306自動搶票腳本它不是外掛是替你盯著余票的瀏覽器每年春運一到朋友圈里就會冒出一堆“代搶票”的鏈接還總有人問“為什么別人手速那么快明明顯示有票一點進去就沒了”其實問題不在于手速而在于你盯著頁面、刷新、對比車次、再點預定、再選乘客的速度?；赟elenium的12306自動搶票腳本做的事情就是把這套“人肉操作”變成瀏覽器自動執(zhí)行定時刷新余票、按你預設的車次和坐席過濾、出現(xiàn)目標車票就點預定、填好乘客、提交訂單。它不是破解12306的接口也沒有繞過任何風控邏輯只是在用程序控制一個真實瀏覽器模擬一個始終在線且不提手酸的“真人”。所以它最大的價值不是“搶”而是讓腳本幫你把“盯”這件事做到一天不眨眼。適合通勤票、假期票、幫家里老人搶票也適合想拿自動化框架練手的開發(fā)者前提是你愿意把登錄、驗證碼這些環(huán)節(jié)留出人工兜底。2. 為什么選Selenium做搶票選型理由與最少可運行環(huán)境在動手之前先把選型這事說透。很多人看到“自動搶票腳本”第一反應是抓12306的后臺接口直接POST提交訂單。這條路對開發(fā)者的誘惑很大但12306的核心下單接口做過簽名校驗關鍵參數由前端加密生成抓包抓到的明文請求根本沒法直接復用。更現(xiàn)實的問題是接口方案一旦失效你面對的不是改個參數的事而是要把整套簽名算法逆向出來維護成本極高。Selenium走的是另一條路它不碰接口而是驅動瀏覽器按真實用戶的路徑操作頁面。12306的風控再嚴也不可能把正常打開網頁的人全攔住對吧這就是Selenium做自動化搶票的核心優(yōu)勢——黑匣子最小化。2.1 Selenium憑什么能搶票瀏覽器自動化與真人操作的邊界Selenium是一個WebDriver自動化測試框架常見用法是讓測試腳本去驅動Chrome、Firefox這類瀏覽器模擬點擊、輸入、滾動、等待這些行為。它最早是給測試人員做回歸測試用的后來被廣泛用于自動化運營、數據采集自然也就有人拿它來做搶票腳本。它的工作模式是“客戶端庫 瀏覽器驅動”你在Python里調用selenium包它通過ChromeDriver這類驅動件把指令翻譯成瀏覽器能理解的動作再由瀏覽器真實地渲染頁面、執(zhí)行JavaScript。這種模式的邊界在哪兒第一Selenium不是萬能的它要求目標頁面在DOM層面穩(wěn)定如果12306改版把按鈕的class和id全換掉腳本就要跟著改選擇器。第二它天然會留下自動化特征比如webdriver屬性、奇怪的瀏覽器指紋風控系統(tǒng)可以識別它成年人要有點自覺任何針對Web的自動化工具都存在被平臺識別和管控的可能這不是腳本本身能完全藏住的。第三它處理不了“頁面沒變但數據已變”的情況余票查詢這種場景還是得靠輪詢。所以真實項目里Selenium做的是“最后一百米”——把人到按鈕的距離縮短為程序到按鈕的距離而不是發(fā)明一把萬能鑰匙。2.2 搭環(huán)境Python虛擬環(huán)境Selenium瀏覽器驅動的最小步驟環(huán)境搭建不復雜但順序別搞錯。先建一個干凈的Python虛擬環(huán)境然后在里面安裝selenium包最后下載與瀏覽器版本匹配的驅動。很多人一上來直接全局裝selenium結果驅動版本和瀏覽器對不上報一堆SessionNotCreatedException這種翻車完全可以避免。按下面這套來操作# 1. 創(chuàng)建并激活虛擬環(huán)境Python 3.9 均可 python -m venv venv_12306 source venv_12306/bin/activate # Windows 下執(zhí)行 venv_12306\Scripts\activate # 2. 安裝 selenium pip install selenium # 3. 檢查瀏覽器版本 google-chrome --version # Windows 下在 Chrome 地址欄輸入 chrome://version參數說明虛擬環(huán)境解決的是包沖突問題你機器上可能已經裝了舊版selenium或者requests搶票腳本對依賴版本比較敏感隔離是必須的。安裝selenium不需要指定版本但建議裝到4.x以上4.x的API比3.x干凈很多不再需要手動聲明executable_path。檢查瀏覽器版本這一步別省驅動要和瀏覽器大版本一致比如Chrome 120就配ChromeDriver 120.x小版本可以略有偏差大版本不能錯。接下來是驅動下載。Selenium 4.x提供了Selenium Manager會自動去官方源拉驅動但國內網絡條件下經常超時建議還是手動下載。下載后把驅動文件放到一個固定目錄比如tools/chromedriver然后在代碼里指定路徑。2.3 最小啟動腳本先跑通一個能打開12306的瀏覽器環(huán)境裝好后不要急著寫業(yè)務邏輯先跑一個最小啟動腳本驗證整個鏈路是通的。這一步能過濾掉九成環(huán)境問題。代碼只做一件事打開一個帶用戶數據目錄的Chrome窗口訪問12306的首頁然后停在那里等你按回車。為什么要帶用戶數據目錄因為搶票場景需要保持登錄狀態(tài)你手動登錄一次后Cookie存在這個目錄里下次腳本啟動還能繼續(xù)用不然每次都要重新掃碼登錄。from selenium import webdriver options webdriver.ChromeOptions() # 使用自定義用戶數據目錄保存登錄態(tài) options.add_argument(--user-data-dir/path/to/chrome_user_data) # 關閉正在受到自動軟件控制提示條 options.add_experimental_option(excludeSwitches, [enable-automation]) # 可選去掉 webdriver 特征警惕這屬于反檢測實踐需自行評估風險 options.add_argument(--disable-blink-featuresAutomationControlled) driver webdriver.Chrome(optionsoptions) driver.get(https://www.12306.cn/index/) print(瀏覽器已打開請手動確認是否進入官網) input(按回車鍵退出...) driver.quit()邏輯說明代碼先給Chrome配置一組選項再用這些選項生成driver實例打開12306首頁最后用input()把進程掛住好讓你肉眼看一眼瀏覽器是不是真的正常加載了頁面。--user-data-dir這個參數是整套腳本的地基登錄態(tài)能不能跨腳本保持就看它配沒配對。excludeSwitches和--disable-blink-features是控制自動化提示的常用做法但你要清楚這類參數只是降低存在感不能保證絕對不被平臺識別——后面避坑章節(jié)我會再細說。參數說明/path/to/chrome_user_data要替換成你的絕對路徑注意Windows路徑里的反斜杠要寫成雙反斜杠或使用r...原始字符串。--user-data-dir指向的是一個空目錄也沒關系Chrome會自動初始化。這里有個常見坑如果你之前已經開著一個Chrome進程再用同一個用戶目錄啟動腳本會直接報“user data directory is already in use”腳本啟動前先關掉其他Chrome窗口。跑通這一步你的Selenium環(huán)境就算立住了。下一個問題是有了環(huán)境腳本到底怎么寫3. 搶票腳本的三個核心模塊登錄態(tài)、余票查詢與提交訂單這一章是整套腳本的主體我的做法是把流程拆成三個模塊登錄態(tài)管理、余票查詢、提交訂單。每個模塊單獨寫、單獨測最后串起來。千萬別一上來就寫一個1000行的大腳本出錯的時候你連在哪一行掛的都不知道。模塊化還有一個好處查詢模塊和提交模塊可以分開調優(yōu)比如查詢頻率降下來不影響提交速度提交環(huán)節(jié)卡了驗證碼也不影響下次輪詢。3.1 登錄態(tài)管理Cookie與等待策略12306的登錄方式有兩種賬號密碼登錄和掃碼登錄。手機App掃碼是現(xiàn)在的主流你讓腳本去自動識別二維碼是不可能的但根本不需要識別。掃碼登錄的一個特點是登錄成功后Cookie會種在瀏覽器里而且有效期覆蓋整個會話。所以我用的策略是“半自動登錄”腳本打開登錄頁你掏出手機掃碼掃完以后腳本自動檢測跳轉然后把Cookie序列化存到本地文件。下次啟動直接從文件加載Cookie免登錄。代碼如下import time import json from selenium import webdriver from selenium.webdriver.common.by import By USER_DATA_DIR /path/to/chrome_user_data COOKIE_FILE 12306_cookies.json options webdriver.ChromeOptions() options.add_argument(f--user-data-dir{USER_DATA_DIR}) driver webdriver.Chrome(optionsoptions) driver.get(https://kyfw.12306.cn/otn/resources/login.html) # 輪詢檢測是否已跳轉到個人中心最多等 120 秒 for _ in range(120): if login not in driver.current_url: break time.sleep(1) # 登錄成功后保存 Cookie cookies driver.get_cookies() with open(COOKIE_FILE, w, encodingutf-8) as f: json.dump(cookies, f, ensure_asciiFalse, indent2) print(f已保存 {len(cookies)} 條 Cookie) driver.quit()邏輯說明代碼打開12306登錄二維碼頁面然后用一個120次的循環(huán)每秒檢查一次當前URL——只要URL里不再包含login字樣說明登錄成功并且頁面發(fā)生了跳轉。跳轉后馬上執(zhí)行get_cookies()把Cookie抓下來寫進JSON文件。注意這里的time.sleep(1)是輪詢等待不是精確計時它的作用是給瀏覽器留出跳轉和渲染的時間。為什么不用WebDriverWait因為登錄跳轉的目標URL每次啟動時可能不一樣用顯式等待反而要額外處理條件輪詢更直觀。參數說明120秒是登錄超時上限如果你掃碼太慢或者網絡卡頓超時后腳本不會崩但Cookie文件不會生成你只需要重新跑一次。判斷跳轉用的是login關鍵字這個條件在12306的登錄流程里是穩(wěn)定存在的從登錄頁跳到個人中心后URL會有明顯變化如果你發(fā)現(xiàn)自己的環(huán)境不滿足條件可以用driver.find_element(By.ID, qd_index)檢測首頁訂單按鈕是否存在來替代。Cookie文件生成后每次啟動腳本前先加載它def load_cookies(driver): with open(COOKIE_FILE, r, encodingutf-8) as f: cookies json.load(f) for c in cookies: driver.add_cookie(c) driver.refresh()這里有個細節(jié)driver.add_cookie()必須在目標域名下調用也就是說你得先driver.get(https://kyfw.12306.cn)打開過一次頁面域名確認了才能往里塞Cookie不然會報“cannot add cookie for non-current domain”。這是新手必踩的坑之一。3.2 余票查詢解析station_name.js的站名編碼12306的余票查詢URL格式大致是https://kyfw.12306.cn/otn/leftTicket/query參數需要出發(fā)站編號、到達站編號、日期、坐席類型。這里的站名編碼不是漢字也不是拼音而是車站數據文件station_name.js里的固定編號。這個文件在12306的靜態(tài)資源目錄里可以直接拉取內容是var station_names c|BJP|北京北|beijingbei|bjb|...這種結構。解析它其實是整個腳本里最“算法”的一步。我的做法是在啟動時加載一次解析成字典后續(xù)查詢直接查表——做起來不復雜但容易在中文名和拼音的對應上踩坑城市有同名站、有帶“站”字和不帶“站”字的輸入差異統(tǒng)一以中文名為準。import re import requests class StationDB: def __init__(self, js_url): self.name2code {} self.code2name {} self.parse(js_url) def parse(self, url): r requests.get(url, timeout10) text r.content.decode(utf-8) # 字段以 c| 和 | 分隔順序為 拼音縮寫|站名|電報碼|拼音|簡拼|編號 for item in text.split()[1:]: parts item.split(|) if len(parts) 6: code parts[5] name parts[1] self.name2code[name] code self.code2name[code] name stations StationDB(https://kyfw.12306.cn/otn/resources/js/framework/station_name.js?station_version1.9300) print(stations.name2code[北京]) print(stations.name2code[上海虹橋])邏輯說明代碼拉取station_name.js按分割得到每個車站的獨立條目再按|分割字段取第2個中文名和第6個編號構建正向和反向映射。這樣查詢時傳入“北京”直接拿到編號拿到響應后也可以根據編號反查站名來校驗結果。station_version這個查詢參數不是固定的它會隨文件更新變化但你用不帶版本號的原始URL也能拿到最新文件所以不用精確到版本號。參數說明requests.get的timeout10約束了請求上限超過10秒直接拋異常讓腳本終止避免網絡抖動導致掛死。正則也可以用但我更推薦字符串分割直觀且不容易錯。解析后建議打印兩個站名做冒煙驗證比如“北京”和“上海虹橋”確認字典結構沒問題再繼續(xù)。余票查詢本身用HTTP請求就能完成不一定非得走Selenium的瀏覽器渲染——這也算Selenium搶票腳本的另外一個思路用Selenium管登錄和提交用requests管高頻查詢。查詢請求帶好Cookie響應是JSON格式里面包含了每個車次的余票狀態(tài)碼比如“有票”用數字表示“無票”用空串表示。判斷邏輯不復雜核心是查一次、解析一次、循環(huán)判斷。3.3 提交訂單從“預定”到“提交訂單”的節(jié)點控制查詢到有票之后腳本要接管瀏覽器去執(zhí)行真正的下單操作。這一步必須走Selenium原因是下單接口的加密參數依賴頁面環(huán)境你手動用requests偽造請求十有八九會被服務器拒絕。流程是定位到符合條件的車次行點擊“預定”按鈕等彈窗加載出乘車人列表勾選乘客點“提交訂單”最后在確認頁面點“確定”。每一步之間必須有等待條件不能只靠time.sleep(1)裸奔——網絡慢的時候頁面元素還沒渲染完你就去點擊直接拋NoSuchElementException。from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC from selenium.webdriver.common.by import By def select_train(driver, expect_train_no): # 等待車次列表渲染完成 wait WebDriverWait(driver, 15) rows wait.until( EC.presence_of_all_elements_located((By.CSS_SELECTOR, #queryLeftTable tr)) ) for row in rows: try: # 車次號在每行的第 1 列 no row.find_element(By.CSS_SELECTOR, td:nth-child(1)).text.strip() if no expect_train_no: # 等待“預定”按鈕變?yōu)榭牲c擊 btn row.find_element(By.CSS_SELECTOR, a.btn72) if btn and 預定 in btn.text: btn.click() return True except Exception: continue return False邏輯說明代碼先等車次表格的行元素全部出現(xiàn)然后遍歷每一行提取第一列的文本作為車次號匹配目標車次一旦命中就點擊該行的“預定”按鈕。try/except包裹單行解析是必要的因為表格里有些行是分隔行、有些行是高鐵動臥的特殊結構與其寫復雜的判斷邏輯不如讓異常跳過不可用的行。這里用了顯式等待而不是固定sleep好處是頁面加載快慢都能自適應。參數說明15秒是等待車次列表出現(xiàn)的最大時長超過會拋TimeoutException你要根據實際網絡環(huán)境調這個值。td:nth-child(1)是列選擇器12306的表格列順序調整時這里要跟著改。btn72這個class是12306車次行“預定”按鈕的穩(wěn)定樣式名但不是官方對外接口頁面改版時可能失效——遇到失效不要慌用瀏覽器F12看新按鈕的class再替換即可。點完“預定”后頁面會彈出確認訂單的窗口這時視野要切到新彈出的dialog元素再依次勾選乘車人、提交訂單。這一段和上面邏輯類似不再重復貼代碼但有一個決定性的參數值得單獨說乘客選擇的等待時間。彈窗里的乘車人列表是從后臺異步拉取的直接點擊很容易撲空建議配合EC.element_to_be_clickable來點擊每個乘客的復選框。如果乘客名單比較長優(yōu)先用身份證尾號做定位關鍵詞別用姓名重名會勾錯人。走到“提交訂單”這一步搶票腳本的“技術含量”基本用完了接下來拼的是穩(wěn)定性和容錯。而穩(wěn)定性的核心是參數調得夠不夠細。4. 搶票參數到底怎么調刷新間隔、加載策略與超時控制寫一套腳本跑通與讓一套腳本穩(wěn)定跑完一輪起售這是兩碼事。我見過很多人在第一個版本里把查詢間隔設成0.1秒結果跑了兩分鐘IP被臨時限制后面所有請求全部超時。這章把幾個關鍵參數講透講完你就知道為什么有些搶票腳本“玄學”般好用有些跑一次就封。4.1 刷新間隔不是越快越好查詢壓力與IP風控12306的余票接口對頻率是有限制的具體閾值沒有官方口徑但根據社區(qū)長期的觀察單IP密集請求持續(xù)一段時間后會出現(xiàn)連接重置或請求被導向驗證頁。所以刷新間隔的取值范圍建議在13秒之間起售高峰可以降低到0.8秒但一旦出現(xiàn)連續(xù)超時就要立刻拉長退避。間歇性刷新比連續(xù)刷新更穩(wěn)亂拳打死老師傅的打法在這里不適用。參數設計的核心是“指數退避”。維護一個連續(xù)失敗計數器初始查詢間隔1秒每失敗一次間隔翻倍最多加到10秒一旦成功間隔重置回初始值。用偽代碼表示就是interval 1.0 fail_count 0 while not bought: try: resp query_left_ticket(...) fail_count 0 interval 1.0 handle_response(resp) except RequestError: fail_count 1 interval min(1.0 * (2 ** fail_count), 10.0) time.sleep(interval)邏輯說明2 ** fail_count實現(xiàn)了翻倍退避連續(xù)失敗3次間隔就是8秒基本能緩解風控的緊張狀態(tài)。min(..., 10.0)給間隔封頂防止長時間卡在超長等待里錯過起售窗口。注意退避只針對查詢接口一旦進入提交訂單環(huán)節(jié)這個循環(huán)就退出了不能讓訂單提交也按1秒一次的頻率跑高并發(fā)搶票的訂單提交本來就容易碰上排隊提示提交本身要的是快、準頻率問題反而是次要的。4.2 頁面加載策略與超時參數讓瀏覽器不傻等Selenium打開的瀏覽器默認會等待頁面所有資源加載完畢才返回控制權這對搶票場景是災難——12306首頁掛了幾個大圖和一個慢速統(tǒng)計腳本光等它就浪費好幾秒。正確的做法是把頁面加載策略改成none或eager讓瀏覽器不等次要資源交互元素一就緒就繼續(xù)執(zhí)行。這個參數能省掉你寶貴的起售時間。from selenium import webdriver options webdriver.ChromeOptions() # eagerDOM 加載完成后立即繼續(xù)不等樣式表和圖片 options.page_load_strategy eager # 或者更激進none完全不等 # options.page_load_strategy none driver webdriver.Chrome(optionsoptions) driver.set_page_load_timeout(15) driver.set_script_timeout(10) driver.get(https://kyfw.12306.cn/otn/leftTicket/init?linktypeiddc)參數說明eager和none的區(qū)別是讓出控制權的時機eager是DOM樹解析完成就返回適合大部分場景none是發(fā)出導航請求就返回頁面的很多元素這時候還沒生成你的后續(xù)查找操作必須用顯式等待硬扛。說實話none更適合配合CDP做精細控制的場景搶票腳本用eager性價比最高既不等圖片又保證關鍵按鈕可用。set_page_load_timeout和set_script_timeout是雙保險防止個別資源掛起拖死整個會話。4.3 12306 MCP和“改接口”思路Selenium之外的選擇寫到這里插一句最近圈子里討論比較多的事情有開發(fā)者嘗試把12306的余票查詢接入MCP模型上下文協(xié)議讓大模型代理去調用余票接口替代手寫循環(huán)輪詢。這個方向的吸引人之處在于用自然語言就能編排搶票策略比如“幫我盯今天到上海的高鐵二等座有票就下單”。但從落地效果看MCP方案要解決的核心問題和Selenium方案一樣登錄態(tài)。查詢接口可以做成工具給AI調用但真正提交訂單還是繞不開網站的加密參數和風控。所以我的判斷是MCP目前更適合做余票監(jiān)控和票情分析離“自動買到票”還有距離——至少現(xiàn)階段Selenium這類瀏覽器自動化方案依然是落地的穩(wěn)定底線。4.4 提交訂單階段的兩個關鍵參數重試開關與排隊提示提交訂單時頁面可能出現(xiàn)兩種狀態(tài)一是彈“當前排隊人數過多”二是按鈕置灰不可點擊。這兩種情況的處理參數完全不同。排隊提示出現(xiàn)時不要關閉彈窗重來排隊本身就是狀態(tài)機——系統(tǒng)給了一個排隊序號你在隊列里等著刷新就意味著退出重排。你應該做的是輪詢檢查排隊提示是否消失超過30秒再考慮放棄重試。按鈕置灰則是另一回事說明當前車次已經無票或者你提交的乘客類型與該坐席不匹配這時候別傻等返回查詢循環(huán)重新找下一輪放票。把這個判斷邏輯寫進參數配置里能讓腳本在起售高峰期更“抗造”。def submit_order(driver, max_queue_wait30): wait WebDriverWait(driver, 5) submit_btn wait.until(EC.element_to_be_clickable((By.ID, submitOrder_id))) submit_btn.click() # 檢測排隊框可選配置項排隊超時時間 start time.time() while time.time() - start max_queue_wait: queue_bar driver.find_elements(By.CSS_SELECTOR, #queue_div) if queue_bar and queue_bar[0].is_displayed(): time.sleep(1) continue # 排隊結束進入確認環(huán)節(jié) confirm_btn driver.find_element(By.ID, qr_submit_id) confirm_btn.click() return True return False邏輯說明點擊“提交訂單”后代碼進入一個時間窗口型的循環(huán)只要排隊div可見就持續(xù)等待排隊div消失就立刻點擊最終確認按鈕。max_queue_wait30意味著排隊最多容忍30秒超時放棄并返回False讓上層邏輯決定是繼續(xù)查詢還是暫停一會兒。這里的time.sleep(1)是排隊輪詢間隔不用設太短因為排隊狀態(tài)的變化是以秒為粒度的設成1秒已經具備不錯的響應速度。參數說明#queue_div是12306排隊提示框的常見選擇器但我要強調一下頁面的ID不是永久不變的你要是發(fā)現(xiàn)選擇器失效優(yōu)先打開瀏覽器開發(fā)者工具確認一下實際結構而不是懷疑自己代碼寫錯了。qr_submit_id是最終確認按鈕的ID在改版中相對穩(wěn)定。max_queue_wait的值要根據搶票時段調整起售高峰排隊常見30秒以上你可以調到60但不要無限等非高峰時段通常秒過30秒綽綽有余。5. 搶票腳本的避坑清單5個高頻翻車點與排查辦法這一章是血淚經驗的匯總。寫這套腳本的人多踩坑的人更多下面5個問題基本覆蓋了絕大多數新手會碰到的情況按“現(xiàn)象→原因→解決”的順序列出來你遇到問題時可以直接對號入座。5.1 啟動就報“SessionNotCreatedException”現(xiàn)象腳本啟動后立刻崩潰報錯內容里帶著“This version of ChromeDriver only supports Chrome version XXX”。原因ChromeDriver和本機Chrome版本不匹配瀏覽器自動更新過但驅動還是舊版。這是環(huán)境問題里最常見的占了這類報錯的八成。解決去ChromeDriver鏡像站下載與本機Chrome大版本一致的驅動替換掉原來的二進制文件。如果機器上有多個Chrome版本還要留意系統(tǒng)PATH指向的是哪一個。另外Selenium 4.x自帶的Selenium Manager有時會拉錯驅動手動指定service webdriver.ChromeService(executable_path/path/to/chromedriver)能繞開自動匹配的坑。版本對齊這件事沒有捷徑屬于一次配置長期受益的基礎工作。5.2 頁面能打開Cookie也保存了但腳本一跑就跳到登錄頁現(xiàn)象手動登錄沒問題腳本啟動后加載Cookie也顯示成功但執(zhí)行到查詢時又被重定向回登錄頁。原因Cookie過期或者Cookie的域名/路徑不完整。12306的Cookie里有幾個關鍵會話字段有效期比較短而且有些字段是HttpOnly的你保存的是瀏覽器當前會話的快照不代表永久有效。另外如果你用--user-data-dir加載了舊用戶目錄目錄里的舊Cookie可能和新保存的Cookie互相覆蓋。解決刪除本地Cookie文件重新走一遍掃碼登錄流程確保登錄后立刻保存到新的文件。加載Cookie時不要用driver.add_cookie一條條塞而應該先打開登錄頁建立會話域再塞Cookie并刷新頁面。建議把Cookie文件按日期重命名比如cookies_20250101.json方便回退排查。如果還有問題檢查系統(tǒng)時間是否準確——Cookie校驗對時間敏感系統(tǒng)時間偏差大會導致會話直接判定失效。5.3 車票顯示有票點擊提交卻提示“余票不足”現(xiàn)象查詢接口明明返回了有票狀態(tài)點進提交訂單環(huán)節(jié)卻被提示沒有余票也就是網上很多人說的“12306顯示有票買的時候又顯示余票不足”。原因這是兩個層面的數據一致性延遲。查詢接口的余票狀態(tài)本身就存在數秒緩存頁面顯示“有票”不代表那幾張票還在更關鍵的是余票鎖定發(fā)生在你點擊提交訂單之后別人比你早幾十毫秒提交票已經被鎖走你晚了一步就鎖不到。這不是腳本的bug是并發(fā)競爭的正常結果。解決這種情況說明你的查詢頻率和提交速度還有提升空間。第一縮小查詢范圍只查目標車次別全頁面掃描減少決策耗時。第二把提交訂單的代碼路徑優(yōu)化到最短去掉多余的等待條件。第三接受一個事實在極端熱門的線路上腳本只是提高概率不是保證成功。遇到這種提示腳本應該立即返回查詢循環(huán)等下一輪而不是卡在錯誤狀態(tài)里空轉。5.4 起售時間一到瀏覽器一直在轉圈不出結果現(xiàn)象起售那一刻點“查詢”瀏覽器頂部標簽一直在轉等了十幾秒才出數據等到能點擊時票已經沒了。原因頁面加載策略選得太保守默認等待全部資源加載。12306的余票頁面在起售瞬間會推入大量數據圖片、腳本、統(tǒng)計SDK都會擠壓帶寬你悶頭等瀏覽器加載完成后臺的搶票請求早就把票耗光了。解決把頁面加載策略改成eager并且對查詢按鈕的點擊時機做優(yōu)化——起售前先把查詢條件填好、頁面停在查詢頁起售時間一到直接點擊“查詢”不重新加載整個頁面。還有一種常見做法是定時任務精準觸發(fā)用Python的schedule庫在起售時間前5秒啟動腳本預留頁面加載時間讓查詢請求剛好在起售時刻發(fā)出。另外把瀏覽器窗口最小化并不能提快速度反而某些系統(tǒng)會降低后臺進程的調度優(yōu)先級干脆讓窗口保持前臺別折騰。5.5 跑著跑著突然彈出滑塊驗證現(xiàn)象腳本連續(xù)運行一段時間后頁面彈出滑塊驗證組件Selenium后續(xù)操作全部卡住直到超時。原因頻率觸發(fā)了風控。bytpass分流搶票為什么“被識別”是必然的——打著搶票名義的高頻請求目標明確特征明顯平臺不攔你攔誰你用自己的Selenium腳本雖然沒有第三方軟件那么強的特征但長時間高頻操作同一個接口同樣會被識別?；瑝K本質上是平臺在告訴你操作密度超出真人范圍來驗一下。解決第一降低輪詢頻率把間隔從0.5秒拉長到1.52秒雖然搶票概率會稍降但能保證腳本不被打斷。第二設計人機協(xié)作流程檢測到滑塊組件出現(xiàn)時腳本發(fā)送桌面通知或播放提示音由你來手動完成滑塊驗證驗證通過后腳本繼續(xù)運行。自動識別滑塊的方案不是不可行但12306的滑塊軌跡校驗越來越嚴自動化的通過率不穩(wěn)定與其花時間調識別代碼不如留一個人工兜底的口子。說到底平臺設置驗證碼的本意就是防止自動化以現(xiàn)在的風控水平硬拼識別算法是個性價比很低的方向。6. 驗證腳本的最終辦法把搶票拆成三段來測試拿到別人的“全部資料詳細文檔”或者在本地寫完這套腳本之后最該做的不是等下一次起售直接開跑而是先做一次演練。我的習慣是把流程拆成三段來測任何一段不過關都不進入下一段。第一段測登錄啟動腳本掃碼登錄保存Cookie退出再啟動腳本加載Cookie刷新頁面確認登錄態(tài)還在。這段測試的價值在于排除所有Cookie和會話層面的問題而且隨時能做不依賴車次時間。第二段測查詢隨便選一個非熱門線路比如北京到石家莊跑10次查詢循環(huán)觀察響應時間、解析結果、退避邏輯是否正確。重點看兩個指標平均響應時間是否在1秒內連續(xù)查詢多次后是否出現(xiàn)超時或驗證碼。第三段測提交找一個有余票的普通車次把腳本流程走到“提交訂單”但不要支付驗證到確認訂單頁面就手動終止。這一步能檢查從車次定位到乘客勾選再到訂單確認的全鏈路是否通暢。有一個我個人的習慣分享給你在正式搶票前把車次方向換成反方向試一次——比如你要搶北京到上海就先跑一次上海到北京的查詢提交流程。反向車次的余票通常充足更容易完整走通流程也更容易暴露提交環(huán)節(jié)的隱患。確認三段全通實戰(zhàn)時你才有底氣把腳本掛在那里去干別的事。另外建議每次實戰(zhàn)前更新一次station_name.js的緩存12306偶爾會新增站點、調整編號用舊緩存查新站名會直接查不到票。這套方案的價值不只在搶票這件事本身。你把登錄態(tài)管理、輪詢退避、顯式等待、頁面加載策略這些細節(jié)吃透換成盯演唱會門票、驗證碼短信、秒殺場景底層思路都能復用。對我來說每次起售日蹲在電腦前看著腳本代替我做那些重復動作自己只負責處理驗證碼和最終支付那種“工具就位、邏輯閉環(huán)”的踏實感比搶到票本身更有成就感。希望你也能在調試這套腳本的過程中把Selenium從“聽說過”變成“用得順手”。好這套方案就講到這希望幫到你。本文還有配套的精品資源點擊獲取 基于Selenium的12306自動搶票腳本：原理、實現(xiàn)與避坑指南
簡介基于Selenium的12306自動搶票腳本全套資料面向計算機相關專業(yè)學生、教師及企業(yè)開發(fā)者可解決購票腳本設計、自動化測試與實戰(zhàn)演練等需求。壓縮包共18個文件涵蓋7個Python源碼、5個XML工程配置、3個文本說明及YAML環(huán)境配置等其中py文件實現(xiàn)核心搶票邏輯、車站信息獲取、參數配置與郵件提醒等模塊yaml與xml用于配置和工程管理md與txt提供詳細使用文檔。資源已通過運行測試并獲導師認可、答辯評審95分適合用于畢業(yè)設計、課程設計、項目初期演示或Selenium進階學習。目前已有129人學習下載配套詳細文檔能幫助讀者快速理解自動化購票流程包括余票查詢、提交訂單等關鍵環(huán)節(jié)目錄結構清晰便于按模塊閱讀和二次開發(fā)。1. 基于Selenium的12306自動搶票腳本它不是外掛是替你盯著余票的瀏覽器每年春運一到朋友圈里就會冒出一堆“代搶票”的鏈接還總有人問“為什么別人手速那么快明明顯示有票一點進去就沒了”其實問題不在于手速而在于你盯著頁面、刷新、對比車次、再點預定、再選乘客的速度?；赟elenium的12306自動搶票腳本做的事情就是把這套“人肉操作”變成瀏覽器自動執(zhí)行定時刷新余票、按你預設的車次和坐席過濾、出現(xiàn)目標車票就點預定、填好乘客、提交訂單。它不是破解12306的接口也沒有繞過任何風控邏輯只是在用程序控制一個真實瀏覽器模擬一個始終在線且不提手酸的“真人”。所以它最大的價值不是“搶”而是讓腳本幫你把“盯”這件事做到一天不眨眼。適合通勤票、假期票、幫家里老人搶票也適合想拿自動化框架練手的開發(fā)者前提是你愿意把登錄、驗證碼這些環(huán)節(jié)留出人工兜底。2. 為什么選Selenium做搶票選型理由與最少可運行環(huán)境在動手之前先把選型這事說透。很多人看到“自動搶票腳本”第一反應是抓12306的后臺接口直接POST提交訂單。這條路對開發(fā)者的誘惑很大但12306的核心下單接口做過簽名校驗關鍵參數由前端加密生成抓包抓到的明文請求根本沒法直接復用。更現(xiàn)實的問題是接口方案一旦失效你面對的不是改個參數的事而是要把整套簽名算法逆向出來維護成本極高。Selenium走的是另一條路它不碰接口而是驅動瀏覽器按真實用戶的路徑操作頁面。12306的風控再嚴也不可能把正常打開網頁的人全攔住對吧這就是Selenium做自動化搶票的核心優(yōu)勢——黑匣子最小化。2.1 Selenium憑什么能搶票瀏覽器自動化與真人操作的邊界Selenium是一個WebDriver自動化測試框架常見用法是讓測試腳本去驅動Chrome、Firefox這類瀏覽器模擬點擊、輸入、滾動、等待這些行為。它最早是給測試人員做回歸測試用的后來被廣泛用于自動化運營、數據采集自然也就有人拿它來做搶票腳本。它的工作模式是“客戶端庫 瀏覽器驅動”你在Python里調用selenium包它通過ChromeDriver這類驅動件把指令翻譯成瀏覽器能理解的動作再由瀏覽器真實地渲染頁面、執(zhí)行JavaScript。這種模式的邊界在哪兒第一Selenium不是萬能的它要求目標頁面在DOM層面穩(wěn)定如果12306改版把按鈕的class和id全換掉腳本就要跟著改選擇器。第二它天然會留下自動化特征比如webdriver屬性、奇怪的瀏覽器指紋風控系統(tǒng)可以識別它成年人要有點自覺任何針對Web的自動化工具都存在被平臺識別和管控的可能這不是腳本本身能完全藏住的。第三它處理不了“頁面沒變但數據已變”的情況余票查詢這種場景還是得靠輪詢。所以真實項目里Selenium做的是“最后一百米”——把人到按鈕的距離縮短為程序到按鈕的距離而不是發(fā)明一把萬能鑰匙。2.2 搭環(huán)境Python虛擬環(huán)境Selenium瀏覽器驅動的最小步驟環(huán)境搭建不復雜但順序別搞錯。先建一個干凈的Python虛擬環(huán)境然后在里面安裝selenium包最后下載與瀏覽器版本匹配的驅動。很多人一上來直接全局裝selenium結果驅動版本和瀏覽器對不上報一堆SessionNotCreatedException這種翻車完全可以避免。按下面這套來操作# 1. 創(chuàng)建并激活虛擬環(huán)境Python 3.9 均可 python -m venv venv_12306 source venv_12306/bin/activate # Windows 下執(zhí)行 venv_12306\Scripts\activate # 2. 安裝 selenium pip install selenium # 3. 檢查瀏覽器版本 google-chrome --version # Windows 下在 Chrome 地址欄輸入 chrome://version參數說明虛擬環(huán)境解決的是包沖突問題你機器上可能已經裝了舊版selenium或者requests搶票腳本對依賴版本比較敏感隔離是必須的。安裝selenium不需要指定版本但建議裝到4.x以上4.x的API比3.x干凈很多不再需要手動聲明executable_path。檢查瀏覽器版本這一步別省驅動要和瀏覽器大版本一致比如Chrome 120就配ChromeDriver 120.x小版本可以略有偏差大版本不能錯。接下來是驅動下載。Selenium 4.x提供了Selenium Manager會自動去官方源拉驅動但國內網絡條件下經常超時建議還是手動下載。下載后把驅動文件放到一個固定目錄比如tools/chromedriver然后在代碼里指定路徑。2.3 最小啟動腳本先跑通一個能打開12306的瀏覽器環(huán)境裝好后不要急著寫業(yè)務邏輯先跑一個最小啟動腳本驗證整個鏈路是通的。這一步能過濾掉九成環(huán)境問題。代碼只做一件事打開一個帶用戶數據目錄的Chrome窗口訪問12306的首頁然后停在那里等你按回車。為什么要帶用戶數據目錄因為搶票場景需要保持登錄狀態(tài)你手動登錄一次后Cookie存在這個目錄里下次腳本啟動還能繼續(xù)用不然每次都要重新掃碼登錄。from selenium import webdriver options webdriver.ChromeOptions() # 使用自定義用戶數據目錄保存登錄態(tài) options.add_argument(--user-data-dir/path/to/chrome_user_data) # 關閉正在受到自動軟件控制提示條 options.add_experimental_option(excludeSwitches, [enable-automation]) # 可選去掉 webdriver 特征警惕這屬于反檢測實踐需自行評估風險 options.add_argument(--disable-blink-featuresAutomationControlled) driver webdriver.Chrome(optionsoptions) driver.get(https://www.12306.cn/index/) print(瀏覽器已打開請手動確認是否進入官網) input(按回車鍵退出...) driver.quit()邏輯說明代碼先給Chrome配置一組選項再用這些選項生成driver實例打開12306首頁最后用input()把進程掛住好讓你肉眼看一眼瀏覽器是不是真的正常加載了頁面。--user-data-dir這個參數是整套腳本的地基登錄態(tài)能不能跨腳本保持就看它配沒配對。excludeSwitches和--disable-blink-features是控制自動化提示的常用做法但你要清楚這類參數只是降低存在感不能保證絕對不被平臺識別——后面避坑章節(jié)我會再細說。參數說明/path/to/chrome_user_data要替換成你的絕對路徑注意Windows路徑里的反斜杠要寫成雙反斜杠或使用r...原始字符串。--user-data-dir指向的是一個空目錄也沒關系Chrome會自動初始化。這里有個常見坑如果你之前已經開著一個Chrome進程再用同一個用戶目錄啟動腳本會直接報“user data directory is already in use”腳本啟動前先關掉其他Chrome窗口。跑通這一步你的Selenium環(huán)境就算立住了。下一個問題是有了環(huán)境腳本到底怎么寫3. 搶票腳本的三個核心模塊登錄態(tài)、余票查詢與提交訂單這一章是整套腳本的主體我的做法是把流程拆成三個模塊登錄態(tài)管理、余票查詢、提交訂單。每個模塊單獨寫、單獨測最后串起來。千萬別一上來就寫一個1000行的大腳本出錯的時候你連在哪一行掛的都不知道。模塊化還有一個好處查詢模塊和提交模塊可以分開調優(yōu)比如查詢頻率降下來不影響提交速度提交環(huán)節(jié)卡了驗證碼也不影響下次輪詢。3.1 登錄態(tài)管理Cookie與等待策略12306的登錄方式有兩種賬號密碼登錄和掃碼登錄。手機App掃碼是現(xiàn)在的主流你讓腳本去自動識別二維碼是不可能的但根本不需要識別。掃碼登錄的一個特點是登錄成功后Cookie會種在瀏覽器里而且有效期覆蓋整個會話。所以我用的策略是“半自動登錄”腳本打開登錄頁你掏出手機掃碼掃完以后腳本自動檢測跳轉然后把Cookie序列化存到本地文件。下次啟動直接從文件加載Cookie免登錄。代碼如下import time import json from selenium import webdriver from selenium.webdriver.common.by import By USER_DATA_DIR /path/to/chrome_user_data COOKIE_FILE 12306_cookies.json options webdriver.ChromeOptions() options.add_argument(f--user-data-dir{USER_DATA_DIR}) driver webdriver.Chrome(optionsoptions) driver.get(https://kyfw.12306.cn/otn/resources/login.html) # 輪詢檢測是否已跳轉到個人中心最多等 120 秒 for _ in range(120): if login not in driver.current_url: break time.sleep(1) # 登錄成功后保存 Cookie cookies driver.get_cookies() with open(COOKIE_FILE, w, encodingutf-8) as f: json.dump(cookies, f, ensure_asciiFalse, indent2) print(f已保存 {len(cookies)} 條 Cookie) driver.quit()邏輯說明代碼打開12306登錄二維碼頁面然后用一個120次的循環(huán)每秒檢查一次當前URL——只要URL里不再包含login字樣說明登錄成功并且頁面發(fā)生了跳轉。跳轉后馬上執(zhí)行get_cookies()把Cookie抓下來寫進JSON文件。注意這里的time.sleep(1)是輪詢等待不是精確計時它的作用是給瀏覽器留出跳轉和渲染的時間。為什么不用WebDriverWait因為登錄跳轉的目標URL每次啟動時可能不一樣用顯式等待反而要額外處理條件輪詢更直觀。參數說明120秒是登錄超時上限如果你掃碼太慢或者網絡卡頓超時后腳本不會崩但Cookie文件不會生成你只需要重新跑一次。判斷跳轉用的是login關鍵字這個條件在12306的登錄流程里是穩(wěn)定存在的從登錄頁跳到個人中心后URL會有明顯變化如果你發(fā)現(xiàn)自己的環(huán)境不滿足條件可以用driver.find_element(By.ID, qd_index)檢測首頁訂單按鈕是否存在來替代。Cookie文件生成后每次啟動腳本前先加載它def load_cookies(driver): with open(COOKIE_FILE, r, encodingutf-8) as f: cookies json.load(f) for c in cookies: driver.add_cookie(c) driver.refresh()這里有個細節(jié)driver.add_cookie()必須在目標域名下調用也就是說你得先driver.get(https://kyfw.12306.cn)打開過一次頁面域名確認了才能往里塞Cookie不然會報“cannot add cookie for non-current domain”。這是新手必踩的坑之一。3.2 余票查詢解析station_name.js的站名編碼12306的余票查詢URL格式大致是https://kyfw.12306.cn/otn/leftTicket/query參數需要出發(fā)站編號、到達站編號、日期、坐席類型。這里的站名編碼不是漢字也不是拼音而是車站數據文件station_name.js里的固定編號。這個文件在12306的靜態(tài)資源目錄里可以直接拉取內容是var station_names c|BJP|北京北|beijingbei|bjb|...這種結構。解析它其實是整個腳本里最“算法”的一步。我的做法是在啟動時加載一次解析成字典后續(xù)查詢直接查表——做起來不復雜但容易在中文名和拼音的對應上踩坑城市有同名站、有帶“站”字和不帶“站”字的輸入差異統(tǒng)一以中文名為準。import re import requests class StationDB: def __init__(self, js_url): self.name2code {} self.code2name {} self.parse(js_url) def parse(self, url): r requests.get(url, timeout10) text r.content.decode(utf-8) # 字段以 c| 和 | 分隔順序為 拼音縮寫|站名|電報碼|拼音|簡拼|編號 for item in text.split()[1:]: parts item.split(|) if len(parts) 6: code parts[5] name parts[1] self.name2code[name] code self.code2name[code] name stations StationDB(https://kyfw.12306.cn/otn/resources/js/framework/station_name.js?station_version1.9300) print(stations.name2code[北京]) print(stations.name2code[上海虹橋])邏輯說明代碼拉取station_name.js按分割得到每個車站的獨立條目再按|分割字段取第2個中文名和第6個編號構建正向和反向映射。這樣查詢時傳入“北京”直接拿到編號拿到響應后也可以根據編號反查站名來校驗結果。station_version這個查詢參數不是固定的它會隨文件更新變化但你用不帶版本號的原始URL也能拿到最新文件所以不用精確到版本號。參數說明requests.get的timeout10約束了請求上限超過10秒直接拋異常讓腳本終止避免網絡抖動導致掛死。正則也可以用但我更推薦字符串分割直觀且不容易錯。解析后建議打印兩個站名做冒煙驗證比如“北京”和“上海虹橋”確認字典結構沒問題再繼續(xù)。余票查詢本身用HTTP請求就能完成不一定非得走Selenium的瀏覽器渲染——這也算Selenium搶票腳本的另外一個思路用Selenium管登錄和提交用requests管高頻查詢。查詢請求帶好Cookie響應是JSON格式里面包含了每個車次的余票狀態(tài)碼比如“有票”用數字表示“無票”用空串表示。判斷邏輯不復雜核心是查一次、解析一次、循環(huán)判斷。3.3 提交訂單從“預定”到“提交訂單”的節(jié)點控制查詢到有票之后腳本要接管瀏覽器去執(zhí)行真正的下單操作。這一步必須走Selenium原因是下單接口的加密參數依賴頁面環(huán)境你手動用requests偽造請求十有八九會被服務器拒絕。流程是定位到符合條件的車次行點擊“預定”按鈕等彈窗加載出乘車人列表勾選乘客點“提交訂單”最后在確認頁面點“確定”。每一步之間必須有等待條件不能只靠time.sleep(1)裸奔——網絡慢的時候頁面元素還沒渲染完你就去點擊直接拋NoSuchElementException。from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC from selenium.webdriver.common.by import By def select_train(driver, expect_train_no): # 等待車次列表渲染完成 wait WebDriverWait(driver, 15) rows wait.until( EC.presence_of_all_elements_located((By.CSS_SELECTOR, #queryLeftTable tr)) ) for row in rows: try: # 車次號在每行的第 1 列 no row.find_element(By.CSS_SELECTOR, td:nth-child(1)).text.strip() if no expect_train_no: # 等待“預定”按鈕變?yōu)榭牲c擊 btn row.find_element(By.CSS_SELECTOR, a.btn72) if btn and 預定 in btn.text: btn.click() return True except Exception: continue return False邏輯說明代碼先等車次表格的行元素全部出現(xiàn)然后遍歷每一行提取第一列的文本作為車次號匹配目標車次一旦命中就點擊該行的“預定”按鈕。try/except包裹單行解析是必要的因為表格里有些行是分隔行、有些行是高鐵動臥的特殊結構與其寫復雜的判斷邏輯不如讓異常跳過不可用的行。這里用了顯式等待而不是固定sleep好處是頁面加載快慢都能自適應。參數說明15秒是等待車次列表出現(xiàn)的最大時長超過會拋TimeoutException你要根據實際網絡環(huán)境調這個值。td:nth-child(1)是列選擇器12306的表格列順序調整時這里要跟著改。btn72這個class是12306車次行“預定”按鈕的穩(wěn)定樣式名但不是官方對外接口頁面改版時可能失效——遇到失效不要慌用瀏覽器F12看新按鈕的class再替換即可。點完“預定”后頁面會彈出確認訂單的窗口這時視野要切到新彈出的dialog元素再依次勾選乘車人、提交訂單。這一段和上面邏輯類似不再重復貼代碼但有一個決定性的參數值得單獨說乘客選擇的等待時間。彈窗里的乘車人列表是從后臺異步拉取的直接點擊很容易撲空建議配合EC.element_to_be_clickable來點擊每個乘客的復選框。如果乘客名單比較長優(yōu)先用身份證尾號做定位關鍵詞別用姓名重名會勾錯人。走到“提交訂單”這一步搶票腳本的“技術含量”基本用完了接下來拼的是穩(wěn)定性和容錯。而穩(wěn)定性的核心是參數調得夠不夠細。4. 搶票參數到底怎么調刷新間隔、加載策略與超時控制寫一套腳本跑通與讓一套腳本穩(wěn)定跑完一輪起售這是兩碼事。我見過很多人在第一個版本里把查詢間隔設成0.1秒結果跑了兩分鐘IP被臨時限制后面所有請求全部超時。這章把幾個關鍵參數講透講完你就知道為什么有些搶票腳本“玄學”般好用有些跑一次就封。4.1 刷新間隔不是越快越好查詢壓力與IP風控12306的余票接口對頻率是有限制的具體閾值沒有官方口徑但根據社區(qū)長期的觀察單IP密集請求持續(xù)一段時間后會出現(xiàn)連接重置或請求被導向驗證頁。所以刷新間隔的取值范圍建議在13秒之間起售高峰可以降低到0.8秒但一旦出現(xiàn)連續(xù)超時就要立刻拉長退避。間歇性刷新比連續(xù)刷新更穩(wěn)亂拳打死老師傅的打法在這里不適用。參數設計的核心是“指數退避”。維護一個連續(xù)失敗計數器初始查詢間隔1秒每失敗一次間隔翻倍最多加到10秒一旦成功間隔重置回初始值。用偽代碼表示就是interval 1.0 fail_count 0 while not bought: try: resp query_left_ticket(...) fail_count 0 interval 1.0 handle_response(resp) except RequestError: fail_count 1 interval min(1.0 * (2 ** fail_count), 10.0) time.sleep(interval)邏輯說明2 ** fail_count實現(xiàn)了翻倍退避連續(xù)失敗3次間隔就是8秒基本能緩解風控的緊張狀態(tài)。min(..., 10.0)給間隔封頂防止長時間卡在超長等待里錯過起售窗口。注意退避只針對查詢接口一旦進入提交訂單環(huán)節(jié)這個循環(huán)就退出了不能讓訂單提交也按1秒一次的頻率跑高并發(fā)搶票的訂單提交本來就容易碰上排隊提示提交本身要的是快、準頻率問題反而是次要的。4.2 頁面加載策略與超時參數讓瀏覽器不傻等Selenium打開的瀏覽器默認會等待頁面所有資源加載完畢才返回控制權這對搶票場景是災難——12306首頁掛了幾個大圖和一個慢速統(tǒng)計腳本光等它就浪費好幾秒。正確的做法是把頁面加載策略改成none或eager讓瀏覽器不等次要資源交互元素一就緒就繼續(xù)執(zhí)行。這個參數能省掉你寶貴的起售時間。from selenium import webdriver options webdriver.ChromeOptions() # eagerDOM 加載完成后立即繼續(xù)不等樣式表和圖片 options.page_load_strategy eager # 或者更激進none完全不等 # options.page_load_strategy none driver webdriver.Chrome(optionsoptions) driver.set_page_load_timeout(15) driver.set_script_timeout(10) driver.get(https://kyfw.12306.cn/otn/leftTicket/init?linktypeiddc)參數說明eager和none的區(qū)別是讓出控制權的時機eager是DOM樹解析完成就返回適合大部分場景none是發(fā)出導航請求就返回頁面的很多元素這時候還沒生成你的后續(xù)查找操作必須用顯式等待硬扛。說實話none更適合配合CDP做精細控制的場景搶票腳本用eager性價比最高既不等圖片又保證關鍵按鈕可用。set_page_load_timeout和set_script_timeout是雙保險防止個別資源掛起拖死整個會話。4.3 12306 MCP和“改接口”思路Selenium之外的選擇寫到這里插一句最近圈子里討論比較多的事情有開發(fā)者嘗試把12306的余票查詢接入MCP模型上下文協(xié)議讓大模型代理去調用余票接口替代手寫循環(huán)輪詢。這個方向的吸引人之處在于用自然語言就能編排搶票策略比如“幫我盯今天到上海的高鐵二等座有票就下單”。但從落地效果看MCP方案要解決的核心問題和Selenium方案一樣登錄態(tài)。查詢接口可以做成工具給AI調用但真正提交訂單還是繞不開網站的加密參數和風控。所以我的判斷是MCP目前更適合做余票監(jiān)控和票情分析離“自動買到票”還有距離——至少現(xiàn)階段Selenium這類瀏覽器自動化方案依然是落地的穩(wěn)定底線。4.4 提交訂單階段的兩個關鍵參數重試開關與排隊提示提交訂單時頁面可能出現(xiàn)兩種狀態(tài)一是彈“當前排隊人數過多”二是按鈕置灰不可點擊。這兩種情況的處理參數完全不同。排隊提示出現(xiàn)時不要關閉彈窗重來排隊本身就是狀態(tài)機——系統(tǒng)給了一個排隊序號你在隊列里等著刷新就意味著退出重排。你應該做的是輪詢檢查排隊提示是否消失超過30秒再考慮放棄重試。按鈕置灰則是另一回事說明當前車次已經無票或者你提交的乘客類型與該坐席不匹配這時候別傻等返回查詢循環(huán)重新找下一輪放票。把這個判斷邏輯寫進參數配置里能讓腳本在起售高峰期更“抗造”。def submit_order(driver, max_queue_wait30): wait WebDriverWait(driver, 5) submit_btn wait.until(EC.element_to_be_clickable((By.ID, submitOrder_id))) submit_btn.click() # 檢測排隊框可選配置項排隊超時時間 start time.time() while time.time() - start max_queue_wait: queue_bar driver.find_elements(By.CSS_SELECTOR, #queue_div) if queue_bar and queue_bar[0].is_displayed(): time.sleep(1) continue # 排隊結束進入確認環(huán)節(jié) confirm_btn driver.find_element(By.ID, qr_submit_id) confirm_btn.click() return True return False邏輯說明點擊“提交訂單”后代碼進入一個時間窗口型的循環(huán)只要排隊div可見就持續(xù)等待排隊div消失就立刻點擊最終確認按鈕。max_queue_wait30意味著排隊最多容忍30秒超時放棄并返回False讓上層邏輯決定是繼續(xù)查詢還是暫停一會兒。這里的time.sleep(1)是排隊輪詢間隔不用設太短因為排隊狀態(tài)的變化是以秒為粒度的設成1秒已經具備不錯的響應速度。參數說明#queue_div是12306排隊提示框的常見選擇器但我要強調一下頁面的ID不是永久不變的你要是發(fā)現(xiàn)選擇器失效優(yōu)先打開瀏覽器開發(fā)者工具確認一下實際結構而不是懷疑自己代碼寫錯了。qr_submit_id是最終確認按鈕的ID在改版中相對穩(wěn)定。max_queue_wait的值要根據搶票時段調整起售高峰排隊常見30秒以上你可以調到60但不要無限等非高峰時段通常秒過30秒綽綽有余。5. 搶票腳本的避坑清單5個高頻翻車點與排查辦法這一章是血淚經驗的匯總。寫這套腳本的人多踩坑的人更多下面5個問題基本覆蓋了絕大多數新手會碰到的情況按“現(xiàn)象→原因→解決”的順序列出來你遇到問題時可以直接對號入座。5.1 啟動就報“SessionNotCreatedException”現(xiàn)象腳本啟動后立刻崩潰報錯內容里帶著“This version of ChromeDriver only supports Chrome version XXX”。原因ChromeDriver和本機Chrome版本不匹配瀏覽器自動更新過但驅動還是舊版。這是環(huán)境問題里最常見的占了這類報錯的八成。解決去ChromeDriver鏡像站下載與本機Chrome大版本一致的驅動替換掉原來的二進制文件。如果機器上有多個Chrome版本還要留意系統(tǒng)PATH指向的是哪一個。另外Selenium 4.x自帶的Selenium Manager有時會拉錯驅動手動指定service webdriver.ChromeService(executable_path/path/to/chromedriver)能繞開自動匹配的坑。版本對齊這件事沒有捷徑屬于一次配置長期受益的基礎工作。5.2 頁面能打開Cookie也保存了但腳本一跑就跳到登錄頁現(xiàn)象手動登錄沒問題腳本啟動后加載Cookie也顯示成功但執(zhí)行到查詢時又被重定向回登錄頁。原因Cookie過期或者Cookie的域名/路徑不完整。12306的Cookie里有幾個關鍵會話字段有效期比較短而且有些字段是HttpOnly的你保存的是瀏覽器當前會話的快照不代表永久有效。另外如果你用--user-data-dir加載了舊用戶目錄目錄里的舊Cookie可能和新保存的Cookie互相覆蓋。解決刪除本地Cookie文件重新走一遍掃碼登錄流程確保登錄后立刻保存到新的文件。加載Cookie時不要用driver.add_cookie一條條塞而應該先打開登錄頁建立會話域再塞Cookie并刷新頁面。建議把Cookie文件按日期重命名比如cookies_20250101.json方便回退排查。如果還有問題檢查系統(tǒng)時間是否準確——Cookie校驗對時間敏感系統(tǒng)時間偏差大會導致會話直接判定失效。5.3 車票顯示有票點擊提交卻提示“余票不足”現(xiàn)象查詢接口明明返回了有票狀態(tài)點進提交訂單環(huán)節(jié)卻被提示沒有余票也就是網上很多人說的“12306顯示有票買的時候又顯示余票不足”。原因這是兩個層面的數據一致性延遲。查詢接口的余票狀態(tài)本身就存在數秒緩存頁面顯示“有票”不代表那幾張票還在更關鍵的是余票鎖定發(fā)生在你點擊提交訂單之后別人比你早幾十毫秒提交票已經被鎖走你晚了一步就鎖不到。這不是腳本的bug是并發(fā)競爭的正常結果。解決這種情況說明你的查詢頻率和提交速度還有提升空間。第一縮小查詢范圍只查目標車次別全頁面掃描減少決策耗時。第二把提交訂單的代碼路徑優(yōu)化到最短去掉多余的等待條件。第三接受一個事實在極端熱門的線路上腳本只是提高概率不是保證成功。遇到這種提示腳本應該立即返回查詢循環(huán)等下一輪而不是卡在錯誤狀態(tài)里空轉。5.4 起售時間一到瀏覽器一直在轉圈不出結果現(xiàn)象起售那一刻點“查詢”瀏覽器頂部標簽一直在轉等了十幾秒才出數據等到能點擊時票已經沒了。原因頁面加載策略選得太保守默認等待全部資源加載。12306的余票頁面在起售瞬間會推入大量數據圖片、腳本、統(tǒng)計SDK都會擠壓帶寬你悶頭等瀏覽器加載完成后臺的搶票請求早就把票耗光了。解決把頁面加載策略改成eager并且對查詢按鈕的點擊時機做優(yōu)化——起售前先把查詢條件填好、頁面停在查詢頁起售時間一到直接點擊“查詢”不重新加載整個頁面。還有一種常見做法是定時任務精準觸發(fā)用Python的schedule庫在起售時間前5秒啟動腳本預留頁面加載時間讓查詢請求剛好在起售時刻發(fā)出。另外把瀏覽器窗口最小化并不能提快速度反而某些系統(tǒng)會降低后臺進程的調度優(yōu)先級干脆讓窗口保持前臺別折騰。5.5 跑著跑著突然彈出滑塊驗證現(xiàn)象腳本連續(xù)運行一段時間后頁面彈出滑塊驗證組件Selenium后續(xù)操作全部卡住直到超時。原因頻率觸發(fā)了風控。bytpass分流搶票為什么“被識別”是必然的——打著搶票名義的高頻請求目標明確特征明顯平臺不攔你攔誰你用自己的Selenium腳本雖然沒有第三方軟件那么強的特征但長時間高頻操作同一個接口同樣會被識別?；瑝K本質上是平臺在告訴你操作密度超出真人范圍來驗一下。解決第一降低輪詢頻率把間隔從0.5秒拉長到1.52秒雖然搶票概率會稍降但能保證腳本不被打斷。第二設計人機協(xié)作流程檢測到滑塊組件出現(xiàn)時腳本發(fā)送桌面通知或播放提示音由你來手動完成滑塊驗證驗證通過后腳本繼續(xù)運行。自動識別滑塊的方案不是不可行但12306的滑塊軌跡校驗越來越嚴自動化的通過率不穩(wěn)定與其花時間調識別代碼不如留一個人工兜底的口子。說到底平臺設置驗證碼的本意就是防止自動化以現(xiàn)在的風控水平硬拼識別算法是個性價比很低的方向。6. 驗證腳本的最終辦法把搶票拆成三段來測試拿到別人的“全部資料詳細文檔”或者在本地寫完這套腳本之后最該做的不是等下一次起售直接開跑而是先做一次演練。我的習慣是把流程拆成三段來測任何一段不過關都不進入下一段。第一段測登錄啟動腳本掃碼登錄保存Cookie退出再啟動腳本加載Cookie刷新頁面確認登錄態(tài)還在。這段測試的價值在于排除所有Cookie和會話層面的問題而且隨時能做不依賴車次時間。第二段測查詢隨便選一個非熱門線路比如北京到石家莊跑10次查詢循環(huán)觀察響應時間、解析結果、退避邏輯是否正確。重點看兩個指標平均響應時間是否在1秒內連續(xù)查詢多次后是否出現(xiàn)超時或驗證碼。第三段測提交找一個有余票的普通車次把腳本流程走到“提交訂單”但不要支付驗證到確認訂單頁面就手動終止。這一步能檢查從車次定位到乘客勾選再到訂單確認的全鏈路是否通暢。有一個我個人的習慣分享給你在正式搶票前把車次方向換成反方向試一次——比如你要搶北京到上海就先跑一次上海到北京的查詢提交流程。反向車次的余票通常充足更容易完整走通流程也更容易暴露提交環(huán)節(jié)的隱患。確認三段全通實戰(zhàn)時你才有底氣把腳本掛在那里去干別的事。另外建議每次實戰(zhàn)前更新一次station_name.js的緩存12306偶爾會新增站點、調整編號用舊緩存查新站名會直接查不到票。這套方案的價值不只在搶票這件事本身。你把登錄態(tài)管理、輪詢退避、顯式等待、頁面加載策略這些細節(jié)吃透換成盯演唱會門票、驗證碼短信、秒殺場景底層思路都能復用。對我來說每次起售日蹲在電腦前看著腳本代替我做那些重復動作自己只負責處理驗證碼和最終支付那種“工具就位、邏輯閉環(huán)”的踏實感比搶到票本身更有成就感。希望你也能在調試這套腳本的過程中把Selenium從“聽說過”變成“用得順手”。好這套方案就講到這希望幫到你。本文還有配套的精品資源點擊獲取