17370845950

PHP构建API需正确设置JSON响应头、规范读取HTTP请求体、配置CORS跨域头、采用路由映射分离逻辑；否则易出现解析失败、跨域拦截、路由混乱等问题。

PHP 构建 API 接口本身不难，但直接裸写 $_GET / $_POST 容易踩路由混乱、内容类型错误、跨域失败、JSON 输出不规范等坑——尤其在前后端分离场景下。

怎么让 PHP 正确响应 JSON 请求

很多新手用 echo json_encode($data) 就以为完事了，但前端 fetch 会报 Unexpected token 或解析为空对象。根本原因是缺少正确的 HTTP 头：

• 必须手动设置 header('Content-Type: application/json; charset=utf-8')
• 如果用了 exit 或 die 之后还有输出（比如 BOM、空格、换行），JSON 就会损坏
• 避免在 json_encode() 前有任何 echo、var_dump 或未捕获的 warning 输出

简单示例：

header('Content-Type: application/json; charset=utf-8');
$data = ['status' => 'success', 'data' => ['id' => 123]];
echo json_encode($data, JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES);
exit;

如何处理不同 HTTP 方法（GET/POST/PUT/DELETE）

原生 PHP 不像框架那样自动路由，得靠 $_SERVER['REQUEST_METHOD'] 手动分发。容易忽略的是：PUT 和 DELETE 请求的 body 数据不能直接用 $_POST 读取。

• GET：参数走 $_GET，适合查询
• POST：表单数据走 $_POST，JSON 数据需用 file_get_contents('php://input')
• PUT/DELETE：一律用 file_get_contents('php://input') 获取原始 body，再 json_decode()
• 别忘了校验 Content-Type 头是否为 application/json，否则可能误解析

为什么 CORS 报错“No 'Access-Control-Allow-Origin' header”

这是浏览器拦截，不是 PHP 报错。后端没显式允许跨域，前端调用就会失败。解决方式不是关浏览器安全策略，而是加响应头：

• 开发阶段可全开：header('Access-Control-Allow-Origin: *')
• 生产环境建议限定域名：header('Access-Control-Allow-Origin: h

  

  ttps://your-frontend.com')
• 若带 cookie 或认证头，Access-Control-Allow-Origin 不能为 *，且要加 header('Access-Control-Allow-Credentials: true')
• 预检请求（OPTIONS）必须返回 200 并带上允许的方法：header('Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS')

如何避免路由和逻辑混在一起导致维护困难

一个 api.php 文件里塞满 if-else 判断路径和方法，很快变成意大利面条代码。最轻量的解法是用简单路由映射：

• 提取请求路径：$path = parse_url($_SERVER['REQUEST_URI'], PHP_URL_PATH)
• 用关联数组映射路径到函数：$routes = ['/users' => 'handleUsers', '/posts' => 'handlePosts']
• 检查 $routes[$path] 是否存在，再 call_user_func($routes[$path])
• 每个 handler 函数内部专注处理单一资源，不拼 SQL、不混 HTML 输出

复杂业务中，这种结构比硬编码 if 更易定位问题，也方便后续迁移到 FastRoute 或 Laravel 等工具。

真正卡住人的往往不是语法，而是 header 顺序、body 读取时机、BOM 字符、以及跨域配置漏掉某一行——这些细节在调试时看不到报错，只表现成前端收不到数据或解析失败。