把项目从官方 API 切到一个自建或第三方的 LLM 网关时，最容易卡壳的往往不是代码逻辑，而是几个不起眼的细节：base_url 尾部要不要带/v1、密钥放在哪里才安全、超时和重试怎么配才不会一遇网络抖动就报错。这篇以jiekou.vip为例，把这三类坑整理成一份可以照着勾选的清单。
为什么值得单独列一份清单
从官方 API 迁到中转站，本质上是"换个入口地址、换把密钥"，代码主体几乎不用动。但正因为改动小，容易掉以轻心，结果被 base_url 拼接、密钥存放、超时设置这三类问题反复绊倒。逐条核对能把返工概率压下来。下面按接入顺序拆成三块。
第一步：base_url 到底怎么填
这是最高频的报错来源。中转站兼容主流协议，你只需要把原本指向官方的请求地址，换成中转站提供的地址。以 jiekou.vip 为例，两种常见协议的填法是：
- OpenAI 兼容协议：
https://api.highwayapi.ai/openai - Anthropic 原生协议：
https://api.highwayapi.ai/anthropic
注意 base_url 的域名是api.highwayapi.ai，而不是 jiekou.vip 这个站点域名，别把浏览器里看到的网址直接抄进代码。
关键的坑在/v1：不同 SDK 和工具对路径的拼接逻辑不一样。有的 SDK 会自动在 base_url 后面补上/v1/chat/completions，这时你就不该再自己写/v1；有的工具则要求你把/v1显式写全。所以：
如果调用返回 404，第一件事就是检查 URL 尾部是否多写或少写了
/v1。多了删掉，少了补上，大多数 404 都出在这里。
一个 OpenAI 兼容协议的 Python 示例：
from openai import OpenAI client = OpenAI( api_key="你的中转站密钥", base_url="https://api.highwayapi.ai/openai", ) resp = client.chat.completions.create( model="gpt-4o-mini", messages=[{"role": "user", "content": "你好"}], ) print(resp.choices[0].message.content)若用的是 Anthropic 原生协议，把 base_url 换成https://api.highwayapi.ai/anthropic，其余照 Anthropic SDK 的常规写法即可。
base_url 自查项：
- 域名写的是
api.highwayapi.ai，不是站点域名 - 协议路径对应正确（openai / anthropic）
- 遇到 404 先排查
/v1是多写还是少写
第二步：密钥怎么放才安全
密钥是访问中转站的唯一凭证，泄露等于把余额和权限拱手让人。几条底线：
- 绝不把密钥硬编码进源码，更不要提交到 Git 仓库
- 用环境变量或专门的密钥管理服务存放，代码里通过
os.environ读取 - 前端页面里绝不出现密钥——浏览器可见即等于公开，需要调用时走自己的后端
- 给不同项目或环境分配不同密钥，一旦某个泄露可单独吊销，互不影响
- 定期在 jiekou.vip 后台轮换密钥，并删除不再使用的旧钥
环境变量读取示例：
import os from openai import OpenAI client = OpenAI( api_key=os.environ["HIGHWAY_API_KEY"], base_url="https://api.highwayapi.ai/openai", )第三步：超时与重试怎么配
大模型请求耗时天然比普通接口长，网络链路也可能偶发抖动，合理的超时和重试能显著提升稳定性。
- 连接超时设短一些（比如 5-10 秒），连不上就尽快失败
- 读取超时设长一些（比如 60 秒以上），因为模型生成本身就慢，尤其长文本
- 重试次数建议 2-3 次，配合指数退避（第一次等 1 秒，第二次 2 秒，第三次 4 秒），别一失败就疯狂重试把自己也拖垮
- 只对可重试错误重试：超时、429、5xx 可以重试；400 参数错误、401 鉴权失败这类重试也没用，应直接报错
- 流式输出场景下，注意区分"整体超时"和"两个数据块之间的间隔超时"
带超时和重试的示例：
from openai import OpenAI client = OpenAI( api_key=os.environ["HIGHWAY_API_KEY"], base_url="https://api.highwayapi.ai/openai", timeout=60.0, max_retries=3, )好在成熟的中转站在服务端就做了多线路调度和故障切换，客户端的重试更多是兜底。两边配合，稳定性才有保障。
上线前的最后一遍核对
- 用真实密钥跑通一次最小请求，确认返回正常
- 故意断网或填错模型名，验证超时和错误处理是否符合预期
- 检查日志里没有打印出完整密钥
- 在中转站后台设置好余额预警
小结
接入三方看似只是改个地址，真正决定顺不顺的是三个细节：base_url 的路径（尤其/v1的取舍）、密钥的安全存放、超时与重试的合理配置。照着这份清单逐条勾选，再用 jiekou.vip 跑一遍最小验证，基本就能一次切换到位。
