Next.js跳过构建时静态生成仅运行时调用getStaticProps生成页面的方案咨询

现有方案的明显缺点 #

• 首次访问冷启动性能差：所有页面都要等到用户首次访问时才会执行getStaticProps拉取数据生成静态资源，首访用户会遇到明显的延迟甚至超时，流量较低的页面会反复触发冷启动，用户体验极差。
• 缺少构建阶段校验：构建时直接跳过了fetchData逻辑，即便数据请求逻辑存在bug、参数不兼容、数据库字段变更等问题，构建阶段完全无法发现，只会在线上运行时抛出错误，排查成本极高。
• 空数据兼容成本高：构建阶段返回的data为null，所有页面组件必须做完善的空值兼容，否则预渲染阶段会直接报错，一旦漏写兼容逻辑就会出现构建失败或者线上白屏问题。
• 缓存灵活性不足：全局设置5分钟的revalidate规则无法适配不同客户、不同页面的更新频率需求，客户侧数据更新后最长要等5分钟才能刷到最新内容，不满足有实时性要求的业务场景。
• 动态路由适配困难：如果应用存在大量动态路由（如/[skuId]、/user/[uid]等），无法提前批量生成静态页，只能等用户逐个访问触发生成，冷启动问题会被无限放大。

更合适的适配方案 #

你可以根据业务场景选择以下方案：

• 改用SSR方案：把getStaticProps替换为getServerSideProps，每次请求都会实时拉取当前客户数据库的数据返回，不需要提前预生成静态页，完全适配多客户独立部署场景，也没有冷启动问题，数据永远是最新的。如果对响应速度有要求，可以在服务端加一层Redis缓存接口请求结果，性能基本和静态页持平。
• 用App Router动态渲染模式：如果是Next.js 13+版本，优先用App Router，给页面加上export const dynamic = 'force-dynamic'配置，构建阶段不会做任何预渲染，运行时根据请求动态生成内容，同时支持自定义单页面的缓存规则，灵活性远高于Pages Router的ISR方案。
• 部署后主动预热：如果一定要保留ISR方案，可以在next start启动完成后运行自定义脚本，遍历当前客户的全量路由主动发起请求，提前把所有静态页生成完成，避免用户侧遇到冷启动问题。
• 客户侧单独构建：如果私有化部署流程允许，可以直接在客户的部署环境中执行next build，构建阶段就能直接拿到客户侧的数据库数据生成全量静态页，性能最优，也不存在上述问题，仅需要调整部署流程支持客户侧单独构建即可。

内容的提问来源于stack exchange，提问作者Bennett Dams