核心是建立“请求→处理→响应”闭环：用curl需设curlopt_returntransfer=true、显式超时和ssl验证；api端点须设json头、用php://input读json、校验解析结果并统一返回状态码。
学 PHP API 编程，核心不是先背语法，而是快速建立「请求 → 处理 → 响应」的闭环认知。你不需要从框架开始，用原生 curl 和 $_SERVER['REQUEST_METHOD'] 就能跑通最简链路。
怎么用 curl 发出第一个有效请求
很多人卡在第一步：明明写了 curl_exec()，却收不到数据或返回空字符串。问题通常不在逻辑，而在默认行为没关掉。
-
CURLOPT_RETURNTRANSFER必须设为true，否则响应直接输出到页面，$response是null - 如果 API 返回 JSON，但响应头是
text/html，json_decode($response)会静默失败——先用var_dump($response)看原始内容 - 遇到 SSL 错误（如
cURL error 60），临时加curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false)排查，但上线前必须换回true并配好 CA 证书 - 超时要显式设置：
curl_setopt($ch, CURLOPT_TIMEOUT, 10)，否则默认可能等几分钟才报错
怎么写一个能被 Postman 调通的最简 API 端点
别一上来就写路由分发或数据库操作。先让 /api/test 返回固定 JSON，验证环境和基础流程是否通。
- 开头必须加
header('Content-Type: application/json; charset=utf-8')，否则前端解析可能乱码或失败 - 用
$_SERVER['REQUEST_METHOD']判断方法，不要依赖$_GET/$_POST——比如 POST 带 JSON body 时，$_POST是空的 - 读取 JSON body 要用：
$input = json_decode(file_get_contents('php://input'), true)，且需检查json_last_error() === JSON_ERROR_NONE - 返回前统一用
http_response_code(200)或对应状态码，别只靠echo
为什么 file_get_contents 有时比 curl 更快出错
它看着简单，但底层限制多，容易在非预期场景崩掉。
- 不支持 POST 带数组字段（
curl_setopt($ch, CURLOPT_POSTFIELDS, $array)可自动编码；file_get_contents需手动http_build_query()） - 无法设置连接超时（
timeout选项只控制读取超时），DNS 解析慢时会卡死 - 没有内置重试、重定向跟随控制，遇到 302 会直接返回空或报错
- 错误信息极难捕获——
file_get_contents失败只返回false，得靠error_get_last()拼凑原因，远不如curl_error($ch)直观
什么时候该放弃原生，上 Guzzle
当你开始反复写以下代码时，就是切换时机：
- 手动拼
Authorization: Bearer xxx+Content-Type+Accept头 - 为不同 API 写相似的重试逻辑（比如 5xx 时重试 2 次）
- 需要并发请求多个接口（
curl_multi_init太绕，Guzzle的Pool一行搞定） - 调试时想看完整请求/响应日志（
Guzzle的LogMiddleware开箱即用）
装完后第一行就写：$client = new \GuzzleHttp\Client(['timeout' => 10]);，别碰全局配置——每个 API 实例独立设 timeout、base_uri、headers 更安全。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
