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