PHP cURL 调用 OpenAI API 需正确设置 Authorization（Bearer + API Key）、Content-Type、Accept 请求头，messages 必须为含 role 和 content 的索引数组并 json_encode；401 多因认证头格式错误，400 常因 messages 结构非法；用户输入须经 json_encode 转义防注入；流式响应在 Web 环境受限，建议同步调用；需合理配置超时与重试。
PHP cURL 调用 OpenAI API 的基本结构
OpenAI 官方不提供 PHP SDK，最直接可靠的方式是用 cURL 发起 POST 请求到 https://api.openai.com/v1/chat/completions。关键不是“能不能调”，而是请求头、请求体、错误处理是否到位。
必须设置的请求头有三个：Authorization（带 Bearer 前缀的 API Key）、Content-Type（固定为 application/json）、Accept（建议显式设为 application/json）。
-
model参数必须明确指定，如"gpt-3.5-turbo"或"gpt-4"，填错会返回 404 或 400 错误 -
messages是数组，每个元素必须含role（"system"/"user"/"assistant"）和content字符串 - 别漏掉
json_encode()整个请求体，且 PHP 数组要确保是索引数组（避免关联数组导致 JSON 键乱序）
常见 401 / 400 错误的定位方法
401 表示认证失败，99% 是 Authorization 头格式不对：不能写成 "Bearer: sk-xxx"（冒号多余），也不能漏掉 "Bearer " 前缀空格；API Key 是否已过期或被删除，需登录 OpenAI 平台确认。
400 多半是 JSON 结构问题：messages 为空、role 值拼错（比如写成 "User" 或 "client"）、content 为 null 或非字符串。调试时可用 json_last_error_msg() 检查编码失败原因。
立即学习“PHP免费学习笔记（深入）”；
- 用
curl_getinfo($ch, CURLINFO_HTTP_CODE)显式捕获状态码，不要只靠curl_exec()返回值判断成功 - 开启
CURLOPT_VERBOSE并重定向到fopen('php://temp', 'r+b')可查看完整请求/响应头，比盲猜高效得多 - OpenAI 返回的错误信息在响应体的
error.message字段里，记得json_decode($response, true)后取值
如何安全传入用户输入并防止 prompt 注入
用户发来的文本不能直接拼进 messages 数组。哪怕只是加个换行或引号，都可能破坏 JSON 结构或诱导模型越狱——这不是 XSS，但后果类似。
- 对用户输入做
json_encode()再赋值给content，这是最简单有效的转义方式（PHP 7.1+ 默认处理 Unicode 和控制字符） - 避免在
systemrole 中动态插入用户数据；若必须上下文控制，用独立user消息传递，而非拼接字符串 - 服务端需限制单次请求长度：
strlen(json_encode(['content' => $input]))超过 8000 字节就截断，否则 OpenAI 直接拒收
流式响应（stream=true）在 PHP 中的实际限制
OpenAI 支持 stream=true 返回 SSE 格式数据，但 PHP-FPM 或 Nginx 默认缓冲整个响应体才吐给浏览器，无法实现真正流式输出。强行用 ob_flush() + flush() 在多数托管环境无效。
- CLI 模式下可稳定流式读取，适合做后台任务或命令行工具
- Web 场景建议关闭
stream，用普通同步请求；前端用轮询或 WebSocket 模拟“打字效果”更可控 - 若坚持流式，需确保 Web 服务器禁用缓冲（Nginx 配置
proxy_buffering off，Apache 关闭mod_deflate），且 PHP 不启用output_buffering
token 计数、超时控制、重试逻辑这些看似次要的点，上线后往往比模型调用本身更容易出问题。特别是 timeout 设太短会导致大量 0 字节响应，而设太长又拖垮用户体验——建议初值用 CURLOPT_TIMEOUT_MS => 15000，再根据实际 P95 延迟调整。
