很多人第一次聽到robotbilibili這個(gè)詞第一反應(yīng)是這不就是一個(gè)掛著 B 站 API 的簽到腳本嗎如果你抱著這個(gè)預(yù)期去讀代碼會發(fā)現(xiàn)它遠(yuǎn)不止一個(gè)腳本。它本質(zhì)上是一套把 B 站賬號重復(fù)操作拆解成可調(diào)度任務(wù)的自動(dòng)化框架登錄態(tài)管理、請求客戶端、任務(wù)抽象、定時(shí)調(diào)度、異常處理和日志監(jiān)控每一層都可以獨(dú)立替換和擴(kuò)展。先說一個(gè)明確判斷robotbilibili這類項(xiàng)目的核心價(jià)值不是和平臺風(fēng)控賽跑也不是幫你實(shí)現(xiàn)那些灰色操作而是把確定性的重復(fù)勞動(dòng)交給代碼讓人把時(shí)間放在內(nèi)容、策略和異常處理上。只有先理解這個(gè)邊界后面的代碼寫起來才有意義。這篇文章我會從真實(shí)開發(fā)痛點(diǎn)出發(fā)先講清楚 B 站自動(dòng)化機(jī)器人要解決什么問題再給出一套完整的 Python 工程示例涵蓋Cookie登錄態(tài)管理、請求客戶端封裝、任務(wù)抽象、定時(shí)調(diào)度、運(yùn)行驗(yàn)證和常見問題排查。讀完以后你不只是會復(fù)制腳本而是能自己設(shè)計(jì)一套可維護(hù)、可灰度、可回滾的 B 站自動(dòng)化任務(wù)系統(tǒng)。1. 這篇文章真正要解決的問題如果你是 B 站內(nèi)容創(chuàng)作者、賬號運(yùn)營者或者只是把 B 站賬號當(dāng)測試對象的技術(shù)愛好者一定經(jīng)歷過下面這些場景每天早上要登錄后臺看一遍數(shù)據(jù)記錄播放、點(diǎn)贊、評論變化。視頻發(fā)布后要在固定時(shí)間點(diǎn)檢查評論、回復(fù)私信。直播前要發(fā)動(dòng)態(tài)預(yù)告直播后要整理數(shù)據(jù)。多個(gè)賬號需要重復(fù)執(zhí)行相同的維護(hù)操作。手動(dòng)操作最大的問題不是累而是不可沉淀。今天手動(dòng)做了一遍明天還要再做一遍后天依然如此。操作步驟沒有存檔數(shù)據(jù)沒有留痕偶爾漏了一次也很難追溯。更有意思的是這些操作絕大多數(shù)是確定性的給定登錄態(tài)調(diào)一個(gè)接口寫一條數(shù)據(jù)。既然是確定性的事就應(yīng)該用代碼表達(dá)。robotbilibili要解決的就是這個(gè)矛盾如何把 B 站賬號的日常維護(hù)動(dòng)作變成一組可編排、可調(diào)度、可監(jiān)控的任務(wù)。讀這篇文章之前我希望你帶著三個(gè)問題登錄態(tài)怎么管理才能既不頻繁失效又不把 Cookie 泄露到代碼倉庫里任務(wù)之間如何抽象才能讓“發(fā)評論”和“查數(shù)據(jù)”這樣完全不同的動(dòng)作共用一套調(diào)度和執(zhí)行框架定時(shí)任務(wù)跑到一半拋異常了怎么才能及時(shí)發(fā)現(xiàn)而不是等到第二天數(shù)據(jù)報(bào)表出來才發(fā)現(xiàn)這三個(gè)問題正是robotbilibili一類項(xiàng)目在設(shè)計(jì)時(shí)最需要想清楚的部分。下面我會用完整代碼逐一回答。2. robotbilibili 的核心概念與整體架構(gòu)在寫出第一行代碼之前先建立一套統(tǒng)一的概念模型。這個(gè)模型不依賴 B 站具體接口任何平臺的自動(dòng)化項(xiàng)目都可以套用。2.1 四個(gè)核心抽象Session會話一次登錄成功后建立的持久化狀態(tài)。在 B 站場景里Session 的核心就是 Cookie 和請求頭。Session 管理得好不好直接決定自動(dòng)化任務(wù)的穩(wěn)定性。Action原子操作一次具體的 API 調(diào)用比如查詢視頻列表、讀取用戶信息、發(fā)送一條動(dòng)態(tài)。Action 是任務(wù)的最小執(zhí)行單元。Task任務(wù)由若干個(gè) Action 按業(yè)務(wù)邏輯組合而成比如“每日數(shù)據(jù)巡檢任務(wù)”可以拆成“獲取用戶信息 - 獲取視頻列表 - 獲取每條視頻的播放量 - 寫入本地?cái)?shù)據(jù)庫”。Scheduler調(diào)度器負(fù)責(zé)在指定時(shí)間或周期性觸發(fā) Task。調(diào)度器需要支持 cron 表達(dá)式、任務(wù)去重、失敗重試和日志輸出。2.2 與手工操作和瀏覽器自動(dòng)化的對比很多人會問既然有requests直接調(diào)接口為什么還要用瀏覽器自動(dòng)化Playwright、Selenium這里有一個(gè)選擇依據(jù)維度手工操作API 自動(dòng)化瀏覽器自動(dòng)化執(zhí)行速度慢依賴人快毫秒級中等需要啟動(dòng)瀏覽器穩(wěn)定性不穩(wěn)定易漏操作高只要接口不變受頁面結(jié)構(gòu)和網(wǎng)絡(luò)影響登錄態(tài)維護(hù)人工維護(hù)Cookie/Token需要處理登錄態(tài)持久化維護(hù)成本無代碼成本接口變更時(shí)需要改代碼頁面 DOM 變更時(shí)需要改選擇器適合場景臨時(shí)、低頻操作批量、定時(shí)、高頻復(fù)雜交互、強(qiáng)驗(yàn)證場景robotbilibili走的是 API 自動(dòng)化路線。它的核心優(yōu)勢是輕量和穩(wěn)定一個(gè) Python 進(jìn)程、一個(gè)請求客戶端、一張定時(shí)任務(wù)表就能跑完整的自動(dòng)化流程。2.3 整體目錄結(jié)構(gòu)一個(gè)可擴(kuò)展的robotbilibili工程建議用下面的目錄組織代碼robotbilibili/ ├── main.py # 程序入口 ├── requirements.txt # 依賴清單 ├── .env # 環(huán)境變量不要提交到 Git ├── robotbilibili/ │ ├── __init__.py │ ├── client.py # 請求客戶端封裝 │ ├── login.py # 登錄態(tài)獲取 │ ├── scheduler.py # 任務(wù)調(diào)度器 │ ├── config.py # 配置讀取 │ ├── api/ │ │ └── user.py # 用戶相關(guān)接口 │ └── tasks/ │ ├── base.py # 任務(wù)基類 │ └── daily.py # 具體任務(wù)實(shí)現(xiàn) └── logs/ └── robot.log # 運(yùn)行日志這個(gè)結(jié)構(gòu)的設(shè)計(jì)原則是入口只做組裝業(yè)務(wù)邏輯放在任務(wù)層底層能力放在 client 和 api 層。后續(xù)無論新增任務(wù)還是更換接口改動(dòng)都能收斂在局部。3. 環(huán)境準(zhǔn)備與基礎(chǔ)依賴為了讓示例可復(fù)現(xiàn)本文統(tǒng)一使用以下環(huán)境。如果你是新手建議嚴(yán)格按照這個(gè)順序操作。3.1 操作系統(tǒng)與 Python 版本Ubuntu 20.04 / macOS / Windows WSL2 都可以。Python 3.9 及以上推薦 Python 3.10 或 3.11。檢查 Python 版本python3 --version如果本機(jī) Python 版本較低建議先安裝pyenv或使用系統(tǒng)包管理器升級。3.2 創(chuàng)建虛擬環(huán)境mkdir robotbilibili cd robotbilibili python3 -m venv venv source venv/bin/activateWindows 用戶執(zhí)行venv\Scripts\activate3.3 安裝依賴創(chuàng)建requirements.txtrequests2.28.0 APScheduler3.10.0 python-dotenv1.0.0安裝pip install -r requirements.txt這里解釋一下三個(gè)依賴的用途requests處理 HTTP 請求是 API 自動(dòng)化的基礎(chǔ)。APScheduler高級定時(shí)任務(wù)調(diào)度庫支持 cron 表達(dá)式、任務(wù)持久化和錯(cuò)過任務(wù)的補(bǔ)償。python-dotenv從.env文件讀取配置避免把 Cookie 等敏感信息寫死在代碼里。3.4 準(zhǔn)備登錄態(tài)B 站自動(dòng)化項(xiàng)目最核心的一步是拿到有效的 Cookie。有兩種方式手動(dòng)從瀏覽器復(fù)制 Cookie登錄 bilibili.com 后按 F12 打開開發(fā)者工具在 Network 面板中找到任意 API 請求復(fù)制請求頭里的 Cookie。集成掃碼登錄讓用戶用 B 站 App 掃碼程序自動(dòng)換取 Cookie。第一種方式最快但 Cookie 有有效期過期后需要重新復(fù)制不適合長期運(yùn)行的定時(shí)任務(wù)。第二種方式用戶體驗(yàn)更好也是推薦方案下一節(jié)會給出實(shí)現(xiàn)思路。4. 登錄與會話管理機(jī)器人穩(wěn)定運(yùn)行的地基4.1 Cookie 與 Session 的關(guān)系HTTP 協(xié)議本身是無狀態(tài)的服務(wù)器不知道兩次請求是不是同一個(gè)用戶。B 站通過 Set-Cookie 在瀏覽器里寫入一串身份憑證后續(xù)請求帶上這串憑證服務(wù)器就能識別用戶身份。在robotbilibili里我們用requests.Session()維持一個(gè)本地會話對象。Session 會自動(dòng)保存服務(wù)器返回的 Cookie并在后續(xù)請求中自動(dòng)攜帶。相比每次請求都手動(dòng)拼 CookieSession 是更規(guī)范的做法。4.2 掃碼登錄的原理與示例掃碼登錄本質(zhì)上是一個(gè)“輪詢”過程客戶端向 B 站服務(wù)端申請一個(gè)二維碼鏈接和唯一的qrcode_key。用戶用 B 站 App 掃描二維碼并確認(rèn)?？蛻舳嗣扛?1-2 秒輪詢一次查詢掃碼狀態(tài)。當(dāng)狀態(tài)返回成功時(shí)服務(wù)端會下發(fā)登錄 Cookie客戶端保存并復(fù)用。下面給出一個(gè)輪詢流程示例。注意接口地址和參數(shù)可能隨版本調(diào)整你需要以 B 站官方接口文檔或開源項(xiàng)目的最新實(shí)現(xiàn)為準(zhǔn)。# robotbilibili/login.py import time import requests def get_qrcode(): 申請登錄二維碼返回 qrcode_key 和二維碼內(nèi)容 URL。 resp requests.post( https://passport.bilibili.com/x/passport-login/web/qrcode/generate, timeout10, ) data resp.json() if data.get(code) ! 0: raise RuntimeError(f獲取二維碼失敗: {data}) return data[data] def poll_qrcode(qrcode_key: str): 輪詢掃碼結(jié)果成功則返回 Cookie 列表。 while True: time.sleep(2) resp requests.post( https://passport.bilibili.com/x/passport-login/web/qrcode/poll, data{qrcode_key: qrcode_key}, timeout10, ) data resp.json().get(data, {}) status_code data.get(code) if status_code 0: return data.get(cookie_info, {}).get(cookies, []) if status_code 86038: raise RuntimeError(二維碼已失效請重新獲取) if status_code 86090: print(已掃碼等待確認(rèn)...) elif status_code 86101: print(等待掃碼...) def login_by_qrcode() - str: 執(zhí)行掃碼登錄返回可用的 Cookie 字符串。 qr get_qrcode() print(請?jiān)?B 站 App 中掃描二維碼: , qr.get(url)) cookies poll_qrcode(qr.get(qrcode_key)) cookie_parts [] for c in cookies: cookie_parts.append(f{c[name]}{c[value]}) return ; .join(cookie_parts)這段代碼的關(guān)鍵點(diǎn)在于輪詢狀態(tài)機(jī)的處理。86101表示等待掃碼86090表示已經(jīng)掃碼等待確認(rèn)86038表示二維碼過期只有code 0才意味著登錄成功并返回 Cookie。生產(chǎn)環(huán)境中你不會希望每次啟動(dòng)程序都重新掃碼所以拿到 Cookie 后應(yīng)該把它寫入環(huán)境變量或本地憑據(jù)文件cat .env EOF BILI_COOKIE你的Cookie字符串 EOF4.3 統(tǒng)一請求客戶端封裝requests.Session固然好用但真正進(jìn)入工程化之后還需要統(tǒng)一處理請求頭、超時(shí)、異常重試和請求間隔。否則每個(gè)任務(wù)自己寫一套 HTTP 邏輯代碼會迅速腐爛。# robotbilibili/client.py import time import requests class BiliClient: Bilibili API 請求客戶端統(tǒng)一管理會話和請求策略。 def __init__(self, cookie: str, max_retries: int 3): self.session requests.Session() self.session.headers.update({ 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 ), Referer: https://www.bilibili.com/, Origin: https://www.bilibili.com, Cookie: cookie, }) self.max_retries max_retries def request(self, method: str, url: str, **kwargs): 帶重試和簡單頻率控制的請求方法。 for attempt in range(1, self.max_retries 1): try: kwargs.setdefault(timeout, 10) response self.session.request(method, url, **kwargs) response.raise_for_status() return response except requests.RequestException as exc: if attempt self.max_retries: raise print(f[client] 請求失敗第 {attempt} 次重試: {exc}) time.sleep(attempt * 2) def get(self, url: str, **kwargs): return self.request(GET, url, **kwargs) def post(self, url: str, **kwargs): return self.request(POST, url, **kwargs)這段封裝帶來了三個(gè)好處統(tǒng)一了請求頭避免每個(gè)接口單獨(dú)設(shè)置User-Agent。增加了重試機(jī)制網(wǎng)絡(luò)抖動(dòng)時(shí)自動(dòng)重試而不是直接拋異常中止整個(gè)任務(wù)鏈。后續(xù)要加統(tǒng)一限流、日志、埋點(diǎn)只需要改request方法所有任務(wù)都生效。5. 核心功能模塊與完整代碼實(shí)現(xiàn)進(jìn)入本文最重要的部分。我會從最底層的 API 封裝開始逐步搭建一個(gè)可以運(yùn)行的最小robotbilibili工程。5.1 獲取登錄用戶信息獲取當(dāng)前登錄用戶信息是很多自動(dòng)化任務(wù)的第一步用來校驗(yàn) Cookie 是否有效也用來確認(rèn)當(dāng)前操作的是哪個(gè)賬號。# robotbilibili/api/user.py from robotbilibili.client import BiliClient def get_my_info(client: BiliClient) - dict: 獲取當(dāng)前登錄用戶的基本信息。 注意接口地址和返回結(jié)構(gòu)以 B 站實(shí)際接口為準(zhǔn)這里僅作示例。 resp client.get(https://api.bilibili.com/x/web-interface/nav) json_data resp.json() if json_data.get(code) ! 0: raise RuntimeError(f獲取用戶信息失敗: {json_data}) data json_data.get(data, {}) return { uid: data.get(mid), name: data.get(uname), level: data.get(level_info, {}).get(current_level), }如果 Cookie 失效B 站通常會返回一個(gè)非 0 的業(yè)務(wù) code。實(shí)現(xiàn)中判斷code ! 0并拋異常就是為了讓上層調(diào)度器能捕獲這個(gè)異常并觸發(fā)告警。5.2 定義任務(wù)抽象基類一個(gè)健壯的任務(wù)框架最重要的一層抽象是任務(wù)接口。所有具體任務(wù)都實(shí)現(xiàn)同一個(gè)run方法調(diào)度器不關(guān)心任務(wù)內(nèi)部邏輯只負(fù)責(zé)在正確的時(shí)間調(diào)用它。# robotbilibili/tasks/base.py import traceback from abc import ABC, abstractmethod from robotbilibili.client import BiliClient class BaseTask(ABC): 所有自動(dòng)化任務(wù)的基類。 name: str base_task description: str abstractmethod def execute(self, client: BiliClient) - dict: 執(zhí)行任務(wù)邏輯返回結(jié)構(gòu)化結(jié)果。 raise NotImplementedError def run(self, client: BiliClient) - dict: 統(tǒng)一的執(zhí)行入口包含異常兜底。 print(f[task] 開始執(zhí)行 {self.name}) try: result self.execute(client) result.setdefault(success, True) result.setdefault(task, self.name) print(f[task] {self.name} 執(zhí)行完成: {result}) return result except Exception as exc: print(f[task] {self.name} 執(zhí)行失敗: {exc}) print(traceback.format_exc()) return { success: False, task: self.name, error: str(exc), }BaseTask把異常處理公共化。具體任務(wù)只需要實(shí)現(xiàn)execute方法不需要關(guān)心調(diào)度器怎么調(diào)它也不需要對上層調(diào)用方暴露異常細(xì)節(jié)。5.3 實(shí)現(xiàn)一個(gè)具體任務(wù)用戶信息巡檢下面實(shí)現(xiàn)一個(gè)最簡單的巡檢任務(wù)它調(diào)用前面寫的get_my_info并把結(jié)果返回給調(diào)度器。# robotbilibili/tasks/user_inspect.py from robotbilibili.api.user import get_my_info from robotbilibili.client import BiliClient from robotbilibili.tasks.base import BaseTask class UserInspectTask(BaseTask): name user_inspect description 獲取當(dāng)前登錄用戶信息校驗(yàn)登錄態(tài)是否有效 def execute(self, client: BiliClient) - dict: info get_my_info(client) return {info: info}你可能會覺得這個(gè)任務(wù)太簡單。沒錯(cuò)本文的目的是先把框架跑通。真實(shí)項(xiàng)目里的“視頻數(shù)據(jù)統(tǒng)計(jì)”“每周動(dòng)態(tài)發(fā)布”任務(wù)只需要在execute里組合多個(gè) API 調(diào)用即可框架本身不需要改動(dòng)。5.4 組裝定時(shí)調(diào)度器一次性的自動(dòng)化腳本價(jià)值有限真正有用的是按計(jì)劃自動(dòng)執(zhí)行。這里使用 APScheduler 的BlockingScheduler配合 cron 觸發(fā)方式。# robotbilibili/scheduler.py from apscheduler.schedulers.blocking import BlockingScheduler from robotbilibili.client import BiliClient from robotbilibili.tasks.base import BaseTask def build_scheduler(client: BiliClient, tasks: list[BaseTask]): 把任務(wù)列表注冊到調(diào)度器。 scheduler BlockingScheduler(timezoneAsia/Shanghai) for task in tasks: scheduler.add_job( task.run, interval, minutestask.run_interval_minutes, args[client], idtask.name, replace_existingTrue, max_instances1, coalesceTrue, ) return scheduler為了讓調(diào)度器能拿到任務(wù)的運(yùn)行間隔我們需要在任務(wù)類上增加一個(gè)統(tǒng)一字段。更新一下base.pyclass BaseTask(ABC): name: str base_task description: str run_interval_minutes: int 60然后讓UserInspectTask指定運(yùn)行頻率class UserInspectTask(BaseTask): name user_inspect description 獲取當(dāng)前登錄用戶信息校驗(yàn)登錄態(tài)是否有效 run_interval_minutes 305.5 主入口程序main.py是程序的唯一入口職責(zé)是讀取配置、初始化客戶端、注冊任務(wù)、啟動(dòng)調(diào)度器。# main.py import os from dotenv import load_dotenv from robotbilibili.client import BiliClient from robotbilibili.scheduler import build_scheduler from robotbilibili.tasks.user_inspect import UserInspectTask load_dotenv() def main(): cookie os.getenv(BILI_COOKIE) if not cookie: raise ValueError(未找到 BILI_COOKIE 環(huán)境變量請先配置登錄 Cookie) client BiliClient(cookie) tasks [ UserInspectTask(), ] scheduler build_scheduler(client, tasks) print([main] 調(diào)度器啟動(dòng)等待任務(wù)執(zhí)行...) scheduler.start() if __name__ __main__: main()到這里一個(gè)最小的robotbilibili工程就跑通了啟動(dòng)后每 30 分鐘執(zhí)行一次用戶信息巡檢Cookie 有效則記錄下當(dāng)前賬號信息Cookie 失效則打印異常。雖然功能很簡單但整個(gè)架構(gòu)已經(jīng)具備擴(kuò)展性。6. 定時(shí)任務(wù)與生產(chǎn)化調(diào)度6.1 為什么選擇 APSchedulerwhile True sleep也能實(shí)現(xiàn)定時(shí)效果但工程上遠(yuǎn)遠(yuǎn)不夠程序重啟后任務(wù)狀態(tài)丟失任務(wù)執(zhí)行超時(shí)會阻塞下一次調(diào)度多個(gè)任務(wù)并發(fā)時(shí)沒有任務(wù)去重機(jī)制。APScheduler 解決了這些問題。能力whilesleepAPSchedulercron 觸發(fā)需要手動(dòng)計(jì)算時(shí)間原生支持任務(wù)重疊控制無max_instances錯(cuò)過的任務(wù)補(bǔ)執(zhí)行無coalesce任務(wù)持久化無支持 SQLAlchemyJobStore進(jìn)程外管理無支持后臺調(diào)度器6.2 錯(cuò)過任務(wù)的補(bǔ)償策略max_instances1表示同一個(gè)任務(wù)在同一時(shí)間只能有一個(gè)實(shí)例在運(yùn)行避免上一次還沒執(zhí)行完下一次又觸發(fā)導(dǎo)致請求風(fēng)暴。coalesceTrue表示如果系統(tǒng)停機(jī)錯(cuò)過多個(gè)調(diào)度點(diǎn)恢復(fù)后只補(bǔ)執(zhí)行最近一次避免任務(wù)堆疊。這兩個(gè)參數(shù)在生產(chǎn)環(huán)境非常重要。假設(shè)你的機(jī)器人凌晨跑數(shù)據(jù)統(tǒng)計(jì)任務(wù)電腦休眠了 3 個(gè)小時(shí)醒來后如果不加coalesce調(diào)度器可能連續(xù)觸發(fā) 6 次任務(wù)瞬間打爆接口加上之后只執(zhí)行一次。6.3 日志接入print只能用在開發(fā)階段。生產(chǎn)環(huán)境需要把運(yùn)行日志寫入文件并記錄結(jié)構(gòu)化信息。Python 標(biāo)準(zhǔn)庫的logging就夠用。# robotbilibili/logger.py import logging from logging.handlers import RotatingFileHandler def setup_logger(name: str robotbilibili, log_file: str logs/robot.log): logger logging.getLogger(name) logger.setLevel(logging.INFO) file_handler RotatingFileHandler( log_file, maxBytes10 * 1024 * 1024, backupCount3, encodingutf-8 ) console_handler logging.StreamHandler() formatter logging.Formatter( %(asctime)s - %(name)s - %(levelname)s - %(message)s ) file_handler.setFormatter(formatter) console_handler.setFormatter(formatter) logger.addHandler(file_handler) logger.addHandler(console_handler) return logger6.4 失敗重試與告警網(wǎng)絡(luò)請求失敗和業(yè)務(wù) code 不等于 0 是兩類不同的問題。前者可以重試后者通常不需要重試因?yàn)閰?shù)或權(quán)限出了問題重試只會浪費(fèi)請求。在BiliClient.request中我們只對requests.RequestException做了重試這是合理的。業(yè)務(wù) code 錯(cuò)誤應(yīng)該在api層通過拋異常終止任務(wù)然后在任務(wù)層記錄日志并觸發(fā)告警。生產(chǎn)環(huán)境建議接入企業(yè)微信機(jī)器人、釘釘機(jī)器人或郵件通知。最簡單的做法是當(dāng)任務(wù)的返回結(jié)果中successFalse時(shí)調(diào)用一個(gè)send_alert函數(shù)。def send_alert(task_name: str, error: str): 發(fā)送告警實(shí)際可替換為企業(yè)微信/釘釘/郵件。 print(f[alert] 任務(wù) {task_name} 失敗: {error})7. 運(yùn)行結(jié)果與效果驗(yàn)證7.1 啟動(dòng)程序python main.py如果一切正常你會看到類似下面的輸出[main] 調(diào)度器啟動(dòng)等待任務(wù)執(zhí)行... [task] 開始執(zhí)行 user_inspect [task] user_inspect 執(zhí)行完成: {info: {uid: 12345678, name: 測試賬號, level: 6}, success: True, task: user_inspect}這里的uid、name、level是自動(dòng)從接口返回值中解析出來的說明整個(gè)調(diào)用鏈?zhǔn)峭ǖ摹?.2 如何判斷成功一個(gè)自動(dòng)化任務(wù)是否成功不應(yīng)該只憑“沒有異?！眮砼袛喽礃I(yè)務(wù)結(jié)果。拿用戶信息巡檢來說成功的標(biāo)準(zhǔn)有兩個(gè)HTTP 請求返回 200。業(yè)務(wù) code 為 0且能解析出用戶信息。如果請求 200 但業(yè)務(wù) code 返回 -101通常表示未登錄這個(gè)任務(wù)實(shí)際上已經(jīng)失敗了。所以在get_my_info里判斷code ! 0并拋異常是非常關(guān)鍵的一步。7.3 模擬 Cookie 失效的驗(yàn)證方法把.env里的BILI_COOKIE改成一段亂碼重新運(yùn)行程序[task] user_inspect 執(zhí)行失敗: 獲取用戶信息失敗: {code: -101, message: 賬號未登錄} [task] 執(zhí)行失敗: 獲取用戶信息失敗: ...正常情況下調(diào)度器不會因?yàn)橐粋€(gè)任務(wù)失敗而退出。它會等待下一個(gè)調(diào)度周期繼續(xù)執(zhí)行。這就是把任務(wù)異常捕獲放進(jìn)BaseTask.run的價(jià)值任務(wù)失敗不影響調(diào)度器存活。8. 常見問題與排查思路在 B 站自動(dòng)化項(xiàng)目里最容易踩坑的不是代碼邏輯而是登錄態(tài)、接口變更和請求頻率。下面整理了一張排查表建議收藏以備后用。問題現(xiàn)象可能原因排查方式解決方案接口返回 code-101Cookie 無效或過期先用瀏覽器打開 bilibili.com看是否已登錄重新掃碼登錄并更新 Cookie接口返回 code-412請求頻率過高或請求頭異常查看請求日志統(tǒng)計(jì)同一接口調(diào)用頻率增加請求間隔避免高頻任務(wù)重疊定時(shí)任務(wù)不觸發(fā)調(diào)度器沒啟動(dòng)或時(shí)區(qū)設(shè)置錯(cuò)誤檢查 main.py 是否執(zhí)行到 scheduler.start()明確指定 timezoneAsia/Shanghai任務(wù)執(zhí)行到一半中斷網(wǎng)絡(luò)超時(shí)或接口響應(yīng)過慢查看日志中的 timeout 異常調(diào)整 BiliClient 的 timeout 參數(shù)多次任務(wù)同時(shí)提交重復(fù)操作上一次任務(wù)沒執(zhí)行完就觸發(fā)了下一次查看日志中是否有并發(fā)調(diào)用設(shè)置 max_instances1coalesceTrue.env 配置生效不了python-dotenv 沒有找到 .env 文件檢查文件路徑和 load_dotenv() 調(diào)用位置在 main.py 頂部調(diào)用 load_dotenv()依賴版本沖突項(xiàng)目依賴與系統(tǒng)包沖突使用 pip freeze 檢查依賴樹使用虛擬環(huán)境鎖定 requirements.txt 版本其中-412是最需要重視的。它往往意味著你的請求被風(fēng)控策略盯上了。遇到這種情況正確做法不是加大并發(fā)去對抗而是降低頻率、增加隨機(jī)延遲、或者停止攻擊性操作。robotbilibili的設(shè)計(jì)目標(biāo)從來不是對抗風(fēng)控而是做一個(gè)“禮貌”的自動(dòng)化客戶端。9. 使用邊界與工程最佳實(shí)踐技術(shù)本身是中性的但自動(dòng)化腳本的使用場景必須設(shè)置邊界。下面這些經(jīng)驗(yàn)是我建議任何接觸 B 站自動(dòng)化的開發(fā)者都遵守的。9.1 合規(guī)底線第一認(rèn)真閱讀并遵守 B 站用戶協(xié)議、開發(fā)者協(xié)議和 API 使用規(guī)范。只對你有權(quán)管理的賬號進(jìn)行操作不做任何影響平臺正常秩序的事情比如批量注冊、刷播放、刷評論、繞過驗(yàn)證碼、攻擊接口等。第二自動(dòng)化只用來替代人工重復(fù)操作不能用來放大規(guī)模。人工一天發(fā) 10 條評論腳本也不應(yīng)該變成一天發(fā) 10 萬條。這不是能力問題而是合規(guī)問題。9.2 敏感信息管理Cookie 等同于賬號的臨時(shí)密碼。把 Cookie 寫死在代碼里、提交到 GitHub、上傳到公開博客都屬于安全事故。正確做法使用.env文件存儲并加入.gitignore。敏感文件加密存儲或使用環(huán)境變量注入。定期更換 Cookie避免長期有效憑據(jù)泄露。# .gitignore .env logs/ __pycache__/ venv/9.3 請求頻率與隨機(jī)化B 站是商業(yè)平臺接口有明確的負(fù)載壓力。機(jī)器人的請求應(yīng)該像人一樣“有禮貌”默認(rèn)請求間隔不低于 1 秒。批量任務(wù)之間增加統(tǒng)計(jì)抖動(dòng)比如 1.5 秒到 3 秒的隨機(jī)延遲。避免在整點(diǎn)時(shí)間并發(fā)跑大量任務(wù)。import random import time def polite_delay(min_seconds: float 1.0, max_seconds: float 3.0): time.sleep(random.uniform(min_seconds, max_seconds))9.4 接口版本兼容B 站接口會不定期調(diào)整。不要讓所有代碼直接依賴原始接口路徑而是封裝到api層。這樣接口變更時(shí)只需要修改一個(gè)文件而不需要全局替換。建議在api層增加一個(gè)簡單的版本標(biāo)記# robotbilibili/api/user.py API_VERSION web-interface def get_my_info(client: BiliClient) - dict: url fhttps://api.bilibili.com/{API_VERSION}/nav ...9.5 日志與可觀測性一個(gè)沒有日志的自動(dòng)化項(xiàng)目出問題時(shí)基本沒法排查。至少需要做到每次請求記錄接口路徑、耗時(shí)、HTTP 狀態(tài)碼。每次任務(wù)記錄開始時(shí)間、結(jié)束時(shí)間、結(jié)果摘要。日志按天或按大小輪轉(zhuǎn)避免磁盤耗盡。任務(wù)失敗時(shí)要有告警不能只靠人看日志。9.6 灰度發(fā)布與回滾如果機(jī)器人會執(zhí)行寫操作比如發(fā)動(dòng)態(tài)、發(fā)評論建議先在小號上驗(yàn)證再逐步擴(kuò)大到正式賬號。每次變更代碼后先在測試環(huán)境跑一個(gè)周期確認(rèn)無誤后再更新生產(chǎn)任務(wù)。# 先跑一次單次任務(wù)不啟動(dòng)調(diào)度器 python -c from dotenv import load_dotenv load_dotenv() import os from robotbilibili.client import BiliClient from robotbilibili.tasks.user_inspect import UserInspectTask client BiliClient(os.getenv(BILI_COOKIE)) print(UserInspectTask().run(client)) 這一步叫做“單次冒煙測試”它能讓你在不等待調(diào)度周期的情況下快速驗(yàn)證代碼是否可用。10. 總結(jié)與后續(xù)擴(kuò)展方向robotbilibili教會我們的不只是一個(gè) B 站腳本怎么寫而是一套自動(dòng)化任務(wù)系統(tǒng)怎么設(shè)計(jì)。梳理一下全文的核心要點(diǎn)登錄態(tài)是整個(gè)自動(dòng)化的地基Cookie 管理不好一切功能都白搭。請求客戶端要統(tǒng)一封裝把重試、超時(shí)、請求頭集中處理才能支撐多任務(wù)場景。任務(wù)抽象是擴(kuò)展性的關(guān)鍵把execute和run分離業(yè)務(wù)代碼和調(diào)度代碼就能各自演進(jìn)。APScheduler 的max_instances、coalesce、時(shí)區(qū)設(shè)置是生產(chǎn)環(huán)境定時(shí)任務(wù)必須注意的細(xì)節(jié)。日志、告警、灰度、合規(guī)邊界決定了這個(gè)項(xiàng)目能跑多久、跑得多穩(wěn)。接下來如果你想繼續(xù)深入可以往這幾個(gè)方向做擴(kuò)展增加 Web 管理端用 FastAPI 暴露一個(gè)管理界面在線查看任務(wù)狀態(tài)、手動(dòng)觸發(fā)任務(wù)、更新 Cookie。接入消息隊(duì)列用 Redis Celery 替代單機(jī)調(diào)度器把任務(wù)分發(fā)到多臺機(jī)器執(zhí)行適合賬號規(guī)模較大的場景。數(shù)據(jù)持久化把接口返回的數(shù)據(jù)寫入 SQLite 或 MySQL積累歷史數(shù)據(jù)后做趨勢分析。多平臺擴(kuò)展把BaseTask抽象復(fù)制一份新增抖音、小紅書等平臺的客戶端實(shí)現(xiàn)整體架構(gòu)可以直接復(fù)用.最后提醒一句自動(dòng)化腳本不是越復(fù)雜越好而是越可控越好。先把用戶信息巡檢這個(gè)最小環(huán)節(jié)跑穩(wěn)定再逐步疊加功能。希望這篇文章能幫你走出從“復(fù)制腳本”到“設(shè)計(jì)系統(tǒng)”的第一步。