openai 环境变量 base_url

代码里明明写了 base_url，跑起来还是连到默认地址；或者换了中转站，环境变量也改了，请求却打到老地方——多半是没搞清 SDK 读哪个变量、参数和环境变量谁说了算。这篇只讲工程落地：变量名怎么拼、优先级怎么排、多环境怎么隔离、跑起来怎么确认真的生效了，最后给一份排查顺序表。协议兼容层和客户端配置另有两篇，这里不重复。

代码里明明写了 base_url，跑起来还是连到默认地址；或者换了中转站，环境变量也改了，请求却打到老地方——这类问题基本不是 SDK 坏了，而是你没搞清它到底读哪个变量、参数和环境变量谁说了算。这篇只讲工程落地：变量名怎么拼、优先级怎么排、多环境怎么隔离、跑起来怎么确认真的生效。

跟官方直连、不做任何切源的项目，其实用不着折腾它；只有自建网关、本地推理服务、中转站这几类场景才需要。如果你要横向比不同中转站的稳定性，可以先去 /sites 看各家当时的检测记录，再回来配地址。协议兼容层和客户端初始化另有两篇单独讲，这里不重复。

base_url 到底管什么：请求打到哪台机器

它决定 SDK 把请求发往哪个根地址。鉴权头、路径拼接、超时重试都挂在这个根上，改它等于换了一整条链路，不是换个域名那么简单。所以第一步永远是先确认终点：你到底想让请求落到官方、某个中转站，还是本机跑的服务。终点错了，后面怎么调都是白费。

第二步是确认路径拼接。根地址后面，SDK 通常会自己补上版本段和资源段。你在 base_url 里多写一层或漏写一层，表现就是 404 或路径找不到，而不是连接失败。判断标准很简单：base_url 只写到「域名 + 可选的统一入口段」，别把后面 SDK 要自己拼的部分也写进去。

1. 先确认终点明确这次请求应该落到哪台机器。是官方直连、某中转站、还是本机服务，写在纸上。
2. 再确认路径对照该服务文档给的根地址格式，看自己有没有多写或少写一层。不确定就先按最简根地址试。
3. 最后确认鉴权地址通了再看密钥是不是这个服务签发的。地址对、鉴权错，报的通常是 401 而不是 404。

变量名怎么拼、参数和环境变量谁优先

SDK 是按固定名字去读环境变量的。拼错大小写、多加下划线、换成另一种命名风格，它不会报错，只会静默回退到默认地址——这就是「我明明设了却不生效」的最常见原因。配之前先去 /guides 翻一眼对应 SDK 的配置说明，别凭记忆拼。

优先级从高到低一般是：代码里显式传的参数 > 环境变量 > 内置默认值。要确认到底用了哪个，最省事的办法是把客户端实例实际持有的地址打印出来，一眼就知道有没有被覆盖。部分框架自己包了一层配置读取，可能绕过标准变量名，那就得去看框架自己的配置来源，别硬套。

多环境隔离：开发、测试、生产各写各的

本地开发用一个不入库的文件放地址和密钥，部署时改用平台的环境变量注入。别把地址和密钥写进仓库，哪怕只是内网地址——一旦仓库外泄，地址加密钥就是完整凭据。团队内部先统一一条规则：base_url 末尾到底带不带斜杠，写进项目说明，避免各写各的。

• 本地文件只放本地用的地址，进 .gitignore，别提交
• 部署环境用平台注入，地址和密钥分开管理
• 地址可以公开、密钥必须走密钥管理，轮换时只换密钥不动地址
• 一次进程内要同时打多个地址时，显式传参比环境变量清楚得多
• 改动后一定要重启进程再验证，热更新不一定重读环境变量

什么情况下别用环境变量：同一个进程要并发打多个不同地址时，环境变量只有一个值，表达不了。这时候显式传参更清楚，也更好测。密钥轮换的周期各家不一样，建议在 /price-watch 看当时的价格和额度口径变化时顺带检查一下自己的密钥有没有到期。

怎么确认真的生效：一次可复现的验证

最省事的验证分两步：第一步打印客户端实际持有的最终地址，第二步发一次最小请求。两步都过了才算真配好，只看地址对但不发请求，等于没验证——可能问题藏在鉴权或网络出口上。换源之后建议先量一次延迟基线，再判断卡顿是地址不对还是链路本身慢。

有一种情况不适用：报错本身就是对方限流或额度用尽。这时候改 base_url 解决不了，得去查额度口径和计费规则，具体数字到 /price-watch 核对当时的记录。把地址问题和额度问题分开看，能省掉一大半无效排查。

地址配错是本地问题，限流报错是对方问题，先分清再动手。