17370845950

PHP无法通过$_DELETE获取DELETE请求数据，需用file_get_contents("php://input")读取原始请求体并手动解析JSON，或从URL路径及查询参数提取ID。

PHP 无法直接通过 $_DELETE 获取 DELETE 请求数据

PHP 的超全局数组里根本没有 $_DELETE —— 这是常见误解。DELETE 请求通常不带表单编码体（application/x-www-form-urlencoded），而是以 application/json 或纯文本、空体形式发送，$_POST 和 $_GET 都不会自动解析它。

用 file_get_contents("php://input") 读取原始请求体

这是处理 DELETE（以及 PUT、PATCH）请求数据最可靠的方式，适用于所有非 multipart/form-data 类型的请求体。

• 必须在脚本开头读取，且只能读一次；后续再调用会返回空字符串
• 如果前端发的是 JSON，需手动 json_decode() 解析
• 若请求体为空（如仅靠 URL 路径标识删除目标），php://input 会返回空字符串，此时应依赖 URL 参数或路由变量
• Apache + mod_php 下正常；PHP-FPM 环境下也兼容，但注意 enable_post_data_reading = Off 会禁用该流（极少配置）

$rawData = file_get_contents("php://input");
if (!empty($rawData)) {
    $data = json_decode($rawData, true);
    if (json_last_error() !== JSON_ERROR_NONE) {
        http_response_code(400);
        echo json_encode(['error' => 'Invalid JSON']);
        exit;
    }
} else {
    $data = [];
}

配合路由提取 ID：别只盯着请求体

RESTful 删除通常形如 DELETE /api/users/123，关键 ID 在 URL 路径中，而非请求体。PHP 原生不解析 PATH_INFO，需自行处理：

• 确保 Web 服务器将请求正确转发到入口文件（如 .htaccess 重写规则或 Nginx 的 try_files）
• 用 parse_url($_SERVER['REQUEST_URI'], PHP_URL_PATH) 提取路径，再用正则或 explode() 拆分
• 不要混淆 $_SERVER['PATH_INFO'] 和实际路径——它依赖 CGI 设置，不可靠；推荐直接解析 REQUEST_URI
• 示例路径 /api/posts/45?force=true 中，ID 是 45，force 是查询参数，应从 $_GET 读取

Content-Type 不匹配会导致 php://input 为空

某些客户端（尤其是旧版 jQuery 或未设 header 的 fetch）可能发 DELETE 请求却不带 Content-Type，或设为 text/plain，但后端仍按 JSON 解析，结果出错。

• 检查 $_SERVER['CONTENT_TYPE'] 是否为 application/json 再决定是否 json_decode
• 允许无 body 的 DELETE：不强制要求有数据，很多规范只要求 URL 定位资源
• 调试时用 var_dump($_SERVER['REQUEST_METHOD'], $_SERVER['CONTENT_TYPE'], file_get_contents('php://input')); 快速定位问题
• Nginx 默认限制 DELETE 请求体大小为 0，若需传数据，需显式配置 client_max_body_size

实际删除逻辑本身（比如查库、软删、事务）取决于业务，但数据入口就这两条路：URL 路径取 ID，php://input 取附带结构化数据。漏掉任一环节，DELETE 接口就会“收不到参数”。