React 服务端组件与客户端组件
React 服务端组件与客户端组件的职责边界，以及它们和首屏体积、交互能力、数据获取位置之间的关系。
[!info] related notes
React 服务端组件与客户端组件
React Server Components 相关问题，核心不是背名词，而是先分清：哪些逻辑必须在浏览器里发生，哪些内容可以留在服务端组织后再交给客户端。
一句话定义
服务端组件更适合放不依赖浏览器交互的内容组织和数据准备；客户端组件更适合放事件处理、局部状态、effect 和浏览器 API 相关逻辑。
为什么要区分这两类组件
- 不是所有组件都需要在浏览器里运行
- 交互能力和浏览器能力会带来客户端 JavaScript 成本
- 能留在服务端的内容越多，客户端需要接管的部分通常越少
服务端组件更适合做什么
- 读取服务端可直接拿到的数据
- 组织页面结构和内容片段
- 减少不必要的客户端逻辑负担
客户端组件更适合做什么
- 处理点击、输入、滚动等交互
- 使用
useState、useEffect、useRef等客户端能力 - 调用浏览器 API 或第三方前端交互库
应该怎么理解它们的边界
- 不是“服务端组件更高级，客户端组件更落后”
- 而是把真正需要交互的部分留在客户端
- 把只负责内容组织和非浏览器逻辑的部分尽量留在服务端
常见误区
- 以为所有页面都应该尽量全写成服务端组件
- 以为服务端组件等于传统 SSR 页面
- 只看概念，不看团队实际工程复杂度和交互需求
最短记忆方式
内容和数据能留服务端就留服务端，交互和浏览器能力留客户端。
面试要点
来自 react-server-vs-client-components-interview-question 的面试视角整理。
一句话回答
服务端组件更适合做内容组织和服务端可完成的数据准备，不必把这部分逻辑都送到浏览器；客户端组件则负责事件、状态、effect 和浏览器 API 等真正需要在用户设备上执行的交互逻辑。
最稳的回答主线
- 先说边界：是否依赖浏览器交互和客户端能力
- 再说价值：能留在服务端的内容可以减少客户端接管负担
- 再说客户端职责：真正的交互、状态和 effect 仍然要落在客户端组件里
- 最后补一句：这不是纯粹替代关系，而是职责拆分
一个更完整的面试表达
可以这样答：
服务端组件和客户端组件的区别，核心不在“写法不同”，而在“这段逻辑到底需不需要浏览器能力”。
服务端组件更适合做内容组织、服务端可完成的数据准备和不需要交互的 UI 拼装；客户端组件则负责事件、状态、effect、浏览器 API 这些必须在用户设备上执行的事情。
所以它们不是互相替代，而是把 UI 按职责拆到更合适的一侧。
一个加分点
服务端组件的价值不只是“跑在服务端”，而是把那些本来不需要进入浏览器的逻辑和代码留在服务端，从而减少客户端 JavaScript 体积和 hydration 压力。
一个常见判断题
如果一块 UI：
- 不需要点击、输入、订阅、effect
- 可以在服务端把数据准备好
那它更适合优先留在服务端组件侧。
面试里容易加分的一句
服务端组件的价值不只是“把东西放到服务端”，而是减少那些本来不需要交互的逻辑进入客户端 JavaScript 包和 hydration 成本。
常见追问
- 服务端组件和传统 SSR 是什么关系
- 为什么有些组件一旦要处理点击就必须放到客户端侧
- 怎么判断一块 UI 值不值得放到客户端组件里
最短记忆方式
不需要浏览器交互的尽量留服务端，需要交互的留客户端。