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 解析，结果出错。
立即学习“PHP免费学习笔记（深入）”；
- 检查
$_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
php://input 取附带结构化数据。漏掉任一环节，DELETE 接口就会“收不到参数”。 
