thinkphp 应使用 $request->header('content-type') 获取原始 content-type 请求头，而非 $_server['content_type']；内部自动标准化键名，返回如 "application/json; charset=utf-8" 的字符串，需用 strtok($contenttype, ';') 提取主 mime 类型。
ThinkPHP 怎么获取原始 Content-Type 请求头
ThinkPHP 默认不直接提供 Content-Type 的独立读取方法，它被归入请求头（header）体系，必须通过统一的 header 读取接口获取。直接访问 $_SERVER['CONTENT_TYPE'] 在某些 SAPI（如 CLI、FastCGI）下可能为空或格式异常，不可靠。
推荐做法是使用 Request 对象的 header() 方法，并注意键名大小写和 HTTP 协议规范：
-
header('content-type')是最稳妥的写法，ThinkPHP 内部会自动标准化键名（忽略大小写，转为小写匹配） - 不要写成
header('Content-Type')或header('CONTENT_TYPE')—— 虽然部分版本兼容，但非标准用法，易在升级后失效 - 返回值是字符串，例如
"application/json; charset=utf-8"或"multipart/form-data; boundary=----..."，需自行解析
Content-Type 值为空或读不到的常见原因
不是代码写错，而是环境或客户端行为导致的典型问题：
- 前端用
fetch或axios发送 JSON 数据时，没显式设置headers: {'Content-Type': 'application/json'}，浏览器可能默认发text/plain或干脆不带该头 - Postman 测试时选了 “form-data” 模式但没填 key-value，实际发出的是空 body + 无
Content-Type头 - Nginx 配置了
underscores_in_headers off;（默认值），而某些代理或调试工具用下划线传头（如Content_Type），会被直接丢弃 - ThinkPHP 的
isAjax()或isPost()判断会提前触发 body 解析，某些情况下干扰 header 读取顺序（少见，但 v6.0+ 中有修复记录）
怎么安全提取 Content-Type 的媒体类型（MIME type）
只拿完整字符串不够，多数场景需要判断是 application/json 还是 multipart/form-data。别用 strpos() 硬匹配，要处理 charset、boundary 等参数：
// TP6 示例
$contentType = $request->header('content-type');
$mimeType = strtok($contentType, ';'); // 只取分号前主类型
switch (trim($mimeType)) {
case 'application/json':
// 处理 JSON 请求体
break;
case 'multipart/form-data':
// 处理文件上传
break;
case 'application/x-www-form-urlencoded':
// 处理表单编码
break;
}
注意：strtok() 比 explode() 更轻量，且能正确应对多个分号或空格；trim() 防止头部空格导致匹配失败。
为什么不能依赖 $request->method() 或 input() 来反推 Content-Type
这是新手常踩的坑：看到 POST 请求就默认是表单，看到 JSON 就手动解析 input()。但这两者完全解耦：
-
$request->method()返回的是 HTTP 方法（POST、PUT），和请求体格式无关 -
$request->input()在未指定$filter时会尝试自动识别并解析 body，但它内部也是先读Content-Type才决定如何解析 —— 如果你跳过这步，等于绕开协议约定 - 例如：一个
PUT请求带Content-Type: application/json，input()可能正常返回数组；但若头缺失，input()就返回原始字符串甚至 null，无法区分是客户端错误还是数据为空
真正需要判断数据格式的地方，必须显式读取并校验 Content-Type，而不是靠行为推测。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
