OpenAI的API本质上是标准的HTTP服务，任何能发HTTP请求的工具理论上都能调用它。Python生态里最常见的两种方式，一种是直接用requests库手写请求，另一种是安装官方提供的openai SDK。两种方式都能完成任务，但在开发体验、稳定性、可维护性上差别不小。本文将通过实际代码对比两种方案的差异，并给出具体的选型建议。
一、requests直接调用：最朴素也最透明的方式
requests是Python最流行的HTTP库，用它调用OpenAI API本质上就是向https://api.openai.com/v1/chat/completions发送一个POST请求。这种方式的好处是完全透明，请求头怎么设置、请求体怎么构造、超时怎么控制，全部由你自己决定，没有任何黑盒。
先看一个基础示例，完成一次对话补全请求：
import requests
url = "https://api.openai.com/v1/chat/completions"
headers = {
"Authorization": "Bearer sk-你的密钥",
"Content-Type": "application/json"
}
payload = {
"model": "gpt-4o-mini",
"messages": [
{"role": "system", "content": "你是一个专业的Python编程助手"},
{"role": "user", "content": "用一句话解释什么是装饰器"}
],
"temperature": 0.7
}
resp = requests.post(url, headers=headers, json=payload, timeout=60)
if resp.status_code == 200:
data = resp.json()
print(data["choices"][0]["message"]["content"])
else:
print(f"请求失败: {resp.status_code}, {resp.text}")
这段代码清晰展示了API的原始面貌：鉴权靠Authorization请求头，参数通过JSON体传递，返回结果从choices数组中提取。对于想深入理解API机制的开发者来说，先手写一遍requests版本非常有价值，之后再看SDK的行为就一目了然了。
不过requests方式的短板也很明显。第一，你需要自己处理分页、重试、超时、限流等所有细节，比如OpenAI返回429限流错误时，官方建议做指数退避重试，手写这套逻辑并不简单。第二，解析结果全靠自己取字段，模型返回结构变化时没有类型提示兜底。第三，流式输出需要手动处理stream=True时的分块传输编码，代码复杂度明显上升。
二、官方openai SDK：开箱即用的工程化封装
官方SDK把这些脏活累活都封装好了。安装命令是pip install openai，新版本（1.x之后）的用法如下：
from openai import OpenAI
client = OpenAI(
api_key="sk-你的密钥",
# 如果使用第三方中转服务，可以修改base_url
# base_url="https://ipipp.com/v1"
)
response = client.chat.completions.create(
model="gpt-4o-mini",
messages=[
{"role": "system", "content": "你是一个专业的Python编程助手"},
{"role": "user", "content": "用一句话解释什么是装饰器"}
],
temperature=0.7
)
print(response.choices[0].message.content)
对比requests版本，代码量差不多，但背后多了很多东西。SDK默认内置了连接池复用，多次调用时不用反复建立TCP连接；内置了带指数退避的自动重试机制，遇到超时、429限流、5xx服务器错误时会自动重试，开发者无需手写重试循环；返回值是带类型提示的对象，IDE可以自动补全response.choices[0].message.content这样的链式属性，拼错字段名时编辑器会直接提示。
流式输出更能体现差距。SDK只需要传一个stream=True参数，然后迭代返回对象即可：
from openai import OpenAI
client = OpenAI(api_key="sk-你的密钥")
stream = client.chat.completions.create(
model="gpt-4o-mini",
messages=[{"role": "user", "content": "写一首关于秋天的短诗"}],
stream=True
)
for chunk in stream:
content = chunk.choices[0].delta.content
if content:
print(content, end="", flush=True)
如果用requests实现同样的流式效果，需要设置stream=True，然后逐行读取响应体、解析data: 前缀、处理SSE格式的每一帧、还要处理[DONE]结束标记，代码量至少翻两倍，而且很容易在边界情况上踩坑。SDK还封装了Function Calling、结构化输出（JSON mode）、文件上传等高级功能，调用方式统一且经过官方测试，稳定性有保障。
三、如何选择：结合场景做决策
两种方案没有绝对优劣，关键看你的使用场景。可以从以下几个维度来权衡：
- 部署环境限制：如果目标环境不方便安装额外依赖，比如某些受限的内网服务器、Serverless函数对包体积敏感，requests方案几乎零负担，Python标准库之外只需要一个requests（甚至可以用标准库的
urllib或httpx替代）。 - 是否使用中转接口：很多国内项目使用兼容OpenAI格式的中转服务。官方SDK支持通过
base_url参数切换接口地址，兼容性很好；requests方式则更加灵活，任何格式的接口都能适配。 - 项目规模与维护性：长期维护的生产项目优先选SDK。自动重试、连接复用、类型提示这些能力，在大量调用场景下能显著降低出错概率，减少手写代码的维护成本。
- 学习目的：如果是想深入理解API协议本身，或者需要在非Python语言中复刻调用逻辑，先用requests手写一遍是最好的学习路径。
还有一种常见做法是两者结合：用requests做一次性验证或调试，确认接口行为后再切换到SDK做正式开发。另外无论用哪种方式，都强烈建议把密钥放在环境变量中而不是硬编码，生产环境还应加上请求日志、费用统计和调用频率监控。
总结一下：requests适合轻量、透明、依赖最少的使用场景；官方SDK适合生产环境、高频调用、需要流式和高级功能的项目。对绝大多数正式项目来说，官方SDK是更稳妥的默认选择，而理解requests层面的原理，会让你在使用SDK遇到问题时更从容地排查。
OpenAI APIPython requestsopenai SDK修改时间：2026-09-02 00:32:30