1. 先把需求拆開看自動(dòng)加價(jià)到底在跟什么賽跑做競(jìng)拍類頻道的自動(dòng)化第一步永遠(yuǎn)不是寫代碼而是把人手動(dòng)出價(jià)這件事拆成一條時(shí)間線。我接觸過的限時(shí)競(jìng)拍頻道本質(zhì)上是一個(gè)高頻刷新的列表頁(yè)加上一個(gè)出價(jià)表單商品有當(dāng)前價(jià)、最小加價(jià)幅度、剩余時(shí)間、出價(jià)次數(shù)限制用戶在倒計(jì)時(shí)結(jié)束前提交一個(gè)更高的價(jià)格服務(wù)端按價(jià)高者得、同價(jià)先到先得的規(guī)則判定。人手動(dòng)做的動(dòng)作是盯倒計(jì)時(shí)、算價(jià)格、點(diǎn)加價(jià)、填金額、確認(rèn)、看回執(zhí)。這五步在網(wǎng)頁(yè)上大概要花三到六秒而在最后十秒里每一次刷新都可能出現(xiàn)新對(duì)手人的手速和注意力就成了瓶頸。自動(dòng)加價(jià)腳本要解決的正是這個(gè)瓶頸讓程序在規(guī)則允許的范圍內(nèi)替人完成盯盤 算價(jià) 提交 校驗(yàn)這一套循環(huán)把響應(yīng)時(shí)間從秒級(jí)壓到百毫秒級(jí)同時(shí)用預(yù)算上限和加價(jià)階梯把手滑多打一個(gè)零這種災(zāi)難性失誤擋在門外。它適合兩類人參考一類是想系統(tǒng)學(xué)習(xí)網(wǎng)頁(yè)自動(dòng)化、狀態(tài)機(jī)設(shè)計(jì)、時(shí)間同步這些通用技能的開發(fā)者另一類是經(jīng)常在競(jìng)拍頻道里被人最后一秒截胡、想搞明白對(duì)面到底是怎么做到的的普通用戶。哪怕你最后決定不寫腳本把本文的延遲賬和時(shí)間窗口那部分看懂手動(dòng)出價(jià)的成功率也會(huì)有肉眼可見的提升。需要提前把話說在前面這類腳本屬于典型的平臺(tái)規(guī)則敏感型工具。任何競(jìng)拍頻道在用戶協(xié)議里都會(huì)寫清楚是否允許自動(dòng)化提交、請(qǐng)求頻率上限是多少、異常行為會(huì)怎么處理。我寫這個(gè)東西的定位始終是技術(shù)練習(xí)和小范圍自用跑之前一定先去讀一遍頻道的規(guī)則頁(yè)把請(qǐng)求間隔放到明顯低于限制閾值的水平遇到驗(yàn)證環(huán)節(jié)就立刻停下轉(zhuǎn)人工。下面的所有實(shí)現(xiàn)都建立在這個(gè)前提上。1.1 三條時(shí)間線本地時(shí)間、服務(wù)端時(shí)間、頁(yè)面渲染時(shí)間很多人第一次寫這類腳本會(huì)理所當(dāng)然地認(rèn)為我本地電腦顯示還剩 3 秒那就是還剩 3 秒。實(shí)測(cè)下來(lái)這個(gè)假設(shè)能把人坑到懷疑人生。一次出價(jià)從你按下回車到服務(wù)端記錄中間至少穿過三段不同步的時(shí)間本地系統(tǒng)時(shí)鐘、服務(wù)端判定截止的時(shí)鐘、以及頁(yè)面倒計(jì)時(shí)組件自己渲染出來(lái)的那個(gè)數(shù)字。這三者之間任意兩個(gè)都可能差幾百毫秒到幾秒。我做過一組粗糙但足夠說明問題的測(cè)量拿同一臺(tái)機(jī)器連續(xù) 50 次請(qǐng)求一個(gè)返回服務(wù)端時(shí)間戳的公開接口記錄往返時(shí)延RTT并取中位數(shù)同時(shí)對(duì)比本地時(shí)鐘。結(jié)果是本地時(shí)鐘比服務(wù)端快了 1.8 秒而這個(gè)偏差在兩天內(nèi)還漂移了 0.4 秒。也就是說如果我按本地倒計(jì)時(shí)還剩 1 秒去提交實(shí)際到達(dá)服務(wù)端時(shí)可能已經(jīng)超時(shí) 0.8 秒反過來(lái)如果本地慢我會(huì)提前提交價(jià)格暴露給對(duì)手被反超的概率大增。正確的做法是把截止時(shí)刻統(tǒng)一換算到服務(wù)端時(shí)間軸上。具體是多次采樣求 RTT 中位數(shù)用發(fā)出請(qǐng)求的本地時(shí)間 RTT/2近似服務(wù)端收到請(qǐng)求的本地時(shí)刻再和服務(wù)端返回的時(shí)間戳相減得到一個(gè) offset。之后所有決策都用本地時(shí)間 offset當(dāng)作服務(wù)端現(xiàn)在幾點(diǎn)。這件事聽起來(lái)很工程化但它決定了你后面所有的窗口計(jì)算有沒有意義。時(shí)間源典型誤差影響處理方式本地系統(tǒng)時(shí)鐘幾百毫秒到數(shù)秒會(huì)漂移截止判斷整體偏移用 offset 校正不直接信本地時(shí)間服務(wù)端時(shí)間接口受 RTT 影響單次采樣抖動(dòng)大offset 估不準(zhǔn)多次采樣取中位數(shù)剔除異常值頁(yè)面倒計(jì)時(shí)組件渲染延遲 自身刷新粒度常見 1 秒一跳看起來(lái)還剩 1 秒其實(shí)不到 1 秒只作參考不作判定依據(jù)提交請(qǐng)求的鏈路耗時(shí)50ms 到 800ms隨網(wǎng)絡(luò)波動(dòng)踩線提交容易超時(shí)預(yù)留安全余量絕不貼著零點(diǎn)提交還有一個(gè)容易被忽略的點(diǎn)頁(yè)面倒計(jì)時(shí)往往是一秒一跳的粗粒度組件它顯示1的時(shí)候真實(shí)剩余可能是 1.0 秒也可能是 0.01 秒。你要是指望讀這個(gè)數(shù)字做精確決策那基本等于閉著眼睛踩點(diǎn)。我的做法是把商品詳情里能拿到的結(jié)束時(shí)間戳當(dāng)成唯一真相倒計(jì)時(shí)組件只用來(lái)給人看。1.2 技術(shù)選型純 requests 還是瀏覽器自動(dòng)化選型這件事我糾結(jié)過很久最后的結(jié)論是看頻道的出價(jià)接口長(zhǎng)什么樣。如果出價(jià)是一個(gè)干凈的 POST 表單參數(shù)固定、沒有動(dòng)態(tài)簽名、沒有風(fēng)控令牌那requests加一個(gè)會(huì)話對(duì)象就夠了快、穩(wěn)、資源占用低一次出價(jià)能壓到幾十毫秒。但現(xiàn)實(shí)中大部分競(jìng)拍頻道的出價(jià)請(qǐng)求都帶著一堆動(dòng)態(tài)參數(shù)有的有時(shí)效性簽名有的綁定了頁(yè)面加載時(shí)下發(fā)的令牌有的還會(huì)校驗(yàn)請(qǐng)求頭的順序和來(lái)源。這種情況下硬啃接口維護(hù)成本會(huì)高到離譜一次前端改版就能讓你通宵。所以我更推薦瀏覽器自動(dòng)化方案用 Playwright 這類工具驅(qū)動(dòng)一個(gè)真實(shí)瀏覽器上下文它能天然帶上前端生成的所有參數(shù)元素定位失敗時(shí)還能截圖排查調(diào)試體驗(yàn)好太多。代價(jià)是慢——一次頁(yè)面操作動(dòng)輒 100 到 300 毫秒啟動(dòng)瀏覽器也要一兩秒。解決辦法是長(zhǎng)駐頁(yè)面 最小操作瀏覽器只啟動(dòng)一次頁(yè)面掛著不關(guān)出價(jià)時(shí)只做點(diǎn)開加價(jià)框、填數(shù)字、點(diǎn)確認(rèn)這三個(gè)動(dòng)作不做整頁(yè)刷新靠頁(yè)面自身的輪詢更新價(jià)格。下面這張表是我自己權(quán)衡時(shí)用的可以直接抄方案單次出價(jià)耗時(shí)抗改版能力調(diào)試難度適用場(chǎng)景純 HTTP 客戶端30–120ms弱參數(shù)一變就廢中需要抓包分析接口穩(wěn)定、參數(shù)靜態(tài)的內(nèi)部練習(xí)環(huán)境瀏覽器自動(dòng)化長(zhǎng)駐頁(yè)面150–400ms強(qiáng)跟隨前端渲染低可截圖可回放大多數(shù)真實(shí)競(jìng)拍頁(yè)面瀏覽器自動(dòng)化每次新開頁(yè)1.5–3s強(qiáng)低不推薦太慢移動(dòng)端協(xié)議模擬快極弱簽名復(fù)雜極高不建議投入我最終選的是第二行。理由很直白競(jìng)拍場(chǎng)景下你要的是穩(wěn)不是最快?？?200 毫秒但每周修一次簽名算法長(zhǎng)期算下來(lái)是虧的。而且長(zhǎng)駐頁(yè)面的方案有個(gè)額外好處——頁(yè)面上的價(jià)格變動(dòng)是真實(shí)推送的你不需要自己去輪詢接口猜價(jià)格減少了被發(fā)現(xiàn)異常頻率的可能。1.3 先把邊界畫清楚什么能自動(dòng)化什么必須人工這一節(jié)我想寫得重一點(diǎn)因?yàn)橐娺^太多人把技術(shù)問題做成賬號(hào)問題。我的原則是三條硬線第一規(guī)則沒寫允許的就當(dāng)不允許。用戶協(xié)議里沒有明確說可以自動(dòng)化提交那就只在自己的測(cè)試環(huán)境里跑流程不連真實(shí)競(jìng)拍。這不是道德說教是純粹的風(fēng)險(xiǎn)收益計(jì)算——為了省幾十秒賠進(jìn)去一個(gè)用了多年的賬號(hào)賬算不過來(lái)。第二遇到驗(yàn)證環(huán)節(jié)立刻停。不管出現(xiàn)的是滑塊、點(diǎn)選還是別的人機(jī)校驗(yàn)程序一律進(jìn)入暫停態(tài)把截圖和上下文寫到日志里等人來(lái)處理。任何試圖自動(dòng)繞過校驗(yàn)的思路我都不碰也不建議你碰這條路的技術(shù)收益遠(yuǎn)小于它帶來(lái)的不確定性。第三頻率必須明顯低于閾值。我的默認(rèn)配置是觀察輪詢 800 毫秒一次出價(jià)動(dòng)作之間強(qiáng)制 1.5 秒冷卻單場(chǎng)競(jìng)拍最多出價(jià) 8 次。這些數(shù)字都刻意留了很大余量。跑得快不等于跑得久這條在自動(dòng)化里是鐵律。把這三條寫進(jìn)代碼比寫任何花哨的算法都重要。我甚至建議把它們做成配置文件頂部的常量每次運(yùn)行前掃一眼形成肌肉記憶。2. 項(xiàng)目骨架從零搭一個(gè)能長(zhǎng)期維護(hù)的出價(jià)器一個(gè)能用的腳本和一個(gè)能維護(hù)的腳本差別全在骨架。我第一版是兩百行的單文件所有邏輯糊在一起結(jié)果改一個(gè)參數(shù)要通讀全文第二次跑就出錯(cuò)。后來(lái)重構(gòu)成配置、驅(qū)動(dòng)、決策、日志四層才真正跑順。這一章講骨架怎么搭重點(diǎn)解釋每一層為什么這么切。2.1 依賴清單與目錄結(jié)構(gòu)依賴我刻意壓到最少。核心只有三個(gè)playwright負(fù)責(zé)瀏覽器驅(qū)動(dòng)pyyaml讀配置loguru或者標(biāo)準(zhǔn)庫(kù)logging做結(jié)構(gòu)化日志。時(shí)間同步那塊用標(biāo)準(zhǔn)庫(kù)time和statistics就夠不需要額外裝 NTP 客戶端。刻意不引入重量級(jí)框架是因?yàn)檫@類腳本生命周期短、改動(dòng)頻繁依賴越少越好修。目錄結(jié)構(gòu)是這樣切的auction_bot/ ├── config/ │ ├── default.yaml # 默認(rèn)參數(shù)進(jìn)版本庫(kù) │ └── local.yaml # 個(gè)人參數(shù)與會(huì)話信息不進(jìn)版本庫(kù) ├── core/ │ ├── browser.py # 瀏覽器生命周期與頁(yè)面句柄管理 │ ├── timesync.py # 服務(wù)端時(shí)間偏移估算 │ ├── bidder.py # 出價(jià)動(dòng)作封裝 │ └── state.py # 狀態(tài)機(jī) ├── logs/ # 按場(chǎng)次分文件 ├── shots/ # 失敗截圖 └── run.py # 入口local.yaml單獨(dú)放、并且加進(jìn)忽略列表這一點(diǎn)必須強(qiáng)調(diào)。里面會(huì)有會(huì)話憑據(jù)、預(yù)算上限這些敏感內(nèi)容一旦混進(jìn)版本庫(kù)或者被同步到公共位置麻煩就大了。我的習(xí)慣是連logs/和shots/也一并忽略因?yàn)樗鼈儼?yè)面快照信息量不小。2.2 配置與憑據(jù)管理別把會(huì)話寫死在代碼里配置文件我分兩層。default.yaml放邏輯參數(shù)比如加價(jià)階梯、冷卻時(shí)間、安全余量、重試次數(shù)這些是可以公開的、跟具體賬號(hào)無(wú)關(guān)的東西。local.yaml放個(gè)人參數(shù)比如預(yù)算上限、單場(chǎng)最大出價(jià)次數(shù)、目標(biāo)商品的關(guān)鍵詞過濾條件。會(huì)話憑據(jù)也就是瀏覽器上下文里的登錄態(tài)我連 yaml 都不放單獨(dú)走環(huán)境變量或者一個(gè)獨(dú)立的、權(quán)限收緊的本地文件程序啟動(dòng)時(shí)讀一次用完不落盤。# core/config.py 節(jié)選 import os, yaml from pathlib import Path BASE Path(__file__).resolve().parent.parent def load_config(): with open(BASE / config / default.yaml, r, encodingutf-8) as f: cfg yaml.safe_load(f) local_path BASE / config / local.yaml if local_path.exists(): with open(local_path, r, encodingutf-8) as f: local yaml.safe_load(f) or {} cfg.update(local) # 預(yù)算上限必須存在且為正數(shù)缺失直接拒絕啟動(dòng) budget cfg.get(budget_limit) if not isinstance(budget, (int, float)) or budget 0: raise ValueError(budget_limit 未配置或非法拒絕啟動(dòng)) cfg[poll_interval] max(cfg.get(poll_interval, 0.8), 0.8) cfg[bid_cooldown] max(cfg.get(bid_cooldown, 1.5), 1.5) return cfg這段代碼里有兩個(gè)刻意為之的設(shè)計(jì)。第一個(gè)是預(yù)算上限的強(qiáng)制校驗(yàn)配置缺失就拋異常寧可啟動(dòng)失敗也不能帶著None 當(dāng)上限的邏輯上路——Python 里None參與比較會(huì)直接報(bào)錯(cuò)但如果哪天有人寫成bid (limit or 999999)那就是深淵。第二個(gè)是輪詢間隔和冷卻時(shí)間的下限鉗制用max()兜底防止哪天手快把間隔改成 0.05 秒跑出一個(gè)自己都害怕的請(qǐng)求量。注意配置里凡是涉及金額的字段一律用整數(shù)表示最小貨幣單位的倍數(shù)比如統(tǒng)一乘 100 存成整數(shù)不要用浮點(diǎn)數(shù)。競(jìng)拍價(jià)格用 float 累加跑幾輪之后你會(huì)看到 199.99999999999997 這種數(shù)字出價(jià)表單填不進(jìn)去調(diào)試能耗掉半小時(shí)。2.3 狀態(tài)機(jī)設(shè)計(jì)觀察、決策、出價(jià)、回溯第一版腳本之所以失控是因?yàn)樗且淮畐hile True加if隨時(shí)可能卡在某個(gè)分支里出不來(lái)。改成顯式狀態(tài)機(jī)之后邏輯一下子清晰了。我定義了六個(gè)狀態(tài)狀態(tài)含義出口條件IDLE等待目標(biāo)商品進(jìn)入視野發(fā)現(xiàn)符合過濾條件的商品WATCH盯盤輪詢當(dāng)前價(jià)與剩余時(shí)間剩余時(shí)間進(jìn)入決策窗口DECIDE計(jì)算是否值得出價(jià)、出多少得出出價(jià)金額或放棄BID執(zhí)行出價(jià)動(dòng)作收到明確回執(zhí)成功/失敗/未知VERIFY出價(jià)后核對(duì)頁(yè)面價(jià)格是否變化價(jià)格更新或超時(shí)HALT暫停等待人工人工干預(yù)后回到WATCH關(guān)鍵在VERIFY這個(gè)狀態(tài)。很多人出價(jià)完就完事實(shí)際上點(diǎn)下去和成交之間差著十萬(wàn)八千里可能按鈕沒點(diǎn)到、可能表單校驗(yàn)拒絕、可能提交成功但頁(yè)面沒刷新。不做回驗(yàn)?zāi)阌肋h(yuǎn)不知道自己是真出價(jià)了還是白點(diǎn)了一下?；仳?yàn)的方式很簡(jiǎn)單——出價(jià)前記下當(dāng)前價(jià)p0出價(jià)后輪詢頁(yè)面價(jià)格若變成自己出的價(jià)p1且p1 p0判定成功若 3 秒內(nèi)價(jià)格沒變判定失敗回到DECIDE重算而不是無(wú)腦重試。狀態(tài)機(jī)的另一個(gè)價(jià)值是把異常變成一等公民。每個(gè)狀態(tài)里發(fā)生的異常都收斂到HALT或者帶退避的重試不會(huì)出現(xiàn)異常把主循環(huán)打穿的情況。這一點(diǎn)在后半夜無(wú)人值守的時(shí)候尤其重要——你睡了腳本抽風(fēng)第二天起來(lái)看日志一片空白那才是最難受的。3. 核心實(shí)現(xiàn)把每一次加價(jià)都做對(duì)骨架搭好之后真正決定成敗的是三個(gè)細(xì)節(jié)加價(jià)金額怎么算、時(shí)間窗口怎么卡、頁(yè)面元素掛掉怎么辦。這一章逐個(gè)拆。3.1 出價(jià)階梯別用當(dāng)前價(jià) 最小幅度這種樸素策略新手最容易寫的就是next_price current_price min_increment邏輯上沒錯(cuò)但實(shí)戰(zhàn)里幾乎必輸。原因有兩個(gè)一是每一輪都只加最小幅度會(huì)把自己拖進(jìn)一場(chǎng)無(wú)休止的拉鋸戰(zhàn)出價(jià)次數(shù)很快耗盡二是在最后時(shí)刻最小幅度往往扛不住對(duì)手一次大跳你加一塊人家加五十你的次數(shù)白費(fèi)。我用的是一套分段階梯核心思路是前期小步試探、中期跟隨、末期一次性封頂。假設(shè)最小加價(jià)幅度是m剩余時(shí)間是t剩余時(shí)間加價(jià)策略出價(jià)次數(shù)預(yù)算意圖 5 分鐘當(dāng)前價(jià) m最多 2 次試探確認(rèn)對(duì)手是否活躍60s – 5min當(dāng)前價(jià) 2m且不超過心理價(jià) 80%最多 3 次跟隨不主動(dòng)抬價(jià)10s – 60s當(dāng)前價(jià) 3m且不超過心理價(jià) 95%最多 2 次搶占位 10s一次性出到心理價(jià)上限1 次封頂不給對(duì)手反超窗口這里有個(gè)反直覺的點(diǎn)末期出到上限看起來(lái)是多花錢實(shí)際上是省錢。因?yàn)楦?jìng)價(jià)的核心成本不是最終價(jià)而是你出了很多次價(jià)最后還是輸了這種沉沒成本。一次性封頂把博弈壓縮成一錘子買賣對(duì)手要么認(rèn)要么抬到超過你的上限——而超過上限的那部分本來(lái)也不該由你承擔(dān)。代碼上我把它寫成一個(gè)純函數(shù)輸入當(dāng)前價(jià)、剩余秒數(shù)、心理價(jià)、已出價(jià)次數(shù)輸出None不出價(jià)或者具體金額。純函數(shù)的好處是能單元測(cè)試我把過去幾十場(chǎng)的手動(dòng)記錄當(dāng)成用例喂進(jìn)去驗(yàn)證每次的決策是否符合預(yù)期。# core/bidder.py 節(jié)選 def decide_bid(current, remaining_sec, ceiling, used_count, min_inc, ladder): 返回 None 表示本輪不出價(jià)返回整數(shù)金額表示出價(jià)。 if used_count ladder[max_total_bids]: return None if current is None or current 0: return None stage None for s in ladder[stages]: if remaining_sec s[min_remaining]: stage s break if stage is None: return None if used_count stage[max_bids]: return None if stage[mode] ceiling: target ceiling else: target current min_inc * stage[steps] cap int(ceiling * stage[ceiling_ratio]) target min(target, cap) # 金額對(duì)齊到最小單位避免出現(xiàn)小數(shù) target int(round(target / min_inc)) * min_inc if target current or target ceiling: return None return targetmin_inc在這里既是最小加價(jià)幅度也是金額對(duì)齊的網(wǎng)格。為什么一定要對(duì)齊很多競(jìng)拍頁(yè)面的輸入框只接受以最小幅度為步長(zhǎng)的金額你填 101.37 會(huì)被前端攔下來(lái)或者提交后被服務(wù)端修正成 101導(dǎo)致我以為我出 101.37實(shí)際出的是 101的誤差。這種誤差在最后幾秒是致命的。3.2 時(shí)間同步最后三秒到底該怎么踩時(shí)間同步我單獨(dú)拎出來(lái)講因?yàn)樗钦麄€(gè)項(xiàng)目里最容易做錯(cuò)、做錯(cuò)之后最難發(fā)現(xiàn)的部分。我的實(shí)現(xiàn)是這樣的# core/timesync.py 節(jié)選 import time, statistics, requests def estimate_offset(url, samples7): offsets [] for _ in range(samples): t0 time.time() try: r requests.get(url, timeout2) server_ms int(r.json()[server_time_ms]) except Exception: continue t1 time.time() rtt t1 - t0 # 用 RTT 的一半近似單程延遲 approx_server_now t0 rtt / 2 offsets.append(server_ms / 1000.0 - approx_server_now) time.sleep(0.15) if not offsets: raise RuntimeError(時(shí)間同步失敗拒絕啟動(dòng)) offsets.sort() # 去掉最高最低各一個(gè)取中位數(shù) core offsets[1:-1] if len(offsets) 5 else offsets return statistics.median(core)幾個(gè)細(xì)節(jié)值得展開。采樣七次是為了讓中位數(shù)有意義太少容易被單次抖動(dòng)帶偏去掉最高最低是防網(wǎng)絡(luò)尖峰sleep(0.15)是為了不把時(shí)間接口打成刷子。最關(guān)鍵的容錯(cuò)是同步失敗直接拒絕啟動(dòng)——帶著錯(cuò)誤的 offset 去踩點(diǎn)比不出價(jià)更糟因?yàn)槟銜?huì)長(zhǎng)期以為自己踩得很準(zhǔn)。有了 offset剩余時(shí)間的計(jì)算就是deadline_ts - (time.time() offset)。至于最后三秒這個(gè)說法我實(shí)測(cè)下來(lái)建議不要真踩三秒而是踩服務(wù)端剩余 6 到 8 秒這個(gè)區(qū)間。原因在 1.1 那張表里寫過提交請(qǐng)求的鏈路耗時(shí)波動(dòng)很大你算的是 3 秒實(shí)際到達(dá)可能是 2.2 秒也可能是 3.8 秒一旦越過零點(diǎn)就是徹底無(wú)效。留 5 秒以上的余量損失的是最后一刻才知道對(duì)手出價(jià)的信息優(yōu)勢(shì)換來(lái)的是這一槍一定打得出去的確定性。在競(jìng)拍里確定性比信息優(yōu)勢(shì)值錢。提示決策窗口的起點(diǎn)不要寫死成固定秒數(shù)而是按你實(shí)測(cè)的提交鏈路耗時(shí)來(lái)定。方法是先在測(cè)試環(huán)境里連續(xù)提交 20 次無(wú)意義的出價(jià)記錄從函數(shù)調(diào)用到頁(yè)面回執(zhí)的耗時(shí)分布取 P95 再加 1 秒安全余量。這個(gè)數(shù)字因人而異我自己環(huán)境里是 4.2 秒別人的網(wǎng)絡(luò)可能是 7 秒。3.3 頁(yè)面元素定位怎么讓它別在關(guān)鍵時(shí)刻掉鏈子瀏覽器自動(dòng)化最脆弱的地方就是元素定位。前端改個(gè) class 名你的page.click(.btn-bid-2)就廢了。我的做法是三級(jí)降級(jí)定位按穩(wěn)定性從高到低排第一級(jí)是文本錨點(diǎn)比如加價(jià)這個(gè)按鈕上的文字。文本通常比 class 穩(wěn)定得多因?yàn)楦奈陌敢弋a(chǎn)品評(píng)審改 class 只是順手的事。第二級(jí)是結(jié)構(gòu)錨點(diǎn)比如包含當(dāng)前價(jià)三個(gè)字的容器里第一個(gè)可點(diǎn)擊的按鈕。第三級(jí)才是帶特征的選擇器比如帶某個(gè)固定># core/browser.py 節(jié)選 async def click_bid_button(page): candidates [ page.get_by_role(button, name加價(jià)), page.get_by_role(button, name出價(jià)), page.locator([data-actionbid]), ] for loc in candidates: try: if await loc.count() 0 and await loc.first.is_enabled(): await loc.first.click(timeout1200) return True except Exception: continue return False這段代碼里timeout1200是刻意的競(jìng)拍場(chǎng)景下寧可快速失敗重試也不要卡在那里等 30 秒默認(rèn)超時(shí)。一次點(diǎn)擊卡住整個(gè)決策窗口就廢了。還有一個(gè)隱蔽的坑頁(yè)面元素存在不等于可用。出價(jià)按鈕在冷卻期內(nèi)往往是存在但disabled的你點(diǎn)上去什么也不發(fā)生程序以為成功了實(shí)際什么都沒提交。所以每次點(diǎn)擊前必須檢查is_enabled()點(diǎn)擊后必須做 3.2 里說的價(jià)格回驗(yàn)。這兩道防線缺一不可。3.4 日志與回放出事之后你得能查日志這塊我吃過虧。第一版只在終端print結(jié)果腳本跑掛了終端一關(guān)什么都沒留下。后來(lái)改成結(jié)構(gòu)化寫入按場(chǎng)次分文件每行一個(gè) JSON字段固定# core/logging_setup.py 節(jié)選 import json, time, pathlib class SessionLogger: def __init__(self, session_id): self.path pathlib.Path(logs) / f{session_id}.jsonl self.path.parent.mkdir(exist_okTrue) self.f open(self.path, a, encodingutf-8) def log(self, event, **kw): rec {ts: round(time.time(), 3), event: event} rec.update(kw) self.f.write(json.dumps(rec, ensure_asciiFalse) \n) self.f.flush() def close(self): self.f.close()必須記的字段有五個(gè)服務(wù)端剩余時(shí)間、當(dāng)前價(jià)、決策結(jié)果、動(dòng)作耗時(shí)、頁(yè)面回執(zhí)。有了這五個(gè)事后能把任何一次失敗完整重放出來(lái)——是決策算錯(cuò)了還是點(diǎn)擊沒生效還是點(diǎn)擊生效了但被服務(wù)端拒絕一眼就能分辨。flush()每次寫入都刷盤看起來(lái)浪費(fèi)但腳本崩潰時(shí)這是唯一能保住最后幾行日志的手段。截圖策略也要有節(jié)流。我的規(guī)則是只在三種情況下截圖——進(jìn)入HALT、點(diǎn)擊后 3 秒內(nèi)價(jià)格沒變、以及每場(chǎng)競(jìng)拍結(jié)束時(shí)各來(lái)一張。無(wú)腦每輪截圖會(huì)把磁盤塞滿而且大部分是無(wú)用信息。4. 跑一遍完整流程從冷啟動(dòng)到收工紙上談完這一章把整個(gè)流程串起來(lái)包括啟動(dòng)前的自檢、一次完整競(jìng)拍的過程記錄、以及參數(shù)怎么調(diào)。所有內(nèi)容都可以直接照著復(fù)現(xiàn)。4.1 冷啟動(dòng)自檢清單我現(xiàn)在每次啟動(dòng)前都會(huì)過一遍這張表五分鐘的事能省掉一整晚的返工檢查項(xiàng)判定標(biāo)準(zhǔn)不通過的后果時(shí)間同步連續(xù) 3 次 offset 估算標(biāo)準(zhǔn)差 300ms踩點(diǎn)全錯(cuò)登錄態(tài)打開目標(biāo)頁(yè)能正常顯示價(jià)格而非登錄框全程白跑元素定位三級(jí)降級(jí)定位全部試一遍至少兩級(jí)可用關(guān)鍵時(shí)刻點(diǎn)不到預(yù)算配置上限為正整數(shù)且已對(duì)齊最小加價(jià)幅度出價(jià)被前端拒絕冷卻與間隔不低于默認(rèn)值請(qǐng)求量異常日志可寫寫入并讀回一條測(cè)試記錄出事無(wú)記錄磁盤余量截圖目錄剩余空間 2GB寫滿后崩潰其中元素定位三級(jí)都試一遍這一步我建議做成啟動(dòng)時(shí)的預(yù)熱函數(shù)跑一次真實(shí)的無(wú)害操作比如點(diǎn)開加價(jià)框再關(guān)掉確認(rèn)整條交互鏈通。這比等到最后十秒才發(fā)現(xiàn)按鈕找不到要好太多。4.2 一次完整競(jìng)拍的現(xiàn)場(chǎng)記錄拿一場(chǎng)模擬環(huán)境里的競(jìng)拍做記錄商品當(dāng)前價(jià) 120最小加價(jià) 5心理價(jià) 200最大出價(jià)次數(shù) 8。時(shí)間線如下T-6min進(jìn)入WATCH當(dāng)前價(jià) 120無(wú)人加價(jià)。狀態(tài)機(jī)判定剩余時(shí)間 5min策略為試探但used_count0且當(dāng)前價(jià)低于心理價(jià) 60%先不出手繼續(xù)觀察。T-4min價(jià)格跳到 135說明有對(duì)手。剩余時(shí)間進(jìn)入 60s–5min 檔steps2算出135 10 145但 145 超過心理價(jià)的 80%160嗎沒有。出價(jià) 145耗時(shí) 280ms回驗(yàn)成功used_count1。T-2min價(jià)格被抬到 155。重算155 10 165超過 160 的 80% 上限被cap截?cái)喑?160實(shí)際出價(jià) 160?；仳?yàn)成功used_count2。T-45s價(jià)格 175。進(jìn)入 10s–60s 檔steps3175 15 190超過心理價(jià) 95%190嗎剛好等于。出價(jià) 190used_count3。T-12s價(jià)格被抬到 195。剩余時(shí)間進(jìn)入 10s 檔但我的實(shí)際配置是 8s 才封頂所以此刻還在上一檔。重算195 15 210超過上限返回None不出價(jià)等封頂窗口。T-7s進(jìn)入封頂檔一次出到 200。但 200 小于當(dāng)前價(jià) 195 加上最小幅度 5 等于 200正好等于可以出。出價(jià) 200耗時(shí) 310ms回驗(yàn)成功used_count4。T-2s頁(yè)面價(jià)格停在 200。倒計(jì)時(shí)歸零競(jìng)拍結(jié)束判定成交。整場(chǎng)總共出價(jià) 4 次全部成功沒有一次浪費(fèi)在無(wú)效點(diǎn)擊上。對(duì)比我最早那版每次加最小幅度的寫法同樣的場(chǎng)景要出價(jià) 12 次以上而且在 T-30s 之后就會(huì)被拖進(jìn)拉鋸最后大概率輸。值得單獨(dú)說的一點(diǎn)T-12s 那一步返回None是正確的行為。當(dāng)時(shí)價(jià)格 195我要出就得 210超過心理價(jià)不出。很多人在這里會(huì)舍不得覺得都跟到這一步了多出 10 塊無(wú)所謂。這就是典型的沉沒成本陷阱規(guī)則一旦破了下次就是多出 50、多出 100。把心理價(jià)寫死在配置里、由代碼執(zhí)行比自己跟自己講道理有效得多。4.3 參數(shù)調(diào)優(yōu)三個(gè)數(shù)字決定成敗調(diào)參這件事沒有通用答案但有明確的調(diào)法。第一個(gè)是poll_interval輪詢間隔。太小請(qǐng)求量上去了風(fēng)險(xiǎn)大太大價(jià)格更新滯后你看到的是舊價(jià)。我的經(jīng)驗(yàn)值是 800ms 到 1.2s。競(jìng)拍頻道的價(jià)格變動(dòng)通常不會(huì)快到需要 100ms 級(jí)別捕捉800ms 足夠你在一秒內(nèi)看到變化。如果你發(fā)現(xiàn)經(jīng)常看到新價(jià)格時(shí)已經(jīng)被人抬了兩輪那說明該調(diào)的是策略而不是間隔。第二個(gè)是bid_cooldown出價(jià)冷卻。這個(gè)純粹是安全參數(shù)我設(shè) 1.5 秒起步。它的作用是防止決策邏輯出錯(cuò) → 瘋狂出價(jià)這種災(zāi)難。哪怕代碼里有 bug1.5 秒的強(qiáng)制冷卻也能保證一場(chǎng)競(jìng)拍最多出幾十次不至于失控。第三個(gè)是ceiling心理價(jià)。這個(gè)不是技術(shù)參數(shù)是心理參數(shù)。我的建議是開場(chǎng)前就定死寫進(jìn)配置運(yùn)行中絕不修改。定法很簡(jiǎn)單查一下同類商品近期的成交記錄取一個(gè)你覺得超過就不值的數(shù)。注意別定成我猜別人會(huì)出到多少那是博弈不是估值。調(diào)參的順序也有講究。先固定冷卻和間隔不動(dòng)只調(diào)策略階梯用歷史記錄回放驗(yàn)證決策是否符合預(yù)期策略穩(wěn)定了再去動(dòng)間隔和冷卻。反過來(lái)調(diào)你會(huì)分不清是策略問題還是節(jié)奏問題。5. 常見問題與排查實(shí)錄這一章全是踩出來(lái)的。5.1 故障速查表現(xiàn)象最可能的原因排查動(dòng)作處理價(jià)格一直不更新頁(yè)面停留在舊視圖輪詢失效看日志里current是否恒定觸發(fā)一次輕量刷新重建頁(yè)面句柄點(diǎn)擊按鈕無(wú)反應(yīng)按鈕disabled或不在視口內(nèi)截圖看按鈕狀態(tài)檢查is_enabled()必要時(shí)滾動(dòng)到可視區(qū)出價(jià)成功但價(jià)格沒變提交成功、頁(yè)面未刷新或價(jià)格被別人立刻超對(duì)比日志中的p0與回執(zhí)等 3 秒重查仍不變則判定失敗時(shí)間窗口算錯(cuò)提前/延后提交offset 漂移或未同步看 offset 的歷史值每 30 分鐘重算一次 offset程序中途靜默退出未捕獲異常打穿了主循環(huán)看日志最后一行給每個(gè)狀態(tài)套 try收斂到HALT日志寫了但沒內(nèi)容緩沖未刷盤ls -l看文件大小強(qiáng)制flush()輸入金額被拒未對(duì)齊最小加價(jià)幅度或含小數(shù)打印實(shí)際提交值用整數(shù)運(yùn)算 網(wǎng)格對(duì)齊長(zhǎng)時(shí)間無(wú)任何出價(jià)決策函數(shù)一直返回None單測(cè)decide_bid的輸入輸出檢查ceiling和used_count是否已耗盡這張表我基本都是按先看日志、再看截圖、最后看代碼的順序查。絕大多數(shù)問題在第一步就能定位因?yàn)槿罩纠锬俏鍌€(gè)字段的設(shè)計(jì)初衷就是讓人不用讀代碼也能判斷問題出在哪個(gè)環(huán)節(jié)。5.2 我踩過的坑與幾條私房經(jīng)驗(yàn)坑一以為瀏覽器上下文能一勞永逸。長(zhǎng)駐頁(yè)面確實(shí)快但它是會(huì)腐化的——頁(yè)面在后臺(tái)久了前端定時(shí)器被瀏覽器節(jié)流價(jià)格推送延遲到十幾秒一次。我第一次遇到這個(gè)現(xiàn)象時(shí)盯著日志看了半小時(shí)以為是接口掛了。后來(lái)發(fā)現(xiàn)只要頁(yè)面在前臺(tái)可見節(jié)流就消失。解決辦法很簡(jiǎn)單把瀏覽器窗口保持在可見狀態(tài)不最小化或者定期觸發(fā)一次極小的時(shí)間戳更新讓頁(yè)面保持活躍。這個(gè)坑常規(guī)文檔里基本不會(huì)寫但它能讓你在無(wú)人值守時(shí)全盤失效?？佣靡粋€(gè)微信號(hào)式的重試毀掉整場(chǎng)。早期我給點(diǎn)擊加了retry3看起來(lái)穩(wěn)健實(shí)際結(jié)果是點(diǎn)一下沒反應(yīng)就點(diǎn)三下三下都成功提交出價(jià)次數(shù)瞬間廢掉兩次而且價(jià)格被自己抬高了兩次。自動(dòng)化的重試必須有冪等判斷——只有確認(rèn)上一次沒生效才允許重試而不是超時(shí)就重試。修正后的做法是點(diǎn)擊超時(shí)后先做價(jià)格回驗(yàn)價(jià)格變了就說明生效了不重試?？尤睦韮r(jià)配置成浮點(diǎn)。前面提過但值得再提一次。199.9這種輸入在很多表單里會(huì)被四舍五入或直接拒絕而你可能跑了一個(gè)小時(shí)才發(fā)現(xiàn)自己的封頂價(jià)從來(lái)沒生效過。一律用整數(shù)一律用最小單位。私房經(jīng)驗(yàn)一先手動(dòng)跑十場(chǎng)再寫腳本。我堅(jiān)持這個(gè)順序。手動(dòng)跑的價(jià)值不是練手速是讓你知道這個(gè)頻道的真實(shí)節(jié)奏——什么時(shí)間點(diǎn)會(huì)有人抬價(jià)、抬多少、抬幾次、有沒有明顯的機(jī)器人行為。這些信息決定了你的階梯參數(shù)怎么設(shè)。跳過這一步直接寫代碼等于閉著眼睛調(diào)參。私房經(jīng)驗(yàn)二給腳本加一個(gè)心跳輸出。每 30 秒往日志寫一行heartbeat帶上當(dāng)前狀態(tài)、剩余時(shí)間、當(dāng)前價(jià)。事后看日志你能一眼看出腳本是在幾點(diǎn)幾分卡死的而不是從最后一個(gè)業(yè)務(wù)事件去猜。私房經(jīng)驗(yàn)三把不出價(jià)當(dāng)成一個(gè)正常結(jié)果。新手總覺得腳本跑起來(lái)了就必須出價(jià)看到None就想去改邏輯。實(shí)際上競(jìng)拍里最省錢的操作就是不出價(jià)。如果你的日志里 80% 的決策都是None說明你的上限設(shè)得合理說明策略在克制。反過來(lái)每場(chǎng)都出滿 8 次那大概率是階梯設(shè)得太激進(jìn)或者心理價(jià)定得太松。私房經(jīng)驗(yàn)四單場(chǎng)結(jié)束后立刻歸檔。把這場(chǎng)的完整日志、截圖、最終成交價(jià)整理成一個(gè) JSON 存起來(lái)。跑夠二三十場(chǎng)你就有了自己的數(shù)據(jù)集可以回頭算我的封頂策略平均多花了多少錢哪些檔位的出價(jià)其實(shí)是浪費(fèi)。這件事帶來(lái)的收益遠(yuǎn)大于再優(yōu)化 100 毫秒的響應(yīng)速度。最后分享一個(gè)我在實(shí)際使用中發(fā)現(xiàn)的小規(guī)律絕大多數(shù)人輸在最后十秒改主意而不是輸在技術(shù)。手動(dòng)出價(jià)的時(shí)候看著價(jià)格往上跳人會(huì)不由自主地把心理價(jià)往上抬抬完之后又后悔。腳本最大的價(jià)值可能不是那 200 毫秒的速度優(yōu)勢(shì)而是它不會(huì)改主意——你寫進(jìn)去的那個(gè)數(shù)字它會(huì)老老實(shí)實(shí)地執(zhí)行到底。從這個(gè)角度看先把策略想清楚再動(dòng)手寫代碼順序反了的話再精巧的自動(dòng)化也只是把你自己的猶豫放大得更有殺傷力。