配置no-cors模式的Fetch POST请求服务端request.body为空的问题排查

核心触发原因：no-cors请求模式的限制 #

• 你在fetch配置里加了mode: "no-cors"，这个模式本身就不适合用于需要后端解析JSON请求体的业务接口调用。no-cors模式的设计初衷是允许前端向跨域地址发送无权限限制的简单请求，从规则上禁止前端手动设置任意自定义请求头。
• 你代码里手动设置的Content-Type: application/json请求头，在no-cors模式下会被浏览器直接丢弃，实际发出的请求会被强制设置Content-Type为text/plain。
• 你在控制台打印的序列化JSON数据确实会作为请求体被浏览器发送出去，但主流服务端框架的JSON请求体解析逻辑（比如Express的express.json()、NestJS的全局body解析中间件），只会对Content-Type匹配application/json的请求执行body解析，碰到text/plain类型的请求会直接跳过解析流程，最终路由处理函数读到的req.body自然就是空对象。
• 额外的异常佐证：no-cors模式下前端本身不允许读取服务端返回的响应内容，你代码里后续写的await response.json()逻辑在这种模式下根本无法正常执行，会直接抛出读取响应被拒绝的错误。

其他可能的诱因 #

• 服务端的body解析中间件挂载顺序错误：如果JSON解析中间件没有放在登录接口路由的最前面，请求路由执行时还没完成请求体流的读取和解析，就会导致读取到的body为空。
• 链路中存在反向代理（如Nginx）配置问题：如果代理层设置了请求体大小截断、或者直接剥离请求头/请求体的规则，服务端进程拿到的请求就是不完整的，自然解析不出有效内容。
• 本地开发环境的请求转发配置错误：如果前端配置了本地devServer的代理规则，规则指向了错误的服务端口/实例，你实际发请求的目标服务没有配套的JSON解析逻辑，也会解析出空的body对象。
• 去掉no-cors开启正常跨域模式后，如果服务端没有正确配置CORS允许的请求头范围，浏览器会在正式POST请求发送前的预检阶段就拦截请求，导致真正带body的请求根本没到达服务端，这类场景也会出现类似的空body现象。

内容的提问来源于stack exchange，提问作者Artem Kablihin