为什么成熟的 LLM 应用，都把"后端地址"做成可切换的配置

很多接入大模型的项目，一开始都是把 SDK 的默认地址直接拿来用，密钥和地址散落在代码里。等到需要换供应商、做灰度、或者在多个环境间切换时，才发现改起来到处是坑。这篇聊一个基础但重要的工程习惯：把 LLM 的后端地址（base_url）和密钥抽成外部配置，让"请求发到哪里"变成一个可随时切换的开关。

为什么后端地址值得单独抽出来

主流大模型 SDK 都允许你显式指定 base_url 和 api_key。默认情况下 SDK 会连到厂商的官方地址，但只要这两个值可配置，同一份调用代码就能指向不同的后端------官方、自建网关、兼容层、测试桩，都只是配置差异。

如果把地址和密钥硬编码在代码里，会带来几个典型问题：换后端要改代码并重新发布；开发 / 测试 / 生产用不同后端时容易配错；密钥进了代码库有泄露风险。把它们抽成环境变量，这些问题就都消失了。

做法：用环境变量驱动后端选择

绝大多数 SDK 都遵循同一套约定------优先读环境变量。以jiekou.vip为例：

bash 复制代码

export LLM_BASE_URL=https://api.highwayapi.ai/anthropic
export LLM_API_KEY=your-key

代码里不写死任何地址，只从环境读：

python 复制代码

import os
from some_llm_sdk import Client

client = Client(
    base_url=os.environ["LLM_BASE_URL"],
    api_key=os.environ["LLM_API_KEY"],
)

Windows 用户在 PowerShell 里用 $env:LLM_BASE_URL="..." 设置同样的变量即可。这样切后端就是改一个环境变量的事，代码零改动。

一个容易踩的坑：路径拼接

切换后端时最常见的报错是 404，十有八九出在 base_url 的路径拼接上。不同 SDK 对 base_url 的处理逻辑不一样：有的会自动在后面补 /v1，有的要求你把完整路径写全。如果你手动多拼了一段，或者少拼了一段，就会 404。

排查方法很简单：对照目标后端的接口文档，确认它期望的完整路径，再看 SDK 默认会怎么拼，把重复或缺失的那一段调平即可。

顺带把多环境也管起来

后端地址一旦可配置，多环境管理就自然顺了。给每个环境准备一份 env 文件：

bash 复制代码

# .env.dev
LLM_BASE_URL=https://dev-backend.example.com

# .env.prod
LLM_BASE_URL=https://prod-backend.example.com

启动时加载对应的那份，同一份代码就能在不同环境间无缝切换，不用改任何逻辑。灰度、回滚、A/B 对比也都建立在这个基础上------本质上都是"切换后端地址"这一个动作。

小结

把 base_url 和 api_key 抽成环境变量，是接入大模型时投入产出比很高的一个小习惯。它让后端选择从"改代码"降级成"改配置"，顺带解决了多环境管理和密钥安全。真正需要切换后端的那一天，你会庆幸当初没把地址写死在代码里。