ChatGPT免费模型接口APIKey

很多人拿到一把免费额度的 Key，第一件事就是粘进代码里跑通，结果要么额度悄悄烧完，要么 Key 进了前端包被人扒走，要么并发一上去就全是报错。这篇不讲协议兼容、也不讲客户端怎么配，只写工程落地：Key 从哪来、怎么存、请求层加哪几道保险、跑起来之后怎么知道它在正常花钱。

免费额度的 Key 从哪来、先确认哪几件事

一次性赠送

开户或注册时给一笔额度，用完就没了，不会自己长回来，适合集中压测或一次性批量任务

每日刷新

每天固定时间重置一个可用额度，当天不用就浪费，适合每天跑几次的轻量脚本

新号体验期

只在注册后的一段时间内可用，到期后自动失效，适合试跑 demo，不适合长期挂服务

拿 Key 之前先把三件事问清楚，能省掉后面一堆麻烦：要不要绑支付方式、额度耗尽之后是直接报错还是悄悄转成计费、有没有并发或者 QPS 上限。这三条在不同厂商、不同活动里差别很大，而且会随时改，所以别背结论，直接去站内 /official-api 和 /ai-nav/category/ai-model-platform 看当时的说明，以页面当天写的为准。

1. 第一步，走官方入口优先从官方控制台或者站内 /official-api 里列的厂商入口进，别从搜索结果里的第三方页面点进去领 Key，来源不明的 Key 出了问题没法追溯。
2. 第二步，确认额度性质在控制台里找到额度页面，看清是一次性赠送、每日刷新还是体验期，记下失效条件，决定这个 Key 是拿来压测还是拿来跑长期任务。
3. 第三步，查计费口径翻一遍计费与限额说明，确认耗尽后是报错还是转付费，有没有自动续费开关，拿不准就先不绑支付方式或者关掉自动充值。
4. 第四步，小流量试跑先发几个最便宜的请求，确认返回正常、限速符合预期，再放大调用量，别一上来就跑全量任务。

• 不确定某条渠道能不能用，先到 /sites 看中转站目录里的说明和用户反馈，再去 /tools/verify 做一次在线实测，比事后猜省事得多
• 免费档往往带限速和日志留存条款，敏感数据别往免费位丢
• 聚合平台上的免费模型和自托管方案也值得比一遍，去 /openrouter 和 /inference 看当时的可用情况
• 免费额度用完不等于服务不可用，先确认是额度问题还是 Key 本身失效，再去排查网络和参数

Key 怎么存：从「能跑」到「不裸奔」

先把一句话说在前面：凡是浏览器能拿到的 Key，等于公开的 Key。判断标准很简单，看这段代码用户能不能看到——前端 JS、小程序包、App 资源、GitHub 仓库、构建产物、日志输出、截图、报错堆栈，只要用户或外部人员能接触到，就不能出现 Key。

三种存放方式，对应三种安全档位

一把 Key 干所有事，是最容易翻车的地方

• 一个项目至少拆三把：本地开发、测试环境、线上环境
• 不同业务线再拆开，比如客服问答和批量任务各用一把
• 拆开之后，某一把被限流或者误吊销，不会连带把整条业务打挂
• 给每把 Key 记一笔用途备注，半年后你还能对上号
• 轮换时能一把一把换，不用停整套服务

泄露了，第一动作不是改代码

1. 先去控制台吊销登录对应的 API 控制台，把这把 Key 直接吊销或删除，这一步做完泄露源就等于断了，比改代码快得多也有效得多
2. 重建一把新 Key新建之后只写进环境变量或密钥管理服务，确认线上读取到新值、请求正常返回
3. 再回头查泄露路径看是误提交到仓库、打进了前端产物、还是被日志打印出来了，把那个出口堵掉，否则新 Key 还会以同样的方式漏出去
4. 检查历史提交和日志仓库用历史检索确认有没有残留，日志系统把请求头字段做脱敏，别让 Authorization 整条打出来

顺序别搞反：很多人一发现泄露先冲去改代码，改半天 Key 还是有效的，中间那段时间谁拿到都能刷。吊销是即时生效的动作，改代码是防复发的动作，两件事优先级差得远。

Key 报错时，先对照这三样

遇到 401、403、连不上的时候，不要一上来就怀疑 Key 本身。先按顺序对照三样东西：请求头格式对不对、Base URL 指向哪里、Key 的前缀和长度对不对。这三样对不上，换多少把 Key 都没用。更细的分支排查路径，去 401-vs-403-api-errors 和 401-auth-error-troubleshoot 这两篇里按症状走一遍，能省掉大量试错。

请求层要加的几道保险：超时、重试、并发

免费接口最容易翻车的地方不是拿不到 Key，而是拿到之后请求层没做防护，一个慢响应把整个脚本拖死。先说结论：超时、重试、并发这三样必须自己在客户端加，别指望服务端帮你兜底。下面按「先保命、再提效」的顺序讲，每一条都能直接改代码。

很多 HTTP 客户端默认超时是「无限」或者一个特别大的值，本地跑小样本时看不出来，一上批量就出事。正确做法是把超时拆成三段：连接超时、读取超时、整体超时，三者分别设，互不替代。连接超时管握手阶段，读取超时管两次数据块之间的间隔，整体超时管这次请求从发出到结束的总时长。三段的秒数不要照抄网上文章，那些数字往往对应的是别人的网络环境和模型档位。到 /api-timeout-tuning 看你当前用的接口和线路对应的分档建议，再来填。

• 连接超时设短一点，握手都连不上说明网络或域名有问题，早点失败早点暴露；
• 读取超时按「流式 / 非流式」分开设，流式如果两段内容间隔太久，就该判为断流而不是继续等；
• 整体超时是所有请求的兜底，任何情况下都不能是无限；
• 三个值都写进配置，别用框架默认值，默认值往往是给人调试用的。

重试不是万能药，乱重试只会拖慢失败速度、把额度浪费掉。判断标准很简单：这个错误再发一次有没有可能成功。超时、5xx、被限流这类是「临时状态」，值得重试；401、403 这类是「鉴权状态」，Token 不对或者没权限，重试一百次结果一样，直接抛出去让人看到。重试要用指数退避，每次等待时间翻倍，并且设一个重试上限，比如三次封顶，超了就记失败、走后续流程。

1. 分类错误按状态码和异常类型分两类：可恢复（超时 / 5xx / 限流）与不可恢复（401 / 403 / 参数错误）。
2. 只对可恢复的重试不可恢复的直接抛出，别包在重试循环里。
3. 加退避和上限等待时间随次数翻倍，加上随机抖动，重试次数封顶三次。
4. 记录失败达到上限仍失败就落库或写日志，方便事后排查是哪类错误集中出现。

重试的意义是给偶发故障一次机会，不是给确定性错误刷次数。

免费额度普遍有并发上限——同时打到服务端的请求数是有数的，不是「总量够就随便发」。本地跑批量任务时，务必自己在客户端压一层队列：任务先进队列，由固定数量的工作协程从队列里取，取一个发一个，发完再取。并发开多少、每批之间留多大间隔，这两个数别拍脑袋，到 /batch-concurrency-throttle-guide 看你所用接口对应的建议值。已经触发限流了怎么逐步恢复，看 /api-rate-limit-recovery，别一限流就把并发直接拉满硬刚。

流式输出必须单独处理，不能把非流式的重试逻辑硬套上去。流式有两个特有的失败点：一是「首字超时」，请求发出后迟迟等不到第一个数据块，说明这次连接基本废了，应该尽早重连；二是「断流」，首字来了、中间突然没了，这时如果已经消费了一部分内容，重发整段可能会导致内容重复，得先决定是丢弃重来还是保留已收部分。这两种情况都要单独写分支判断，别混在普通的超时重试里。

• 首字超时设一个独立的短超时，比读取超时更早触发；
• 断流要有明确的处理策略：重连还是标记为部分成功，取决于你的下游怎么用这段内容；
• 流式请求不要复用非流式的重试封装，两者的失败语义不一样；
• 批量任务里流式和非流式最好分开跑，别混在一个队列里互相拖累。

降级、日志与成本可见性

降级这件事，最怕的不是没备用通道，而是主通道挂了没人知道，等下游业务反馈才发现。所以切换判据要写在代码里，满足条件自动切，不靠人盯。切换逻辑本身怎么设计，可以对照站内的 /multi-model-routing-fallback 那篇，这里只讲和日志、成本相关的落地部分。

1. 先定切换信号至少覆盖三类：请求连续失败、单次耗时超过阈值、返回的错误类型属于可重试。把这三类写成布尔判断，不要写成「感觉慢」。
2. 再定降级顺序主模型失败切同渠道备用模型，同渠道都不可用再切备用渠道。每一级都要有超时时间，避免卡在中间层。
3. 记录每次切换切换发生时打一条独立日志，标明从哪个模型切到哪个、触发原因是什么。否则事后只能看到最终结果，看不到过程。
4. 定期回放按月挑几条切换日志复盘，看触发频率和误切比例，阈值不合理就调整。

日志这块，字段不能凭感觉记。请求 ID、模型名、耗时、token 数、状态码、错误类型这六项是底线，缺一项都会让慢和贵这两类问题变得无法归因。完整的字段清单和回放方式在 /api-log-fields-replay，按那个口径落库，后面做统计和复盘都不用重写埋点。

有了日志，还要把用量做成天级看板。看板的价值不在好看，而在于和站内 /usage、/price-watch 的公开口径对一对。偏差大通常不是数据出错，而是统计口径写错了——比如有没有把重试算进去、有没有把缓存命中单独剔除、是按请求算还是按 token 算。对不上的时候先怀疑口径，再怀疑数据。

• 看板按天聚合，维度至少包含模型、渠道、状态码
• 用量和费用的数字要能点回到原始日志，不能只有汇总
• 和 /usage 的公开口径做一次核对，偏差超过预期就查口径说明
• 和 /price-watch 的价格追踪对一对，确认自己用的是哪一档计费
• 免费额度单独拉一条线，标出消耗速度，估算什么时候会用完

这三种表现没有绝对的好坏，取决于业务能不能接受报错。面向内部工具，报错加告警通常可以接受；面向外部用户，排队或自动切付费更稳，但要多一层成本上限保护。判断标准是：额度耗尽的那一刻，业务方能不能自己感知到、能不能接受。如果这两个问题答不上来，就先别上线。

降级要自动，日志要完整，用量要能对上账，免费额度要当成会到期的东西。

上线前的验证清单与后续动作

这一节只讲上线前怎么验证、上线后怎么跟进。免费档能不能用，不是看宣传页写得漂不漂亮，而是看你自己的链路跑起来是什么样。顺序建议是先量基线、再压一条最重的请求、然后比对输出质量，最后才是决定要不要换回付费。跳过前面几步直接上生产，出问题时你会分不清是网络、限速还是模型本身的问题。

1. 先量延迟基线用站内 /tools/speed-test 跑一遍你常用的那条链路，把首字延迟和整体耗时记下来。建议在早、晚各跑一次，因为不同时段的排队情况差别很大。这一步只是拿你自己的数字，不要拿去和别人的截图比。
2. 挑最重的一条真实请求做端到端压测从业务里挑那条最长、最复杂的请求，完整走一遍从入口到落库的流程，而不是只测一次单轮问答。重点看超时设置、重试次数、并发上限这三处会不会互相打架。
3. 跑一轮小评测比对输出换渠道前后各跑同一批用例，几十条就够了，覆盖你业务里最容易出错的几类问题。方法参考 /prompt-version-regression-testing，别自己临时想一套标准。
4. 上线后观察一段时间再决定去留免费档的限速会不会卡住业务，只有跑起来才知道。如果发现排队变长、失败率上升，再回 /coding-plans 和 /official-api 用数据比一遍，别凭感觉换。

有一点要提前说清楚：如果你的业务对延迟或成功率有硬性要求，免费档本来就不适合当主链路，再怎么验证也只是确认它能不能做兜底。反过来，如果只是内部工具、低频调用，那这套清单跑一遍基本就够用了。判断标准不是「免费能不能用」，而是「免费档在你的业务里具体卡在哪一步」。