👁 40 次阅读

Next.js 16 升级后请求数翻倍，是缓存策略变了还是性能回退？

来源链接：https://github.com/vercel/next.js/issues/85470

现象描述

在 Next.js 16 发布后，有用户报告升级后服务器请求数出现明显增长。issue #85470 的发起人 carlos-dubon 描述了以下现象：从 Next.js 15 升级到 16 后，请求数量「effectively doubled」，导致服务器压力增加、响应延迟变高，并且由于资源消耗增加，云服务成本也随之上升。 另一位用户 jperezrealini 在 2025-10-29 的评论中补充了自己的观察：在 10 月 23 日升级到 Next.js 16 后，请求数明显增加；回滚到 15 后，请求数降回一半。他还注意到「prefetch requests are duplicated」，计划复现后单独开一个 issue。 该 issue 带有 Performance 标签，当前状态为 closed，关闭时间 2026-10-27，关闭原因标记为 completed。issue 共收到 42 条实质讨论评论。

背景原因

官方博客中的说明

用户在讨论中引用了 Next.js 16 官方博客文章中关于路由与导航增强的部分： > Trade-off: You may see more individual prefetch requests, but with much lower total transfer sizes. We believe this is the right trade-off for nearly all applications. If the increased request count causes issues, please let us know. We’re working on additional optimizations to inline data chunks more efficiently 这段话明确承认了 Next.js 16 会带来更多的独立 prefetch 请求，但同时声称总传输体积会显著降低。官方认为这是「对几乎所有应用都正确的权衡」，但也请用户反馈问题。

缓存策略的变更

有用户指出，Next.js 16 在缓存方面发生了重大变化。parkerhutchinson 在 2025-10-28 的评论中质疑发起人是否了解 Next.js 16 中缓存已改为「opt-in」模式，并询问是否阅读了关于 use cache 和 dynamicIO 设置的文档。

排查或量化方法

观察请求量的变化

jperezrealini 提供了直接的量化数据：升级到 Next.js 16 后请求数增加，回滚到 15 后请求数降为一半。这表明问题与版本差异直接相关，而非随机波动。

识别重复的 prefetch 请求

jperezrealini 特别指出「prefetch requests are duplicated」。这说明除了 prefetch 总数增加外，还存在重复请求的情况。

监控服务器成本指标

issue 发起人提供了截图显示部署 v16 后 ops/s 的变化，并在 3:30 PM 后回滚变更。这种通过监控指标对比的方式可以量化升级带来的性能与成本影响。

完整解决方案

版本 16.2 与 16.3 中的修复

根据 issue 讨论中的信息，Next.js 团队在后续版本中对该问题进行了处理：

• 在版本 16.2 中，prefetchInlining 功能落地，以 experimental.prefetchInlining 配置项作为 opt-in 方式提供
• 在版本 16.3 中，prefetchInlining 成为默认行为，但仍可通过同一配置项选择退出

icyJoseph 在 2026-10-27 的评论中总结了这一进展： > – In version 16.2 we shipped prefetchInlining to address this issue, with the experimental.prefetchInlining config as an opt-in > – In version 16.3, prefetchInlining became the default behavior, with the possibly to still opt-out, via the same config option 相关文档链接：https://nextjs.org/docs/app/api-reference/config/next-config-js/p

配置方式

在 16.2 版本中，如果需要启用该功能，可以通过 next.config.js 中的实验配置开启：

// next.config.js
module.exports = {
  experimental: {
    prefetchInlining: true
  }
}

在 16.3 版本中，该功能默认开启，如果希望保持 16.0/16.1 的行为，可以通过相同配置项关闭：

// next.config.js
module.exports = {
  experimental: {
    prefetchInlining: false
  }
}

参数或对比表格

版本	prefetchInlining 状态	请求行为	说明
Next.js 15	不适用	请求数较少	升级前的基线行为
Next.js 16.0/16.1	未提供	请求数增加，prefetch 请求重复	问题出现的版本区间
Next.js 16.2	实验性，默认关闭	可通过 experimental.prefetchInlining 开启	需要手动配置
Next.js 16.3	默认开启	请求数应下降	可通过同一配置项选择退出

常见错误排查

1. 升级后请求数翻倍，是否应立即回滚？

先确认使用的版本。如果是 16.0 或 16.1，可以考虑升级到 16.2 或 16.3，这两个版本中引入了 prefetchInlining 优化。如果无法升级，回滚到 15.x 是可行的临时方案，但要注意后续升级时同样会遇到该问题。

2. 是否了解 Next.js 16 缓存策略的变化？

Next.js 16 中缓存改为 opt-in 模式，涉及 use cache 和 dynamicIO 设置。如果未调整缓存策略，prefetch 行为可能与 15 有明显差异。建议阅读官方文档中关于缓存与预取（prefetching）的说明。

3. 是否区分了 PPR 路由的 prefetch 行为？

jperezrealini 在讨论中指出，文档对 PPR（Partial Prerendering）路由下的 prefetch 行为说明不够清晰。如果应用大量使用 PPR 路由，prefetch 请求的模式可能与预期不同。文档链接：https://nextjs.org/docs/app/guides/prefetching#partial-prerendering-ppr

4. 是否检查了共享路由壳（route shell）的 prefetch 去重？

讨论中提到，期望是「如果多个链接共享同一路由壳，Next.js 应该只 prefetch 一次并缓存」。如果应用有大量共享布局的路由，prefetch 请求可能因缺少去重而增加。16.2/16.3 中的 prefetchInlining 针对此问题做了优化。

5. 是否验证了关闭 Cache Components 后的行为？

jperezrealini 在 2026-03-26 的评论中提到，尝试禁用 Cache Components 后，动态路由仍被 prefetch，这与文档描述不一致。如果遇到类似情况，需要在 issue 中反馈或等待后续修复。

实践建议

• 升级到 Next.js 16 时，先在小流量环境中验证请求量变化，观察服务器负载与响应延迟指标
• 如果请求量增长明显，优先升级到 16.2 或 16.3 版本，利用 prefetchInlining 优化
• 在 16.2 版本中，可以通过 experimental.prefetchInlining: true 提前验证优化效果
• 关注官方文档中关于 prefetching 与 PPR 的更新，特别是共享路由壳的 prefetch 去重行为
• 如果应用对请求数敏感（如自托管且按请求量计费），在升级前评估请求量变化对成本的影响
• 在部署监控中对比升级前后的 ops/s、请求数、延迟等指标，量化实际影响

FAQ

Q: Next.js 16 请求数翻倍是 bug 还是设计变更？

A: 根据官方博客的说明，这是设计变更的一部分。Next.js 16 改为「更多独立 prefetch 请求，但总传输体积更低」的策略。官方承认了请求数增加，并表示正在开发额外的优化来更高效地内联数据块。issue #85470 关闭时标记为 completed，后续版本中通过 prefetchInlining 功能进行了针对性优化。

Q: prefetchInlining 是官方确认的修复方案吗？

A: 据 issue 讨论，icyJoseph 在 2026-10-27 的评论中确认，16.2 版本中 prefetchInlining 作为实验性功能落地，16.3 中成为默认行为。但 issue 状态为 closed 且关闭原因为 completed，同时讨论了具体的功能与配置项，社区用户 phil-sola 在 2026-06-10 还询问了该功能与共享布局去重优化的关系，说明社区在持续关注此功能的效果。

Q: 升级到 16.3 后请求数会完全恢复到 15 的水平吗？

A: 据 issue 讨论，16.3 中 prefetchInlining 成为默认行为，但该优化主要针对 prefetch 请求的合并与内联。由于 Next.js 16 的缓存策略整体发生了变化，请求模式与 15 仍可能存在差异。具体效果需要在实际部署中对比监控数据验证。

Q: 如果对请求数非常敏感，是否应该继续使用 Next.js 15？

A: 这是可行的临时方案，issue 中有用户在 16.0/16.1 版本遇到问题后回滚到 15，请求数恢复正常。但需要注意，长期停留在旧版本会错过安全更新与性能改进。建议在 16.2+ 版本中开启或使用 prefetchInlining 验证效果后再决定迁移计划。

Q: 如何判断 prefetchInlining 是否解决了当前应用的请求数问题？

A: 在升级到 16.2 或 16.3 后，对比升级前后相同时间段内的服务器请求数、ops/s、平均响应延迟等指标。参考 issue 发起人提供的监控方式，在部署后持续观察 24-48 小时，与 15.x 版本的基线数据对比，判断请求量的变化幅度是否符合预期。