Next.js生产环境getStaticProps请求Django GraphQL报400错误求助

安全阿岳

2026-7-22

Next.js生产构建后getStaticProps请求Django GraphQL返回400错误的原因分析

以下是导致该现象的核心原因，均源于开发/生产环境下，getStaticProps（服务端/构建阶段执行）与客户端useQuery（浏览器端执行）的运行环境差异：

环境变量配置不一致
开发模式下Next.js加载.env.development，生产构建时默认加载.env.production。如果生产环境中服务端专用的GraphQL端点变量（无NEXT_PUBLIC_前缀）配置错误（比如域名拼写错误、路径缺失），getStaticProps在构建阶段会用错误地址发起请求，触发400。而客户端useQuery使用的NEXT_PUBLIC_前缀变量配置正确，因此请求正常。
请求来源与CORS策略冲突
Django GraphQL服务的CORS配置通常只允许前端域名的浏览器请求，但生产构建时getStaticProps是在构建机器的服务端环境发起请求，请求来源为构建机器的IP或localhost，不在Django的CORS允许列表内，服务端直接判定请求无效返回400。而客户端useQuery的请求来源是合法的前端域名，符合CORS规则，所以正常响应。
CSRF保护验证失败
Django生产环境默认开启CSRF保护，客户端请求时浏览器会自动携带CSRF Cookie与Token，但getStaticProps在构建阶段发起的请求没有这些验证信息，Django会直接返回400错误。
请求格式或参数异常
开发模式下的调试工具（如Apollo DevTools）可能自动修正请求格式，但生产构建时代码压缩、混淆可能导致GraphQL查询字符串被意外转义，或者请求中依赖了浏览器专属变量（如window）导致参数缺失，进而触发400错误。
生产环境速率限制触发
生产构建时getStaticProps会批量生成页面，短时间内向Django发起大量请求，若Django配置了速率限制规则，会触发限制返回400，而客户端单页面的请求频率不会触发该规则。