前端UI组件【免费下载链接】next-shadcn-dashboard-starterFree, open source, AI-friendly admin dashboard template built with Next.js 16, shadcn/ui, Tailwind CSS, and TypeScript. Production-ready tables, forms, auth, and billing. MIT licensed.项目地址https://gitcode.com/gh_mirrors/ne/next-shadcn-dashboard-starter点击查看免费下载在 Next.js 16 shadcn/ui TypeScript 构建的 next-shadcn-dashboard-starter 中服务端组件RSC与客户端组件之间的边界序列化直接决定页面首屏的 HTML 体积与 RSC 请求流量。本文基于.claude/skills/vercel-react-best-practices/rules/server-dedup-props.md这一 Vercel 官方最佳实践规则深入讲解 RSC Props 的按引用去重序列化机制、哪些操作会破坏去重、不同数据类型下的影响差异并结合本仓库的表格页、表单页与平行路由源码给出可直接落地的代码范例。读完本文你将掌握在服务端与客户端边界传递 Props 时避免数据被序列化两次的完整方法能精确估算每个改动对网络载荷的影响。一、规则背景Vercel React 最佳实践中的 Server-Side 性能项本规则属于.claude/skills/vercel-react-best-practices技能包中Server-Side Performance服务端性能类目前缀server-与server-serialization最小化传给客户端的数据量、server-parallel-fetching、server-cache-react等规则同组整体影响等级为HIGH见 SKILL.md 中的分类表。而本篇server-dedup-props规则自身的标注为Impact: LOW增量收益——它不改变业务逻辑只通过避免同一份数据被序列化两次来削减网络载荷tags: server, rsc, serialization, props, client-components。LOW并不意味着可忽略它描述的是单点收益幅度小但在大型管理后台中表格页、列表页、详情页会反复把数组/对象传给客户端组件每处多传一份引用都会叠加到页面体积上属于积少成多的边界优化。二、核心机制RSC→Client 序列化按对象引用去重而非按值React 服务端组件在渲染时会把需要下发给客户端组件的 props 序列化并内嵌到 HTML 响应与后续的 RSC 请求中这与server-serialization规则描述的是同一套机制。关键在于去重判定的基准RSC→client 序列化去重按对象引用reference判定而不是按值value判定。同一引用 只序列化一次新引用 再序列化一次。这意味着即便两份数据内容完全一样只要它们是两次运算产生的不同引用就会被当作两个独立对象分别序列化重复占用网络字节。错误示范重复序列化整个数组// RSC同一份 usernames 被序列化了两次 // 网络载荷2 个数组 × 3 个字符串 6 个字符串 ClientList usernames{usernames} usernamesOrdered{usernames.toSorted()} /这里的usernames.toSorted()返回一个全新的数组引用toSorted()是 ES2023 的非变更式排序方法返回新数组。因此 React 序列化器认为这是两个不同的对象把原数组和排序后的数组各序列化一次。正确示范只传一次客户端再转换// RSC只传一次 usernames ClientList usernames{usernames} /; // Client在客户端完成转换 (use client); const sorted useMemo(() [...usernames].sort(), [usernames]);改造后网络载荷只有 3 个字符串排序动作移到客户端用useMemo完成同时避免了每次渲染都重新排序。注意这里从toSorted()换成[...usernames].sort()只是形式差异两者都会创建新引用关键是把创建新引用的动作移到了客户端一侧。三、嵌套去重行为不同数据类型的影响差异去重是递归生效的——序列化器会深入到对象内部。因此同一个数组重复传两次造成的冗余量取决于元素类型数据类型影响等级重复内容说明string[]、number[]、boolean[]HIGH数组 全部原始类型元素数组本身是引用会被复制数组内的每个原始值也会完整重复object[]LOW仅数组结构本身数组引用被复制但数组内嵌套的每个对象仍按引用去重不会重复用原文档的例子直观说明// string[] —— 所有内容完全重复 usernames{[a,b]} sorted{usernames.toSorted()} // 发送 4 个字符串2 组 a、b // object[] —— 只重复数组外壳 users{[{id:1},{id:2}]} sorted{users.toSorted()} // 发送 2 个数组 2 个唯一对象而非 4 个对象第一条中usernames与sorted各带一组a、b共 4 个字符串。第二条中两个数组引用都指向同一组{id:1}、{id:2}对象toSorted()不深拷贝元素所以对象只序列化一次多出来的只是数组壳的开销。这解释了为什么规则给出嵌套去重行为这一节对object[]而言重复传引用虽然不理想但代价远小于基本类型数组优化时应优先处理string[]、number[]等场景。四、破坏去重的操作清单哪些代码会制造新引用只要在服务端对将要传给客户端的 props 做过下列任一操作就会产生新引用导致重复序列化数组类创建新数组引用.toSorted().filter().map().slice()[...arr]展开运算符对象类创建新对象引用{...obj}对象展开Object.assign()structuredClone()JSON.parse(JSON.stringify())判别方法很简单这些操作的结果与原始对象是两个不同的引用序列化器无法识别它们内容相同。真正能命中去重的是同一个变量原样传两次以及数组中的嵌套对象元素。五、更多正反例对照原文档还给出了两组典型场景// ❌ 错误先传完整数组又传一份 filter 后的新数组 C users{users} active{users.filter(u u.active)} / // ❌ 错误先传整个 product 对象又单独传一个从它解构出的字段 C product{product} productName{product.name} / // ✅ 正确只传一份原始引用 C users{users} / C product{product} / // 过滤、解构等操作放到客户端组件内部做第二组例子尤其值得注意productName{product.name}看似只传了一个字符串非常节省但它和product{product}叠加出现时product.name会作为字符串再序列化一遍对象内的name字段序列化一次独立 props 里的name字符串又序列化一次。字段越多这种整传 拆传的组合冗余越明显。因此规则建议如果客户端组件本来就需要整个对象就只传整个对象拆字段、过滤、解构一律放客户端。六、例外条款何时允许在服务端传派生数据原文档明确给出唯一例外当转换本身开销很大expensive或者客户端根本不需要原始数据时才在服务端传派生数据。典型场景是对数十万条记录做聚合、排序、分页后再传结果此时服务端一次性算好比把海量原始数据传给客户端客户端再重复计算、且需要多传一轮完整数据更划算。规则的矛头对准的是客户端两者都需要、服务端却各传一份的重复序列化而不是禁止一切服务端预处理。这条边界可以帮助你在实际代码中做合理取舍。七、仓库源码印证本项目中的服务端/客户端边界实践下面结合 next-shadcn-dashboard-starter 的实际代码看这套规则在本仓库中的落地点。7.1 数据层与服务端的预筛选是合法例外本仓库的用户与产品表格都遵循服务端 prefetch 客户端消费模式服务端组件src/app/dashboard/users/page.tsx、src/app/dashboard/product/page.tsx通过searchParamsCache解析查询参数后把筛选条件分页、搜索、角色、排序传给src/features/users/components/user-listing.tsx或src/features/products/components/product-listing.tsx在其中调用queryClient.prefetchQuery(...)最后用HydrationBoundary state{dehydrate(queryClient)}把脱水后的查询状态包给客户端表格。真正的过滤、排序、切片发生在src/constants/mock-api-users.ts的getUsers()中先filter、再sort、最后slice分页最终只把当页 10 条数据放进响应total_users等元信息另算。这正是客户端不需要原始数据全集服务端预处理后传少量结果的合法场景——分页数据通过 TanStack Query 缓存而非直接塞进 RSC props没有制造重复序列化。7.2 客户端组件只在必要时接收数据引用客户端表格src/features/users/components/users-table/index.tsx与src/features/products/components/product-tables/index.tsx均以use client开头通过useSuspenseQuery(usersQueryOptions(filters))从客户端缓存中读取data.users/data.products再交给useDataTable与列定义渲染。注意其中的const columnIds columns.map((c) c.id).filter(Boolean)——这段mapfilter在客户端模块顶层执行只作用于本地列定义数组不跨越 RSC 边界不会引发重复序列化。类似地编辑页src/app/dashboard/product/[productId]/page.tsx只把productId一个原始字符串作为 props 传给客户端组件ProductViewPagesrc/features/products/components/product-view-page.tsx组件内部再通过useSuspenseQuery(productByIdOptions(productId))取回完整产品对象用于表单初始化src/features/products/components/product-form.tsx中解构initialData字段作为defaultValues。服务端没有同时传对象 拆出的字段符合规则的✅ 正确示范。7.3 平行路由与纯展示组件最小化跨边界传递仪表盘src/app/dashboard/overview/layout.tsx把sales、pie_stats、bar_stats、area_stats四个平行路由段在服务端组合后渲染。其中sales/page.tsx在服务端await delay(3000)后直接渲染RecentSales组件而src/features/overview/components/recent-sales.tsx的数据是模块级静态常量salesData组件本身不接收任何 propsarea-graph.tsx等图表组件同样把chartData声明在客户端组件模块内部。整条链路上几乎不存在需要跨边界传递的运行时数据也就没有重复序列化的机会——这是把静态数据留在模块内、不经过 RSC 序列化的最优形态可作为新页面开发时参考的基线。八、落地自检清单在实际开发中可对照以下清单审查每个 RSC → Client 的 props 传递是否把同一份数据传了两次检查服务端 JSX 中是否存在原始引用 派生结果同时作为 props 的情况如users与users.filter(...)、product与product.name。是否在服务端调用了破坏引用的操作审查传给客户端组件的 props 前是否有.toSorted()、.filter()、.map()、.slice()、[...arr]、{...obj}、structuredClone()、JSON.parse(JSON.stringify())。若有考虑把操作移到客户端useMemo中。是否按数据类型评估了优先级string[]/number[]/boolean[]重复传引用是 HIGH 影响应优先修复object[]只是数组外壳重复可放在低优先级。是否误伤了合法的服务端预处理分页、聚合、过滤海量数据后再传少量结果属于客户端不需要原始数据的例外应当保留不要为了教条式的全部放客户端而把大量数据搬给浏览器。客户端转换是否用了useMemo移入客户端的派生计算排序、过滤、解构应包裹useMemo避免组件每次渲染都重建派生引用。九、小结server-dedup-props规则的核心是一条内存模型常识RSC 序列化去重认引用不认值。在 next-shadcn-dashboard-starter 这类大量使用服务端组件 客户端交互组件混合架构的模板中谨记同一份数据只传一次转换交给客户端再配合服务端预处理大数据的例外条款就能在零业务改动的前提下持续削减首屏 HTML 与 RSC 请求的网络载荷。更进一步可结合同类规则 server-serialization最小化传参字段与本仓库的 SKILL.md完整 64 条规则索引系统性地审查服务端性能边界。赞分享前端UI组件【免费下载链接】next-shadcn-dashboard-starterFree, open source, AI-friendly admin dashboard template built with Next.js 16, shadcn/ui, Tailwind CSS, and TypeScript. Production-ready tables, forms, auth, and billing. MIT licensed.项目地址https://gitcode.com/gh_mirrors/ne/next-shadcn-dashboard-starter点击查看免费下载相关推荐Phoenix 前端性能指南避免 RSC Props 重复序列化降低网络载荷Phoenix 前端性能指南避免 RSC Props 重复序列化降低网络载荷 本指南围绕 Phoenix 仓库中收录的 Vercel React 最佳实践规可观测性AI 评测LLMOpsAI 应用人工智能避免 RSC Props 重复序列化Mediago 前端性能优化指南避免 RSC Props 重复序列化Mediago 前端性能优化指南 导读 在 React Server ComponentsRSC架构中服务端向客户端音视频桌面应用后端RealWorld 上手指南用 100 种前后端组合看懂一个 Medium 风格的全栈博客应用RealWorld 上手指南用 100 种前后端组合看懂一个 Medium 风格的全栈博客应用 评估一个新框架时官方教程里的 todo 清单往往太浅——真前端UI组件上一篇Rasterio错误处理与调试常见问题排查和解决方案大全下一篇拥抱TypeScript的强大openapi-typescript项目推荐创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考