做内容站、社媒监测或 AI 助手时，最先卡住的往往不是模型，而是数据从哪来：自建爬虫要扛反爬、代理、字段清洗和合规；官方开放平台又经常权限窄、审核慢。于是会出现一类「社交数据基础设施」供应商——用一套 API Key 拉多平台公开数据的结构化 JSON。
本文以 TikHub 官网公开信息做选型备忘，不是接入教程，也不是实测报告。价格、端点、额度以官网现页为准；真接 API 时密钥只放私有配置，不要写进公开笔记或 Git。
它大概解决什么问题
TikHub 的自我定位是：面向 AI 智能体、营销/内容分析、量化研究等场景，提供多平台公开社媒数据的 API / 数据集，而不是成品仪表盘。
官网宣传要点（整理日口径，需复核）：
| 维度 | 官网说法 |
|---|---|
| 平台 | 约 16 个社媒平台 |
| 接口 | 1000+ 端点；MCP 侧宣传 990+ 工具 |
| 数据集 | 10 亿+ 预采集记录，多格式交付 |
| 实时 API 单价 | 约 $0.001～0.01 / 次请求（端点不同） |
| 认证 | Authorization: Bearer YOUR_API_KEY |
覆盖平台名常见包括：TikTok、抖音、Instagram、YouTube、X/Twitter、小红书、B 站、微博、快手、微信公众号、Lemon8、知乎、Reddit、LinkedIn 等。能力类型因平台而异：详情、用户、搜索、评论、直播、热榜、商品相关端点等。
入口：
- 官网：https://tikhub.io/zh
- 用户台：https://user.tikhub.io
- 文档：https://docs.tikhub.io
- 定价：https://tikhub.io/zh/pricing
- Python SDK：https://github.com/TikHub/TikHub-API-Python-SDK
调用形态（官网示意）
- 基址示例：
https://api.tikhub.io/api/v1/... - 例如 TikTok 单视频一类端点：
/api/v1/tiktok/app/v3/fetch_one_video+aweme_id - 部分端点宣传单价可低至约 $0.001/次
- 示例语言：Python / JavaScript / cURL / Java 等
周边产品也值得单独评估：
| 产品 | 用途 |
|---|---|
| MCP | mcp.tikhub.io/{platform}/mcp，接到 Claude Desktop / Cursor 等，用自然语言拉数 |
| Chrome 扩展 | BYOK，浏览器侧边栏分析（多平台） |
| 数据集 | 批量历史数据，CSV/JSON/JSONL/Parquet 等，按量计价 |
定价怎么读才不容易踩坑
完整表以官网为准。选型时优先搞清这几条：
- 免费额度：注册试用请求次数有限；部分端点可能不能用免费额度。
- 按量付费：单价随端点变；可能按每日请求量做阶梯折扣。
- 失败请求是否计费：官网宣传非 200 不计费——仍要以账单和实测为准。
- 有没有“缓存便宜重拉”：若相同参数再次请求仍按实时计费，调试时很容易烧额度；响应里的 cache 链接多半是短期复看，不是免费无限重拉。
- 充值与企业档：支付方式和手续费减免条件会变，正式预算前重算。
成本直觉：即便单价只有 $0.001，日请求到几千次也会变成「每天几美元、每月上百美元」量级。正式接入前应用真实端点跑 1～2 天小流量，用账单反推单价和字段可用性。
适合 / 不适合
更适合：
- 要快速拿到抖音 / TikTok / 小红书等结构化公开数据，暂时不想先搭采集基建
- 给 AI 工具临时查数（MCP），验证产品假设
- 把「自建爬虫」当备选，把「付费 API」当加速器
不太适合：
- 预算接近零却要大规模、长期全量采集
- 数据链路必须 100% 自控，不能依赖第三方限流、调价、下线端点
- 业务场景对版权、个人信息、跨境合规要求极高，且你还没想清楚法律边界
和自建爬虫怎么比
| 维度 | 付费社媒 API | 自建爬虫 |
|---|---|---|
| 上线速度 | 通常更快 | 慢，要处理登录态/反爬/代理 |
| 字段稳定性 | 以供应商契约为准 | 自己定 schema，但页面一变就修 |
| 成本结构 | 按次/按量，易预测也易刷爆 | 机器与人力成本，边际更可控 |
| 合规责任 | 对方宣称范围 + 你的使用场景 | 全在自己 |
| 降级 | 换供应商或砍功能 | 继续维护或停用 |
更稳的工程顺序往往是：
- 用免费/小流量额度验证字段是否够用、延迟是否可接受。
- 把关键链路写成适配层（内部 DTO），不要把供应商字段散落业务代码。
- 设日预算与 RPS 熔断，避免循环任务把账单打穿。
- 明确降级：供应商挂了时产品是「少功能」还是「停服务」。
风险边界（必看）
- 合规：供应商宣称只采公开数据，不等于你的用途一定合法合规。内容版权、平台 ToS、个人信息与跨境规则都要单独判断。
- 稳定性：限流、封端点、改价、改字段都会发生。
- 数据质量：空值、延迟、重复、历史口径差异只能实测，不能信示例。
- 密钥安全：Key 只放私有配置；公开仓库、截图、聊天记录里出现 Key 就当已泄露轮换。
选型结论（可执行）
- 若目标是「先验证抖音/小红书数据能不能支撑某个闭环」，TikHub 这类服务适合作为候选加速器，不是默认永久依赖。
- 当前合理动作：注册免费额度 → 选 1～2 个核心端点 → 记字段与单价 → 再决定是否进具体代码仓。
- 真接入时：代码仓
docs/写边界与适配层；密钥进 private；公开笔记只保留调研结论。
本文信息来自官网公开页摘要与个人选型备忘，不构成采购建议或法律意见。
—
来源笔记：50-内容与产品/内容与站点/社媒数据API-TikHub.md
正文完
