axios 在 get 请求中传递 data 时会错误地设置 content-type: application/json 并忽略请求体数据，php curl 需模拟该非标准行为才能兼容——关键不是发送 post 数据，而是添加误导性 json 头并保持纯 get。
在将 Axios GET 请求迁移到 PHP 时，一个常见误区是直接将 data 作为请求体（CURLOPT_POSTFIELDS）发送。但正如 Axios 文档和实际行为所示：GET 请求不支持请求体（body）。当 Axios 配置 method: 'get' 同时指定 data 时，它并不会将数据序列化为 URL 查询参数，也不会真正发送 data 字段；相反，它仅设置 Content-Type: application/json 请求头（即使 body 为空），这本质上是一种不符合 HTTP 规范的“伪行为”。
因此，你原始的 cURL 尝试存在两个根本性错误：
- ❌ 使用 CURLOPT_POSTFIELDS + CURLOPT_CUSTOMREQUEST: "GET"：HTTP GET 不应携带请求体，多数服务端会直接忽略或报错；
- ❌ 未设置 Content-Type: application/json 头：导致服务端无法识别“Axios 风格”的 GET 请求，返回空响应或 400 错误。
✅ 正确做法是：
- 使用标准 CURLOPT_HTTPGET => true（或省略，cURL 默认为 GET）；
- 显式添加 Content-Type: application/json 请求头（尽管逻辑上不合理，但这是 Axios 的实际行为）；
- 不发送任何请求体（data 字段在此场景下被 Axios 丢弃，不应在 PHP 中尝试补全）；
- 启用 CURLOPT_RETURNTRANSFER 获取响应内容，并进行错误处理。
以下是可直接运行的完整 PHP 示例：
立即学习“PHP免费学习笔记（深入）”；
$url,
CURLOPT_HTTPGET => true,
CURLOPT_RETURNTRANSFER => true,
CURLOPT_FOLLOWLOCATION => true,
CURLOPT_TIMEOUT => 30,
CURLOPT_HTTPHEADER => [
'Content-Type: application/json',
// 如需认证或其他头，可在此追加，例如：
// 'Authorization: Bearer your-token'
],
]);
$response = curl_exec($ch);
$httpCode = curl_getinfo($ch, CURLINFO_HTTP_CODE);
$error = curl_error($ch);
curl_close($ch);
if ($error) {
die("cURL Error: " . $error);
}
if ($httpCode >= 400) {
echo "HTTP Error: " . $httpCode . "\n";
var_dump($response);
exit;
}
// 假设 API 返回 JSON
$result = json_decode($response, true);
if (json_last_error() !== JSON_ERROR_NONE) {
echo "JSON Parse Error:\n";
var_dump($response);
} else {
echo "Success:\n";
var_dump($result);
}
?>⚠️ 重要提醒：
- 不要尝试把 apikey 和 id 拼入 URL 查询字符串（如 ?apikey=...&id=...），除非服务端明确要求查询参数——这与原始 Axios 行为完全不符；
- 不要使用 http_build_query() + CURLOPT_POSTFIELDS，GET 请求发送 body 是无效且不可靠的；
- 如果你控制后端，强烈建议修正接口设计：GET 请求应通过 URL 参数传参（/123456789/?apikey=...&id=...），或改用 POST/PUT 请求体接收结构化数据；
- Axios 此行为已被社区广泛视为反模式（GitHub issue #2183），未来版本可能移除或修正，故生产环境应避免依赖该特性。
总结：迁移的核心不是“功能等价”，而是“行为克隆”——PHP cURL 必须复现 Axios 的非标准请求头，而非逻辑上更合理的实现。
