Next.js 13 Server Component 的边界笔记

Next.js 13 刚出来时，大家最容易被 Server Component 这个概念吸引，因为它看起来像是在重新分配前后端渲染责任。但真开始上手以后，我觉得最难的不是语法本身，而是组件边界要重新思考。

以前很多组件默认都跑在客户端，取数、状态、展示混在一起还勉强能过。Server Component 出来后，逻辑就必须重新分层：纯展示和数据读取能不能留在服务端，交互和浏览器依赖是不是必须下沉到客户端，这个判断一旦不清楚，项目结构很快就会乱。

我比较认可的做法，是把它当成一次“重新收边界”的机会。能在服务端完成的读取和拼装，尽量别带到客户端；必须依赖浏览器事件和本地状态的部分，再明确标成 client component。这样数据链路和交互链路会清楚很多。

真正要警惕的，是把 Server Component 当成“新的全能组件”来用。只要边界没想清楚，后面同样会出现难以解释的依赖问题。

Next.js 13 的价值，不只是新能力，而是逼我们重新回答一个老问题：哪些逻辑应该待在离数据最近的地方，哪些逻辑应该留在用户交互那一侧。

前端里的很多“体验问题”本质上都是边界问题

围绕「Next.js 13 Server Component 的边界笔记」这类前端话题，最常见的误区是先去追求框架技巧，再去补组件边界和状态来源。可一旦项目规模上来，真正让代码变脆的，往往不是少用了某个 API，而是数据获取、缓存失效、交互 pending、组件拆分和构建产物之间没有形成清楚约定。框架升级只会把这些隐性问题更快地暴露出来。

我会先做的落地检查

• 先明确状态由谁拥有、什么时候重置、什么时候延迟更新，避免组件自己偷偷维护第二份真相。
• 把路由、缓存、构建配置和产物入口拆成可独立验证的边界，不要把所有约定都留在默认行为里。
• 一旦某个点已经影响到交互一致性、渲染成本或团队协作效率，就应该把它写成约束，而不是继续靠经验口口相传。