迁移到RSC时常见坑有哪些

说起来你可能不信，我上个月刚把一个中型后台管理系统从传统React迁移到RSC架构，结果头三天就踩了五六个坑，差点没把键盘砸了。今天就跟你们唠唠那些迁移过程中最让人抓狂的常见陷阱，希望能帮正打算动手的你少走点弯路。

第一大坑：幻想“全服务端”能搞定一切

我一开始的想法特别天真：既然RSC这么香，那我干脆把所有组件都丢到服务端去算了，什么加载、渲染全交给服务器，多省事。结果页面跑起来，按钮点不动，弹出的弹窗全白屏，连个菜单下拉都展开不了。后来才反应过来——服务端组件根本没有事件处理能力。你写个onClick，它压根不认识，就像跟空气对话。我的血泪教训：服务端组件管数据获取，客户端组件管交互，千万别混为一谈。

数据流里藏着的“定时炸弹”

这是我犯过最蠢的一次错误。我在服务端组件里从数据库取了个用户信息，里面包含一个Date对象，然后直接把它当props传给了一个客户端组件。结果呢？页面直接报了个“无法序列化”的错误。RSC的数据流是通过JSON传输的，Date、函数、Map、Set这些统统罢工。你得先手动转成字符串或时间戳，到客户端再解析。别问我怎么知道的，我也被折腾了一整天。

第三方库的“背叛”

迁移的时候我天真地以为原来用的那些npm包都能直接拿来用。结果一升级，日历组件、富文本编辑器、图表库全炸了，因为它们内部大量调用了 window、document 这些浏览器API。解决方法其实很简单：在这些组件文件顶部加上 'use client' 声明，或者用 dynamic 带 ssr: false 的方式动态加载。但最烦的是有些包根本没标明自己是不是纯客户端，得一个个排查，那感觉像是在拆盲盒。

被忽略的缓存策略

刚开始我压根没管缓存，结果服务端组件的请求每次页面刷新都重新跑一遍。后来才意识到，RSC和传统SSR不一样，它的数据缓存策略你要明确告诉框架。比如那些不变的文章内容，用force-cache；用户登录状态这种动态数据，用no-store。忘了配置？那你可能要对着一张1秒才加载出来的仪表盘发呆。

目录结构折腾到崩溃

还有个小细节——组件文件命名。我一开始把所有文件都丢在同一个文件夹里，结果Next.js的App Router把我整晕了。记得一定要把服务端组件和客户端组件物理上分开，比如用components/server/和components/client/这样的目录结构，否则后面找文件简直是噩梦。而且如果你不小心在一个服务端组件里引用了客户端组件，里面再嵌套一个服务端组件，那就会触发“服务端组件导入客户端组件再导入服务端组件”的诡异错误，React给你报一个“不受支持的组件类型”异常。

总结一下（但这不是总结）

其实迁移到RSC就像第一次学骑自行车，摔两下是正常的。最关键的还是先画清楚组件边界：哪些是拿数据的，哪些是人机交互的。别一上来就想着全服务端，也别幻想客户端能直接接过来用。先把那些陷阱一个个趟过去，你会发现流式渲染、代码分割带来的性能提升是真的香。最后送你一句话：先让大脑里的架构跑通，再让代码在服务器上跑通——别问我怎么知道的，问就是。