PHP调用大模型API的关键难点是鉴权、请求体格式、流式响应处理和错误码识别；需用curl手动构造请求，严格设置header、JSON编码、超时及返回参数，并注意各厂商接口差异与认证机制。
PHP 调用大模型 API 不难，但容易卡在鉴权、请求体格式、流式响应处理和错误码识别这四点上。别信“封装好就能直接用”的说法，OpenAI、Anthropic、通义千问、DeepSeek 的接口行为差异比文档写的更明显。
curl 发起 POST 请求是最稳的起点
别一上来就装 SDK，尤其当你要对接多个厂商时。原生 curl 能让你看清每个字段是否发对、header 是否带全、body 是否 JSON 编码正确。SDK 往往隐藏了重试逻辑或自动转换，出问题反而更难定位。
关键点：
-
Content-Type必须设为application/json，漏掉会返回 400 或 “invalid request” - 必须用
json_encode()构造请求体，不能拼字符串 —— 特别注意中文、换行符、单双引号嵌套 - 务必设置
CURLOPT_TIMEOUT（建议 ≤ 60），大模型响应慢时 curl 默认会卡很久 - 启用
CURLOPT_RETURNTRANSFER，否则curl_exec()返回bool(true)而不是响应内容
OpenAI 兼容接口（如 DeepSeek、Ollama、Fireworks）要小心 base_url 和 model 名
很多国产模型标榜 “兼容 OpenAI”，但实际只兼容部分字段。比如 model 参数传 deepseek-chat 可能报错，得换成 deepseek-coder 或查它文档里真实注册的名称；base_url 末尾多一个 /（如 https://api.deepseek.com/v1/）会导致 404。
立即学习“PHP免费学习笔记（深入）”；
常见踩坑：
- 误把
api_key放 body 里 —— 它必须在Authorization: Bearer <key>header 中 - 用
stream: true却没处理 chunk 响应，导致 JSON 解析失败（返回的是以data:开头的 SSE 流） - 忽略
max_tokens，模型可能返回超长文本，PHP 内存溢出或超时
国内平台（通义千问、月之暗面、智谱）需额外处理 access_token 和签名
它们不走标准 Bearer Token，而是先调 /v1/oauth/token 换 access_token，且有效期短（通常 1 小时）。有些还要按规则拼接 signature（比如用 app_key + timestamp + nonce + body 做 HMAC-SHA256），漏一步就 401 或 403。
实操建议：
- 把 token 获取逻辑单独封装，加缓存（如写入
/tmp/qwen_token.json并检查expires_in） - 签名计算必须严格按文档顺序拼接字段，空格、换行、编码（URL encode 还是 rawurlencode）都不能错
- 通义千问的
messages字段要求role只能是system/user/assistant，传human会直接拒掉
错误响应必须逐字段解析，不能只看 HTTP 状态码
HTTP 200 不代表成功 —— 大模型 API 常用 200 包裹业务错误（如 {"error": {"code": "invalid_api_key", ...}}）；而 429 可能是限流，也可能是 key 写错了被当成未授权处理。
安全做法：
- 先用
json_decode($response, true)解析，再检查是否存在error键 - 记录完整请求和响应（脱敏后），尤其是
request_id字段，报错时客服只认这个 - 对
rate_limit_exceeded类错误，不要盲目重试，先确认是否配额用完或 key 绑定域名不符
真正麻烦的从来不是“怎么发请求”，而是各家对 temperature 的解释不一致、对 stop 字符串的截断时机不同、甚至同一个 model 名在不同 region 返回结果长度都不同。上线前，拿同一段 prompt 在各平台跑三轮，比读十遍文档有用。
