MediaCrawler 项目深度分析

一、基本盘

Star 量在同领域（中文自媒体数据采集）排第一，且仍在活跃维护。

二、项目定位

一个多平台自媒体数据采集工具，覆盖国内 7 个主流社交媒体平台，支持关键词搜索、指定帖子详情、评论爬取、创作者主页采集等功能。

平台功能矩阵

三、技术架构

3.1 整体架构

main.py (入口，工厂模式) ├── CrawlerFactory → 7个平台爬虫 │ ├── XiaoHongShuCrawler / DouYinCrawler / KuaishouCrawler │ ├── BilibiliCrawler / WeiboCrawler / TieBaCrawler / ZhihuCrawler │ └── 全部继承 AbstractCrawler 基类 ├── base/ — 抽象基类、公共组件 ├── store/ — 多格式数据输出 (CSV/JSON/Excel/SQLite/MySQL/PostgreSQL) ├── proxy/ — IP代理池管理 ├── cache/ — 缓存抽象 (支持 Redis) ├── database/ — ORM 模型，支持自动建表 ├── config/ — 配置中心 (base_config.py) ├── api/ — FastAPI 后端服务 ├── webui/ — Vite 前端界面 ├── tools/ — 工具函数、CDP 管理、异步文件写入 └── constant/ — 常量定义

3.2 目录结构

MediaCrawler/ ├── api/ # FastAPI 后端服务 ├── base/ # 抽象基类 ├── cache/ # 缓存层 (Redis支持) ├── cmd_arg/ # 命令行参数 ├── config/ # 配置文件 ├── constant/ # 常量定义 ├── database/ # 数据库模型 ├── docs/ # VitePress 文档站 ├── libs/ # 第三方库 ├── media_platform/ # 7个平台爬虫实现 │ ├── xhs/ # 小红书 │ ├── douyin/ # 抖音 │ ├── kuaishou/ # 快手 │ ├── bilibili/ # B站 │ ├── weibo/ # 微博 │ ├── tieba/ # 贴吧 │ └── zhihu/ # 知乎 ├── model/ # 数据模型 ├── proxy/ # 代理池 ├── store/ # 数据存储层 ├── test/ / tests/ # 测试 ├── tools/ # 工具函数 ├── webui/ # Web 前端 (Vite) ├── main.py # 入口文件 ├── pyproject.toml # Python 项目配置 └── requirements.txt # 依赖列表

3.3 设计模式

• 工厂模式：CrawlerFactory通过平台标识（xhs/dy/bili等）创建对应的爬虫实例
• 模板方法模式：AbstractCrawler基类定义start()流程骨架，子类实现各平台特有逻辑
• 策略模式：存储层支持 CSV/JSON/Excel/SQLite/MySQL/PostgreSQL 可插拔切换
• 代理模式：代理池抽象，支持多代理提供者

四、核心技术原理 — CDP 模式

这是 MediaCrawler 架构中最关键的技术创新。

4.1 什么是 CDP

Chrome DevTools Protocol— Chrome 浏览器对外暴露的底层通信协议。你按 F12 打开的开发者工具就是通过 CDP 跟浏览器内核通信。任何程序都可以通过 WebSocket 连接localhost:9222来操控 Chrome 浏览器（查看 DOM、执行 JS、监控网络请求、截图等）。

Playwright 和 Puppeteer 底层走的也是 CDP。

4.2 MediaCrawler 的 CDP 做法

传统爬虫路径：

Python脚本 → launch() 启动新Chrome → 无登录态 → 需要扫码登录 → 高风控风险

MediaCrawler CDP 路径：

用户手动打开 Chrome（已登录各平台） ↕ WebSocket (localhost:9222) Python脚本 → connect_over_cdp() 连上已有浏览器 → 复用Cookie/登录态 → 低风控风险

三步走：

1. 用户启动 Chrome 并开启远程调试：chrome://inspect/#remote-debugging
2. Playwright 通过 CDP 连上：playwright.chromium.connect_over_cdp("http://localhost:9222")
3. 在浏览器 JS 环境中执行签名函数：page.evaluate("window._webmsxyw()")

4.3 为什么这招聪明

传统的爬虫有两种路径：

CDP 模式走了第三条路：不逆向加密，不模拟点击，直接在真人浏览器里调用平台自己的签名函数。

page.evaluate("window._webmsxyw()") → 返回 { xs: "abc...", xt: "123..." } ↓ Python 拿着签名直接发 HTTP 请求

核心洞察：平台的 JS 源代码里一定包含签名算法，CDP 让你在浏览器运行环境里直接拿到计算结果——你不需要知道算法怎么算的，只需要知道函数名是什么。

4.4 CDP 模式的局限性

1. 依赖平台暴露签名函数到window对象上。如果平台做严格的闭包隔离不暴露，这招就废了。
2. 平台改前端 JS 时函数名可能变更，需要同步更新。不过改一两行 JS 表达式的成本远低于重新逆向。
3. 需要 Chrome >= 144且需要用户手动开启远程调试。
4. 本质上仍是寄生，平台理论上可以通过检测 CDP 连接来反制。

五、优劣势分析

5.1 优势

5.2 风险与不足

六、商业模型

作者的商业化思路很清晰：开源版做流量和口碑，Pro 版做变现，赞助商做广告收入。这是一套成熟的独立开发者商业模式。

七、对现有项目的关联

7.1 与 SocialHub 的关系

SocialHub 做的是多平台社媒数据看板（热榜聚合 + 账号管理），数据来源是 URL 直抓（不涉及登录态和签名）。

MediaCrawler 做的是搜索/详情/评论爬取，数据维度不重叠但互补：

• SocialHub 缺搜索能力和评论数据
• MediaCrawler 缺热榜聚合和账号管理

未来整合方向：MediaCrawler 的 CDP 模式 + 平台爬虫架构可以作为 SocialHub 的深度数据采集层，但需要明确哪些数据走 URL 直抓、哪些走浏览器自动化。

7.2 技术学习价值

值得学习的架构模式：

1. 工厂模式 + 抽象基类的爬虫架构设计
2. CDP 模式的浏览器操控方式（比直接写 Playwright 脚本优雅得多）
3. 代理池设计— 抽象层 + 多提供者支持
4. 多格式存储层— 可插拔的数据输出
5. 配置中心化— 所有开关集中在config/base_config.py
6. FastAPI + Vite的 Web 管理界面架构

7.3 闲鱼变现可能

不能直接卖软件（开源且许可证禁止商业用途），但可以做：

• 部署+定制服务：帮不会技术的人搭起来用（技术服务，非卖软件）
• 场景化产品：基于此架构做「小红书舆情监控」「抖音竞品分析」等垂直工具
• 需注意法律边界：仅限学习研究，不能商用

八、总体评价

一句话总结：技术架构值得学，CDP 模式值得抄，但生产环境使用需要认真评估法律风险。作为爬虫架构参考和学习材料，质量很高。