Next.js 16(2025):Cache Components 与架构边界重塑
Created on
Next.js 16 重点落在“可控缓存与架构边界”:Cache Components 把 PPR 与 use cache 结合,缓存更显式;proxy.ts 取代 middleware.ts,边界更清晰;Devtools MCP 强化调试与协作。
适合谁
- 对缓存可控性有强需求的内容或平台型应用
- 需要明确网络边界与代理逻辑的企业项目
- 希望进一步提升构建与调试效率的团队
使用方式(快速上手)
- 版本发布:2025 年(Next.js Conf 前后)
- 核心变化:Cache Components(PPR +
use cache)、proxy.ts取代middleware.ts、Devtools MCP、缓存 API 增强 - 升级注意:async params、
next/image默认行为变化、缓存策略更显式
来源:https://nextjs.org/blog/next-16
核心能力与选择策略
- Cache Components:显式控制缓存与渲染边界,避免“隐式缓存”带来的不确定
proxy.ts:将请求代理明确收口,区分应用逻辑与网络边界(middleware.ts逐步弃用)- 缓存 API:
updateTag()与新版revalidateTag()强化缓存一致性控制 - Devtools MCP:更强的调试可视化与上下文协作能力
- 选择建议:先把缓存边界收敛清楚,再改
proxy.ts
案例 1:新闻首页“静态外壳 + 缓存卡片”加速
新闻站首页既要快速打开又要避免全量动态渲染,开启 Cache Components,并在数据组件上 use cache 控制缓存,提升 TTFB 与导航体验。
关键代码:
// next.config.ts
const nextConfig = {
cacheComponents: true,
};
export default nextConfig;
// component
("use cache");
export async function TopStories() {
return fetchTopStories();
}
来源:https://nextjs.org/blog/next-16
案例 2:API 代理统一收口到 proxy.ts
企业将多个后端服务收口到代理层,用 proxy.ts 明确网络边界与鉴权逻辑,替代旧 middleware.ts。
关键代码:
// proxy.ts
export default function proxy(req: Request) {
return fetch("https://api.internal" + new URL(req.url).pathname, req);
}
来源:https://nextjs.org/blog/next-16
升级对比(14 -> 15 -> 16)
- 渲染与缓存:14 引入 PPR 预览;16 通过 Cache Components +
use cache明确缓存策略 - 数据写入:14 起 Server Actions 稳定,15/16 持续完善 DX
- 构建与工具:15.5
next build --turbopackbeta;16 强化 Turbopack 与 Devtools MCP - 边缘与路由:15.5 Node.js Middleware 稳定;16 用
proxy.ts替代middleware.ts - 迁移注意:16 async params 与
next/image默认变更,需审视路由与图片策略 - 升级建议:仍在 14 先升 15;对缓存可控与架构升级需求高可评估 16
迁移检查清单(16 相关)
middleware.ts是否需要改为proxy.ts- 是否依赖 sync
params/searchParams(需要改为 async) next/image是否使用自定义quality或本地 query string
进一步阅读
- 官方发布说明:
https://nextjs.org/blog/next-16 - Cache Components 配置:
https://nextjs.org/docs/app/api-reference/config/next-config-js/cacheComponents proxy.ts说明:https://nextjs.org/docs/app/getting-started/proxy
小结
Next.js 16 更像一次“架构层升级”:缓存更明确、边界更清晰、调试更系统。适合已经规模化、需要可预测行为的团队。