PHP接口需设Content-Type为application/json并避免输出干扰,JSON请求须读php://input,跨域需正确处理OPTIONS预检,参数应过滤校验,数据库操作禁用SQL拼接。
前端(尤其是 Fetch 或 Axios)默认期望收到 application/json 响应,如果 PHP 只用 echo json_encode($data) 而不设头,前端可能解析失败或触发 CORS 预检异常。
实操建议:
header('Content-Type: application/json; charset=utf-8');
var_dump() 或 print_r() 残留http_response_code(200) 或对应状态码(如 400/401/500),前端可据此分支处理header('Content-Type: application/json; charset=utf-8');
http_response_code(200);
echo json_encode(['code' => 0, 'msg' => 'success', 'data' => ['id' => 123]], JSON_UNESCAPED_UNICODE);
GET 参数走 $_GET,POST 表单(application/x-www-form-urlencoded)走 $_POST,但 Fetch/Axios 默认发的是 application/json —— 此时 $_POST 为空,必须手动读取原始输入。
常见错误现象:前端发了 JSON 数据,PHP 却收不到任何值,$_POST 是空数组

实操建议:
$_SERVER['REQUEST_METHOD'] === 'POST'
strpos($_SERVER['CONTENT_TYPE'], 'application/json') !== false
$raw = file_get_contents('php://input'); $data = json_decode($raw, true);
$input = $_POST;
if (empty($_POST) && strpos($_SERVER['CONTENT_TYPE'], 'application/json') !== false) {
$raw = file_get_contents('php://input');
$input = json_decode($raw, true) ?: [];
}
简单 GET 请求加 Access-Control-Allow-Origin: * 能跑通,但一旦前端带认证(credentials: true)、自定义 Header(如 X-Token)或用 PUT/DELETE 方法,浏览器会先发 OPTIONS 预检请求 —— 此时若后端没响应预检,接口直接被拦在浏览器层,PHP 代码根本不会执行。
实操建议:
if ($_SERVER['REQUEST_METHOD'] === 'OPTIONS') { http_response_code(200); exit; }
Access-Control-Allow-Origin 不能为 *,需指定具体域名(如 https://your-fe.com)header('Access-Control-Allow-Headers: X-Token, Content-Type');、header('Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS');
cors.php),所有接口开头 require_once 'cors.php';
裸用超全局变量容易引入安全漏洞(如 SQL 注入、XSS)、类型混淆(字符串 ID 当整数用)、缺失校验(前端绕过 JS 校验直接调用)。
实操建议:
$id = filter_input(INPUT_GET, 'id', FILTER_VALIDATE_INT) ?: 0;
Authorization Header 中的 token,并解析验证(别手写 JWT 解码)复杂点往往不在语法,而在边界:前端可能传空字符串、负数 ID、超长字符串、非法 JSON 结构——这些都要在接口入口就拦截,而不是让业务逻辑崩溃后才报 500。