非浏览器首次请求时，Next.js配置fallback:true的getStaticProps不生效

当前异常是Next.js静态生成流程在fallback: true配置下，和非浏览器请求的适配逻辑不匹配导致的，具体触发链路如下：

• 当getStaticPaths配置fallback: true时，对列表中未预先生成的路径，Next.js首次收到请求时不会立刻执行getStaticProps拉取数据，而是直接返回一个不包含任何业务数据的占位HTML空壳，这个逻辑原本是为了适配客户端路由跳转时的加载态场景。
• 浏览器请求拿到这个占位空壳后，Next.js会在后台同步触发该路径的静态生成流程：等getStaticProps执行完成、带完整数据的静态页面生成并写入缓存后，浏览器会通过内置的路由逻辑自动替换成完整内容，所以浏览器访问时表现完全正常。
• 像Python脚本这类不带客户端渲染逻辑的非浏览器请求，拿到第一波返回的占位空壳后就直接终止请求了，既不会等待后台的静态生成流程走完，也没有客户端脚本触发后续的内容替换逻辑，所以最终拿到的就是event为undefined的空内容，服务端日志里也不会出现getStaticProps fired...的记录——因为这个路径的首次请求根本没有走到getStaticProps的执行分支。这也是第三方元标签检测工具识别到页面title、description为空的核心原因——占位空壳本身不会注入任何服务端渲染的Meta标签内容。

• 核心调整：将getStaticPaths中的fallback取值从true改为*'blocking'*。
  该配置的运行逻辑和原true模式完全不同：对所有未在paths列表中声明的路径，首次请求会在服务端同步完成getStaticProps执行、业务数据拉取、静态页面生成、缓存写入的全流程，全部步骤完成后才会把带完整数据的HTML返回给请求方。不管请求来自浏览器、Python脚本还是第三方元标签检测工具，拿到的都是带完整业务内容、Meta标签的最终静态页面，不会再出现返回空壳的问题。
• 调整后的代码示例：

export async function getStaticPaths() {
    return {
        paths: [],
        fallback: 'blocking' // 替换原有的 fallback: true
    };
}

• 版本兼容提示：如果使用的Next.js版本低于12.2，*fallback: 'blocking'*暂不支持，这种场景下可以在服务端反向代理层增加请求识别逻辑：对无浏览器特征的首次请求，服务端内部等待目标路径的静态生成完成后，再将完整页面内容返回给请求方，同样可以解决空壳返回的问题。

内容的提问来源于stack exchange，提问作者Anar Salimkhanov