我喜欢你>_<

一句话摘要#

这次整理让我更清楚地理解了 Next.js 的核心权衡：SSR 负责“快看到”，Hydration 负责“能交互”，而响应式冲突要优先用 CSS 方案规避。

目录#

• 一句话摘要
• 目录
• 背景与问题
  • 本章小结
• 核心概念
  • 本章小结
• Hydration 机制
  • 本章小结
• SSR 下的响应式实践
  • 本章小结
• 总结

背景与问题#

在 Next.js（App Router）里，我最初的问题是：页面明明 SSR 首屏很快，但一涉及交互或响应式判断就容易出现 Hydration 警告，甚至内容闪动。

核心难点不是“会不会写组件”，而是“服务端和客户端的首次输出是否一致”。

核心概念#

在 Next.js 里，组件分为 Server Component 和 Client Component：

• Server Component（默认）：
  • 运行在服务端。
  • 不可使用 React Hooks、事件监听、浏览器 API。
  • 优点是减少客户端 bundle，首屏更轻。
• Client Component（"use client";）：
  • 需要 Hydration 后才具备完整交互。
  • 可使用状态、事件和浏览器能力。
  • 适合表单、按钮、动态交互区域。

最佳实践是“叶子节点 client 化”：页面尽量保持 server，只有必须交互的局部切到 client。

Hydration 机制#

Hydration 可以理解为“把交互能力重新附着到已渲染的 HTML 上”。

过程是：服务端先输出静态内容，客户端下载 JS 后再绑定事件和状态。
所以 SSR 的优势是内容先到，挑战是交互稍后到。

这也是为什么 SSR 通常改善 FCP，但仍可能出现 TTI 体感延迟。Next.js 的 streaming 和选择性 hydration 就是在缓解这个落差。

SSR 下的响应式实践#

常见 Hydration mismatch 报错本质是：服务端首次 HTML 与客户端首次渲染不一致。

典型误区是直接在渲染阶段读取 window.innerWidth 并分支输出不同组件。
在 SSR 场景下更稳妥的做法是优先用 CSS 媒体查询（或 Tailwind 断点类）处理展示差异，让初始 HTML 保持一致。

1
return (
2
  <>
3
    <div className="block md:hidden">
4
      <MobileNav />
5
    </div>
6
    <div className="hidden md:block">
7
      <DesktopNav />
8
    </div>
9
  </>
10
);

总结#

这次整理后，我对 SSR 的判断更清晰了：
先保证首屏输出一致，再局部增强交互；先用 CSS 解决响应式，再用 JS 处理必须的行为逻辑。这样才能把 Next.js 的性能优势稳定地发挥出来。