备选标题（按吸引力排序）：
- 做分析类工具，真正卡死你的不是爬虫，是第三方API配额
- 第三方API配额怎么算？这笔账没想清楚，你的工具根本做不大
- 免费送多少、要不要收费，其实是第三方API配额替你定的
一条踩坑帖，让我重新算了一遍账
前几天刷到一条做YouTube评论分析工具的分享帖，作者老老实实把API的坑列了一遍。大部分我都见过，但有一条我盯着看了好一会儿。
他说YouTube Data API v3每天免费10000 units，太平洋时间午夜重置。拉评论的commentThreads.list一次才1 unit，一页能拿100条，算下来理论上一天能拉一百万条评论，听着特别宽裕。
但是——按关键词找视频的search.list，一次要100 units，而且它有自己独立的额度桶，每天只有100次。
我当时的第一反应不是“哦，技术细节”，而是“完了，这东西的商业形态被这100次给定死了”。说真的，做这类工具这么多年，我踩过的最贵的坑，从来不是爬不下来数据，而是我压根没把配额这笔账提前算清楚。
你以为的瓶颈，和真正的瓶颈不是一回事
大多数人做分析类工具，脑子里的难点是“怎么把数据抓下来”。于是花大把时间折腾分页、折腾反爬、折腾请求速度。
但在依赖第三方官方API的场景里，这些都不是真正的天花板。
真正的天花板是那个独立的配额桶。拿上面那个例子说，如果你的产品逻辑是“用户输入一个关键词，我帮他找视频再拉评论分析”，那你每接一个请求，search.list就扣一次，一天只有100次。
也就是说不管你服务器多快、代码多漂亮，你一天最多只能接待100个“从关键词开始”的用户。拉评论那边的10000 units根本还没碰到就先炸了。
这就是那个反常识的点：你以为限制在“拉评论”，其实限制在“发现视频”。两件事花的是两个桶里的钱，而贵的那个桶特别浅。
帖子里作者自己也没完全想明白，他在结尾问了一句：热门视频几十万条评论的时候大家怎么处理配额，是开多个GCP项目轮换，还是干脆不上官方API。这个问题问得特别真实——它本质上已经不是技术问题，是商业问题了。
（他提到的那套前端Next.js、后端Flask加Redis的实现，具体跑得怎么样属于待核实，我这里只借用配额这个事实。
配额上限，其实替你做了三个产品决策
我后来想通一件事：第三方API的配额结构，等于提前帮你把几个关键决策写死了，你越早认清越省事。
第一个决策是，免费能送多少。你的免费额度不是你大方不大方决定的，是配额除以单个用户的平均消耗算出来的。
如果每个用户平均要花掉你两次search.list，那你一天满打满算只能免费服务50个人，再多就得排队或者报错。
第二个决策是，从哪一步开始收费。既然贵的是“关键词发现视频”这一步，那合理的免费策略就是——免费用户只能贴视频链接或视频ID来分析（这步几乎不耗贵配额），想用关键词批量发现视频的高级功能，才进入付费。
你看，收费点不是你拍脑袋定的，是配额结构顺着往下推出来的。
第三个决策是，视频ID从哪来。如果能引导用户自己提供视频链接，你就把最贵的那个桶整个绕过去了。
这不是偷懒，这是把有限的配额花在真正产生价值的那一步——分析，而不是发现。
我的判断很直接：做这类工具，先别急着写代码，先拿张纸把每个核心操作对应消耗哪个配额桶、桶有多深画出来，这张图比你的架构图重要。
这跟“自己的成本”“接口被刷”是两回事
我得特意说清楚一个容易混的点。平时我们聊得多的是另外几件事：怎么挑便宜的模型省自己的token成本、怎么做个API比价站、怎么给自己的接口加限流防被刷。
那些讲的都是“我自己的东西”——我自己的钱、我自己的接口。
但第三方API配额是另一个物种。它是你消费别人的服务时，别人给你划的硬上限。
你再怎么优化代码、怎么防刷，也改不了search.list一天100次这个事实。前者是你能通过技术和议价去压的变量，后者是外部给定的常数。
把这两者混在一起想，是很多人做分析类工具一上来就跑偏的原因。
认清这个常数，产品形态反而清晰了：你不是在跟自己的成本博弈，你是在一个固定的配额预算里，决定把它花给谁、花在哪一步。
想低成本验证，最小路径长这样
道理说完，落到能跑的东西上。假设你就想先做个最朴素的版本：用户给视频ID，你拉评论、按关键词和发帖人筛一遍、导出结果。
调API聚合这件事用Python最顺手，官方读接口拿个API key就够了、不用走OAuth这点帖子里也确认了，省了一大截。你可以直接在Python在线运行里把拉评论、翻页、合并回复的逻辑先跑通，确认一个视频到底消耗多少请求，再决定要不要往下做。
我特别建议你从第一天起就把配额用量记下来，不只是存评论。开一张表记“今天调了几次search.list、几次commentThreads.list、还剩多少”，评论本身另开一张。
这种结构化的小数据用SQLite就够，想随时看看今天烧了多少配额、哪个用户最费钱，直接用SQLite编辑器打开表瞄一眼就行，不用再单独写后台。配额这笔账能不能看见，直接决定你免费额度敢不敢放开。
跑通之后想让别人用，把前端页面做出来，通过Web应用托管发个链接出去就能收反馈了。先拿十几个真实用户验证“关键词搜整条评论线程、按发帖人找评论、导出CSV”这几个点有没有人要，再谈规模化的事。
有一条边界，平台帮不了你
最后得老实说一句，免得你误会。上面这些能力——Python跑聚合、SQLite记账、Web发链接——解决的是“你怎么把工具低成本做出来、跑起来、给人用”。
但配额上限本身，是YouTube那边划的,不是任何托管平台能帮你突破的。
换句话说，平台能帮你省掉搭环境、配服务器、做前后端的那些麻烦，让你把精力全放在业务判断上；但它变不出第二个search.list额度桶。真要突破那个常数，得回到商业层面想办法——比如引导用户自带视频ID、把贵操作做成付费、或者干脆重新设计你根本不依赖关键词发现这一步的产品。
这才是这类工具真正要动脑子的地方。
今天就一个能立刻做的小动作：挑你正在用或打算用的那个第三方API，翻到它的配额文档，把每个核心方法消耗多少、有没有独立桶、桶多深，抄到一张表里。抄完你大概率会发现，你原本设想的产品形态，得改一改了。