Node.js+Express开发的API在Postman中始终显示200，无法正确识别4XX等状态码

核心排查方向 #

前置代理/网关层强制改写状态码 #

这是最常见的故障原因：如果服务前面挂载了Nginx、云API网关、CDN等中间层，这类组件的默认配置往往会拦截后端返回的4xx、5xx状态码，统一包装成200响应，把错误信息塞到响应体中返回给客户端。

• 验证方法：在部署服务的服务器本地，直接用curl http://127.0.0.1:你的服务端口/接口路径发起请求，绕过所有前置代理。如果curl返回的状态码和代码预期一致，问题就出在前置代理的配置上，需要关闭代理层的错误状态码改写规则。

路由匹配顺序逻辑漏洞 #

Express的路由是按注册顺序从上到下匹配的：如果当前写的带404/500逻辑的路由，被前面注册的同路径路由、全局响应中间件提前拦截，直接返回了200响应，代码里的状态码分支根本不会被执行。

• 另外需要注意：一旦响应头已经发送给客户端，后续调用的res.sendStatus()、res.status()会被Express直接忽略，还可能触发Cannot set headers after they are sent的运行时警告，这类场景也会导致最终客户端收到的永远是第一次发送的200状态码。

现有代码的分支判断漏判 #

你当前的路由实现里，存在很容易触发200返回的逻辑漏洞：

• 对busca(0)的返回值判断不严谨：JS中空数组[]是真值，只要busca接口返回空集合，就会直接走200返回分支，永远不会触发else里的404逻辑，自然客户端一直收到200状态码。
• 文件读取的同步操作没有做单独异常捕获：如果存在权限不足、文件损坏等读文件失败的场景，虽然外层有全局try/catch，但要确认异常真的能被捕获并触发500状态码返回，没有被其他全局错误拦截器提前劫持。

客户端侧的干扰 #

Postman自身的缓存代理、本地抓包工具（如Charles、Fiddler）的自动状态码改写功能，也会导致界面显示的状态码和实际不符。可以新建无脚本、无环境变量的全新Postman请求重新验证。

代码优化参考 #

调整逻辑判断分支，避免漏判导致的状态码不匹配：

router.get('/', async (req, res) => {
  try {
    const dados = await busca(0);
    // 覆盖null、undefined、空数组三类无数据场景，确保正确触发404
    if (!dados || dados.length === 0) {
      return res.sendStatus(404);
    }

    const pasta = '/upload/'
    for (const [idx, row] of dados.entries()) {
      const nomearquivo = pasta + row.arquivotitulo;
      if (fs.existsSync(nomearquivo)) {
        try {
          const contents = fs.readFileSync(nomearquivo, {encoding:'base64'});
          dados[idx]['arquivotitulo64'] = contents;
        } catch (readErr) {
          console.log('文件读取失败', readErr)
        }
      }
    }
    return res.status(200).send(dados);
  } catch (err) {
    console.log(err);
    return res.sendStatus(500);
  }
});

内容的提问来源于stack exchange，提问作者Felipe Souza