PHP API发起PUT请求创建玩家时返回200状态码但响应为空JSON数组

当前问题现象 #

向/players端点发起PUT请求创建新玩家时，服务器返回200成功状态码，但响应体为空JSON数组[]，没有返回预期的玩家创建结果。

逐层排查方向 #

1. 确认代码实际执行路径 #

• 能拿到200状态码说明请求没有匹配到代码里写的404兜底分支，大概率已经进入case 'players'对应的handle_player函数，不存在路由完全匹配失败的问题。
• 最容易被忽略的逻辑漏洞：case 'players'分支调用完handle_player后没有加exit终止脚本。对比其他分支，比如默认404分支写完header后是有exit的，如果handle_player内部没有主动输出内容、没有终止执行，脚本会继续走到后续流程，很可能被末尾的默认空JSON输出覆盖真实返回。

2. 检查handle_player函数内部逻辑 #

• 确认函数是否做了请求方法分支判断：如果函数只实现了GET方法（拉取玩家列表）的返回逻辑，没有针对PUT创建玩家的分支处理，就会直接走到函数的默认兜底逻辑，返回空数组[]，且因为没有主动修改响应状态码，最终对外返回200。
• 确认入参解析是否正常：前端传的是JSON格式的请求体，PHP端是通过file_get_contents('php://input')读取后json_decode得到$input，如果请求体格式不合法、或者服务器配置限制了php://input的读取权限，会导致$input为null，后续创建玩家因为缺少username等必填参数，走异常分支直接返回空结果，不会抛出可见错误。
• 确认数据库操作是否静默失败：如果创建玩家的SQL执行报错、或者创建完成后查询玩家信息的SQL写错，会拿到空的查询结果集，直接被json_encode成空数组返回，全程不会在响应中显示错误信息。

3. 快速定位问题的调试手段 #

• 在handle_player函数最开头插入硬编码调试输出，输出完成后直接终止脚本：

  echo json_encode([
    'debug_flag' => 'success hit players handler',
    'request_method' => $method,
    'parsed_input' => $input,
    'remaining_path_params' => $request
  ]);
  exit;
  

  重新发起请求查看返回：
  • 如果看不到这段debug信息，说明根本没走到handler内部，回头检查PATH_INFO的解析结果是否符合预期
  • 如果能看到debug信息，逐行检查后续逻辑的变量值，顺着打印的信息往下排查即可
• 直接查看PHP运行时的错误日志，这类静默的数据库报错、JSON解析错误都会记录在日志里，不会直接体现在接口响应中。

内容的提问来源于stack exchange，提问作者Θωμάς Κέρτζαλης