最简可用PHP请求需三要素：固定URL（https://dashscope.aliyuncs.com/api/v1/services/aigc/text-generation/generation）、Authorization头（Bearer sk-xxx）、Content-Type: application/json，且body必须json_encode()后传入；模型响应结构不统一，qwen-max用output.text，qwen-long等用choices[0].message.content，需按endpoint区分解析。
PHP 调用通义千问 API 不需要 SDK，但必须严格按 DashScope 的 REST 接口规范构造请求；用错地址、漏签名头、body 不是 JSON 字符串，三者任一都会直接 401 或 400。
怎么发一个最简可用的 POST 请求
DashScope 当前（2026 年）只接受 https://dashscope.aliyuncs.com/api/v1/services/aigc/text-generation/generation 这个固定地址，不是控制台里随便复制的服务地址，也不是旧版 api-dashscope 子域名。很多 PHP 开发者卡在这一步，DNS 解析失败或返回 404，其实只是 URL 写错了。
最小可行代码只需三要素：
-
Authorization: Bearer sk-xxx—— 必须是 DashScope 控制台生成的以sk-开头的 API Key，不是 RAM 的LTAI开头 AK/SK -
Content-Type: application/json—— 缺少这个 header，哪怕 body 是合法 JSON，也会被拒 -
json_encode($data)后传给CURLOPT_POSTFIELDS—— 不能直接传 PHP 数组，否则服务端解析失败
示例片段：
立即学习“PHP免费学习笔记（深入）”；
$data = [
'model' => 'qwen-max',
'input' => [
'messages' => [['role' => 'user', 'content' => '你好']]
]
];
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, 'https://dashscope.aliyuncs.com/api/v1/services/aigc/text-generation/generation');
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_POST, true);
curl_setopt($ch, CURLOPT_POSTFIELDS, json_encode($data));
curl_setopt($ch, CURLOPT_HTTPHEADER, [
'Authorization: Bearer ' . $_ENV['QWEN_API_KEY'],
'Content-Type: application/json',
'User-Agent: aliyun-dashscope-php'
]);
$response = curl_exec($ch);
为什么用 qwen-long 模型时返回字段结构不一样
不同模型的响应体结构不统一：qwen-max 返回的是 output.text，而 qwen-long 和兼容 OpenAI 协议的接口（如 /compatible-mode/v1/chat/completions）返回的是 choices[0].message.content。硬写一个通用解析逻辑会出错。
统一LLM网关 - 一个API对接70+AI模型，使用单一API密钥即可调用GPT、Claude、Gemini、Qwen、Deepseek、Grok等主流模型。
实际处理建议：
- 明确你用的是哪个 endpoint：走
/text-generation/generation就按output.text取值；走/chat/completions就按 OpenAI 格式取 - 不要依赖
$response['output']['choices']去适配所有模型 ——qwen-max根本没有choices字段 - 检查
$response['code']和$response['message']，比 HTTP 状态码更准；比如ResourceNotFound很可能是因为用了旧 endpoint
中文内容乱码或 InvalidSignature 怎么排查
签名错误和中文乱码常被混为一谈，但根源完全不同：InvalidSignature 是认证失败，Content-Type 错、X-Ca-Timestamp 时间偏差超 15 分钟、body 的 SHA256 没算对，都可能触发它；而中文乱码是响应没设 UTF-8 解码或请求 body 本身含非法字节。
关键检查点：
-
json_encode()前确保输入字符串是 UTF-8 编码，用mb_convert_encoding($str, 'UTF-8')预处理 - 签名计算时，
body的 SHA256 必须是对 JSON 字符串字节流哈希，不是对 PHP 数组；空 body 也要算hash('sha256', '') - 如果用
file_get_contents替代 cURL，记得设stream_context_create(['http' => ['method' => 'POST', 'header' => $headers, 'content' => json_encode($data)]])，否则 header 无效
流式输出（stream=true）在 PHP 中怎么接住
流式响应不是一次返回完整 JSON，而是多段以 data: 开头的 SSE 数据块，每块可能是部分文本、done 或错误信息。PHP 默认 cURL 不支持自动解析这种格式。
实操要点：
- 必须设
curl_setopt($ch, CURLOPT_WRITEFUNCTION, $callback)，自己处理每次收到的数据块 - 回调函数里要识别
data: { ... }行，跳过空行和注释行（:开头） - 别用
json_decode($line)直接解 —— 有些行是data: [DONE]，不是 JSON；先trim()再判断是否以data:开头 - 流式 endpoint 是
/compatible-mode/v1/chat/completions，不是/text-generation/generation，后者不支持stream
真正容易被忽略的是：流式响应中每个 data: 块里的 content 字段可能被截断，需拼接后按 token 边界做分段展示，不能简单 echo 完事。
