Express中配置express.json()后req.body取值为undefined的问题排查

在完成挂载顺序校验、urlencoded配置补充、依赖完整性排查后，排除基础配置问题，剩余常见根因可按排查优先级逐一验证：

1. 请求配置与接口规则不匹配 #

express.json() 中间件仅会解析Content-Type请求头匹配application/json的POST类请求体，两类高频错配会导致req.body为空：

• 请求头不匹配：选了raw格式的请求体但类型选了Text/HTML，而非JSON；手动添加了错误的Content-Type头（比如text/plain）；误选了form-data、x-www-form-urlencoded格式的请求体但内容是手写JSON，和Content-Type不匹配。哪怕请求体内容是合法JSON，只要Content-Type不匹配，解析器会直接跳过该请求，不会做格式转换。
• 请求方法不匹配：如果路由中create接口仅注册为POST方法，但发起请求时用了GET、其他非对应方法，GET请求本身不携带可解析的请求体，自然读不到参数。

2. express.urlencoded 配置缺失兼容参数 #

从Express 4.16版本开始虽然内置了urlencoded解析能力，但调用时如果不传{ extended: true }配置，在处理嵌套结构、特殊编码的表单参数时会出现静默解析失败，不会抛出可被业务代码捕获的错误。

基础可用的配置写法为：app.use(express.urlencoded({ extended: true }))

3. 前置中间件提前消费请求可读流 #

JSON和表单参数解析的本质是读取请求携带的可读流内容做格式转换：

• 所有挂载在express.json()之前的中间件（哪怕未在示例代码中列出，比如自定义的身份校验、流量统计类中间件），如果有代码主动读取了请求流（比如监听req的data事件、手动把req管道转发到其他处理逻辑），后续的json解析器就会拿不到完整的流数据，最终解析结果为空。
• 示例代码中列出的morgan、cors、helmet默认都不会消费请求流，需要重点排查项目里额外挂载的、未展示的前置中间件逻辑。

4. 请求体损坏导致解析被静默跳过 #

Express内置的json解析器碰到请求体JSON格式不合法、网络传输截断的情况，默认不会抛出可被业务路由try/catch捕获的错误，而是直接把req.body置为空对象。

• 常见触发场景：本地抓包代理、安全软件的网络拦截截断了请求体；Postman中输入的JSON存在语法错误（比如漏写引号、多了冗余逗号）。

• 在路由挂载之前、所有解析中间件之后，加一行日志直接打印req.headers['content-type']和req.body的值，确认进入路由前的解析结果是否为空
• 临时给express.json添加解析校验逻辑，捕获被静默处理的解析错误：

  app.use(express.json({
    verify: (req, res, buf) => {
      try { JSON.parse(buf.toString()) } catch (e) { console.log('JSON解析失败：', e) }
    }
  }))
  

• 对照检查Postman的请求配置，确认请求方法、Content-Type头、请求体格式和接口要求完全匹配

内容的提问来源于stack exchange，提问作者Oge Obubu