OpenMontage 开发规范解读React/Next.js 服务端嵌套数据拉取的并行化技巧【免费下载链接】OpenMontageWorlds first open-source, agentic video production system. 12 production pipelines, 100 tools, 700 agent skill and production-knowledge files. Turn your AI coding assistant into a full video production studio.项目地址: https://gitcode.com/GitHub_Trending/op/OpenMontage导读本篇文章围绕仓库内置技能包.claude/skills/vercel-react-best-practices/rules/server-parallel-nested-fetching.md所定义的规则展开讲解在 React Server ComponentsRSC与 Next.js 场景下如何对列表 嵌套关联数据的拉取方式进行并行化改造彻底消除服务端串行瀑布waterfall效应。读完本文你将掌握Promise.all内逐项链式拉取per-item promise chaining的核心写法、它与普通并行拉取的区别、适用边界与配套规则能够在基于该仓库 remotion-composer 等前端子项目中编写高性能的 React/Next.js 数据层代码。一、规则定位为什么它属于 Server-Side PerformanceHIGH在技能包分类体系见 rules/_sections.md中所有规则按消除瀑布async-、包体积bundle-、服务端性能server-、客户端数据拉取client-、重渲染rerender-、渲染性能rendering-、JavaScript 微优化js-、高级模式advanced-八大类划分。server-parallel-nested-fetching属于Server-Side Performanceserver-类impact 等级为HIGH高。它在 SKILL.md 的 Quick Reference 中被明确描述为server-parallel-nested-fetching- Chain nested fetches per item in Promise.all即在Promise.all内部把每个条目的嵌套拉取链进该条目自己的 Promise 里。它与其姊妹规则server-parallel-fetching用组件组合实现并行拉取共同解决一类问题消除服务端瀑布eliminates server-side waterfalls即该规则 frontmatter 中的impactDescription。要理解这条规则的价值需要先搞清楚一个前置概念——服务端瀑布。什么是服务端瀑布在 React Server Components 中组件树是顺序执行的父组件await完成前子组件不会开始渲染更不会发起自己的数据请求。如果我们在同一层级里连续写多个await就会形成串行请求链请求 A 完成 → 请求 B 才开始 → 请求 B 完成 → 请求 C 才开始每一次顺序等待都叠加一次完整的网络往返延迟round-trip latency。在_sections.md中这一现象被直接点名Waterfalls are the #1 performance killer. Each sequential await adds full network latency. Eliminating them yields the largest gains.瀑布是头号性能杀手每个顺序 await 都会叠加完整的网络延迟消除它们能带来最大的收益。server-parallel-nested-fetching处理的正是瀑布中最难发现的一类不是同一层级的多请求串行而是先拉列表、再逐条拉关联数据造成的两段式瀑布。二、错误示范慢条目阻塞所有嵌套拉取规则原文给出了最典型的错误写法const chats await Promise.all( chatIds.map(id getChat(id)) ) const chatAuthors await Promise.all( chats.map(chat getUser(chat.author)) )这段代码表面上用了两次Promise.all看起来已经是并行了但实际上存在严重的时序缺陷第一段100 个getChat(id)并行发出必须等到全部 100 个getChat全部完成第二个Promise.all才会开始构造getUser(chat.author)请求只要有一个getChat(id)极慢慢查询、超时重试、热点数据命中缓存失败等其余 99 个作者请求即使数据已经就绪也只能干等。这正是规则原文强调的场景If onegetChat(id)out of 100 is extremely slow, the authors of the other 99 chats cant start loading even though their data is ready.瓶颈时间 最慢的那个getChat的耗时 各getUser的耗时而不是平均耗时。直观理解两阶段提交 vs 流水线可以把这两种写法类比成两种工作方式错误写法两阶段提交全体成员先集合等最后一个到达再统一出发。只要有一个人迟到全队都在等。正确写法流水线谁先到谁先走第 1 个聊天数据的作者请求在第 1 个getChat完成的那一刻立即发出不需要等第 100 个。三、正确示范逐项链式拉取per-item chaining规则给出的修正写法如下const chatAuthors await Promise.all( chatIds.map(id getChat(id).then(chat getUser(chat.author))) )关键变化只有一个把依赖关系写进同一个 Promise 链里。对每个idgetChat(id)完成后立刻在其.then回调中发起getUser(chat.author)Promise.all只负责收集 100 条独立的 Promise 链每条链互不等待慢的getChat只影响它自己这条链上的getUser其他 99 条链照常推进。于是整体耗时从最慢getChatgetUser串行段变成各链并行交错网络空闲时间被最大化压缩。图解时序时间轴 → 错误写法: getChat (100个并行) |________| ← 全部完成 getUser (100个并行) |________| 正确写法: 链1: getChat#1 → getUser#A |__|__| 链2: getChat#2 → getUser#B |__|__| 链3: getChat#3 → getUser#C |___|___| ... 链100: |_______|____| 每条链独立推进没有全局屏障四、扩展写法更多可落地的变体原规则只给出了.then链式写法实际工程中还有几种等价或更优的实现建议按场景选用。变体 1async/await风格可读性更好const chatAuthors await Promise.all( chatIds.map(async id { const chat await getChat(id) return getUser(chat.author) }) )map的回调被标记为async返回的本身就是 Promise效果与.then链完全一致但嵌套层级更深时更易读。变体 2提前构造 Promise最后统一Promise.all这是 async-dependencies.md 中推荐的无额外依赖替代方案核心思想是创建 Promise 的动作会立即启动请求const chatsPromise Promise.all(chatIds.map(id getChat(id))) const authorsPromise chatsPromise.then(chats Promise.all(chats.map(chat getUser(chat.author))) )注意这种写法仍然存在全局屏障authorsPromise依赖全部chats完成适用于后续确实需要完整列表的场景若只需要逐条关联数据前两种逐项链式写法更优。变体 3多层嵌套关联规则强调chain dependent fetches within each items promise把依赖拉取链进每条目的 promise该原则可自然推广到多层const results await Promise.all( chatIds.map(async id { const chat await getChat(id) const author await getUser(chat.author) const org await getOrganization(author.orgId) // 第二层依赖 return { chat, author, org } }) )每条链内部的串行依赖不可避免但链与链之间始终并行这正是该规则的精髓。五、规则族与相邻规则的组合使用这条规则不是孤立存在的它与技能包中多个规则构成完整的瀑布消除体系规则文件解决的问题与本文规则的关系async-parallel.md无依赖的独立操作直接用Promise.all并行本文规则是它在有依赖场景下的延伸async-dependencies.md部分依赖的操作用better-all或提前构造 Promise 最大化并行提供提前创建 Promise的等价替代写法async-defer-await.md把await推迟到真正使用的分支避免阻塞无关代码路径从是否需要等待维度消除不必要阻塞server-parallel-fetching.md在 RSC 组件树中通过组件组合实现同级并行拉取同属服务端瀑布消除侧重组件结构维度其中 async-parallel.md 给出了最基础的对照// 错误3 次串行往返 const user await fetchUser() const posts await fetchPosts() const comments await fetchComments() // 正确1 次往返 const [user, posts, comments] await Promise.all([ fetchUser(), fetchPosts(), fetchComments() ])本文的规则可以理解为当并行对象内部存在列表 → 列表成员关联数据的依赖时把依赖链收拢到条目内部从而把上面这种一次往返的理想效果推广到嵌套场景。整个技能包共收录 65 条规则8 大类完整索引见 SKILL.md长文版汇总见 AGENTS.md其中第 3.7 节 Parallel Nested Data Fetching 即为本文规则的扩展版本。六、工程实践错误处理与注意事项在实际编码中还需注意以下几点属于规则之外的常识性补充帮助正确落地1. 失败语义Promise.all的快速失败Promise.all采用fail-fast快速失败语义任意一条链 reject整体立即 reject。若列表拉取中某条getChat失败会连带中断整体可考虑改用Promise.allSettled并在逐项链内降级const chatAuthors await Promise.allSettled( chatIds.map(async id { const chat await getChat(id) return getUser(chat.author) }) ) // 对 fulfilled / rejected 分别处理避免单点拖垮整体2. 逐项链式 ≠ 无限并行当chatIds数量极大如数千条时Promise.all会一次性发起大量并发请求可能打满连接池或触发上游限流。此时应引入并发上限如分批Promise.all、p-limit等逐项链式优化的收益依然成立只是需要控制在合理并发窗口内。3. 与缓存配合嵌套拉取产生的是高基数、低命中率的关联请求同一 author 可能被多条聊天重复请求。可以结合server-cache-reactReact.cache() 做请求级去重与server-cache-lru跨请求 LRU 缓存两条相邻规则在并行化的同时进一步削减重复网络开销。4. 在 OpenMontage 前端子项目中的适用场景本仓库的 remotion-composer 是 React/TypeScript 编写的视频渲染前端使用 Remotion 框架源码位于 src其中 TitledVideo.tsx 等组件会按 props 渲染标题、媒体与场景数据。当这类组件需要先取场景列表、再按场景取对应素材或字幕时同样适用本文规则把场景 → 素材/字幕的依赖链收进每条目的 Promise 内避免某个素材请求缓慢拖慢整页渲染管线。七、总结一条可以机械执行的检查清单将本文规则沉淀为代码评审与自动重构时的检查清单发现两段式Promise.all若代码中先await Promise.all(map(fetchList))、再基于结果await Promise.all(map(fetchDetail))即命中本规则判定依赖方向若第二个请求只依赖该条目自身的数据如chat.author而非整个列表的聚合结果就可以安全地改为逐项链式改写ids.map(id fetchList(id).then(item fetchDetail(item.ref)))或等价 async 写法验证收益最慢条目的耗时不再阻塞其他条目的第二阶段请求整体延迟从两段累加收敛为各链并行的近似最长链结合相邻规则对无依赖操作用 async-parallel.md对部分依赖操作参考 async-dependencies.md对 RSC 组件树场景参考 server-parallel-fetching.md。核心心法一句话Promise.all并行的是链条而不是阶段——把嵌套依赖挂到每条独立的链上慢的条目只慢自己快的条目永远不等别人。【免费下载链接】OpenMontageWorlds first open-source, agentic video production system. 12 production pipelines, 100 tools, 700 agent skill and production-knowledge files. Turn your AI coding assistant into a full video production studio.项目地址: https://gitcode.com/GitHub_Trending/op/OpenMontage创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
OpenMontage 开发规范解读React/Next.js 服务端嵌套数据拉取的并行化技巧【免费下载链接】OpenMontageWorlds first open-source, agentic video production system. 12 production pipelines, 100 tools, 700 agent skill and production-knowledge files. Turn your AI coding assistant into a full video production studio.项目地址: https://gitcode.com/GitHub_Trending/op/OpenMontage导读本篇文章围绕仓库内置技能包.claude/skills/vercel-react-best-practices/rules/server-parallel-nested-fetching.md所定义的规则展开讲解在 React Server ComponentsRSC与 Next.js 场景下如何对列表 嵌套关联数据的拉取方式进行并行化改造彻底消除服务端串行瀑布waterfall效应。读完本文你将掌握Promise.all内逐项链式拉取per-item promise chaining的核心写法、它与普通并行拉取的区别、适用边界与配套规则能够在基于该仓库 remotion-composer 等前端子项目中编写高性能的 React/Next.js 数据层代码。一、规则定位为什么它属于 Server-Side PerformanceHIGH在技能包分类体系见 rules/_sections.md中所有规则按消除瀑布async-、包体积bundle-、服务端性能server-、客户端数据拉取client-、重渲染rerender-、渲染性能rendering-、JavaScript 微优化js-、高级模式advanced-八大类划分。server-parallel-nested-fetching属于Server-Side Performanceserver-类impact 等级为HIGH高。它在 SKILL.md 的 Quick Reference 中被明确描述为server-parallel-nested-fetching- Chain nested fetches per item in Promise.all即在Promise.all内部把每个条目的嵌套拉取链进该条目自己的 Promise 里。它与其姊妹规则server-parallel-fetching用组件组合实现并行拉取共同解决一类问题消除服务端瀑布eliminates server-side waterfalls即该规则 frontmatter 中的impactDescription。要理解这条规则的价值需要先搞清楚一个前置概念——服务端瀑布。什么是服务端瀑布在 React Server Components 中组件树是顺序执行的父组件await完成前子组件不会开始渲染更不会发起自己的数据请求。如果我们在同一层级里连续写多个await就会形成串行请求链请求 A 完成 → 请求 B 才开始 → 请求 B 完成 → 请求 C 才开始每一次顺序等待都叠加一次完整的网络往返延迟round-trip latency。在_sections.md中这一现象被直接点名Waterfalls are the #1 performance killer. Each sequential await adds full network latency. Eliminating them yields the largest gains.瀑布是头号性能杀手每个顺序 await 都会叠加完整的网络延迟消除它们能带来最大的收益。server-parallel-nested-fetching处理的正是瀑布中最难发现的一类不是同一层级的多请求串行而是先拉列表、再逐条拉关联数据造成的两段式瀑布。二、错误示范慢条目阻塞所有嵌套拉取规则原文给出了最典型的错误写法const chats await Promise.all( chatIds.map(id getChat(id)) ) const chatAuthors await Promise.all( chats.map(chat getUser(chat.author)) )这段代码表面上用了两次Promise.all看起来已经是并行了但实际上存在严重的时序缺陷第一段100 个getChat(id)并行发出必须等到全部 100 个getChat全部完成第二个Promise.all才会开始构造getUser(chat.author)请求只要有一个getChat(id)极慢慢查询、超时重试、热点数据命中缓存失败等其余 99 个作者请求即使数据已经就绪也只能干等。这正是规则原文强调的场景If onegetChat(id)out of 100 is extremely slow, the authors of the other 99 chats cant start loading even though their data is ready.瓶颈时间 最慢的那个getChat的耗时 各getUser的耗时而不是平均耗时。直观理解两阶段提交 vs 流水线可以把这两种写法类比成两种工作方式错误写法两阶段提交全体成员先集合等最后一个到达再统一出发。只要有一个人迟到全队都在等。正确写法流水线谁先到谁先走第 1 个聊天数据的作者请求在第 1 个getChat完成的那一刻立即发出不需要等第 100 个。三、正确示范逐项链式拉取per-item chaining规则给出的修正写法如下const chatAuthors await Promise.all( chatIds.map(id getChat(id).then(chat getUser(chat.author))) )关键变化只有一个把依赖关系写进同一个 Promise 链里。对每个idgetChat(id)完成后立刻在其.then回调中发起getUser(chat.author)Promise.all只负责收集 100 条独立的 Promise 链每条链互不等待慢的getChat只影响它自己这条链上的getUser其他 99 条链照常推进。于是整体耗时从最慢getChatgetUser串行段变成各链并行交错网络空闲时间被最大化压缩。图解时序时间轴 → 错误写法: getChat (100个并行) |________| ← 全部完成 getUser (100个并行) |________| 正确写法: 链1: getChat#1 → getUser#A |__|__| 链2: getChat#2 → getUser#B |__|__| 链3: getChat#3 → getUser#C |___|___| ... 链100: |_______|____| 每条链独立推进没有全局屏障四、扩展写法更多可落地的变体原规则只给出了.then链式写法实际工程中还有几种等价或更优的实现建议按场景选用。变体 1async/await风格可读性更好const chatAuthors await Promise.all( chatIds.map(async id { const chat await getChat(id) return getUser(chat.author) }) )map的回调被标记为async返回的本身就是 Promise效果与.then链完全一致但嵌套层级更深时更易读。变体 2提前构造 Promise最后统一Promise.all这是 async-dependencies.md 中推荐的无额外依赖替代方案核心思想是创建 Promise 的动作会立即启动请求const chatsPromise Promise.all(chatIds.map(id getChat(id))) const authorsPromise chatsPromise.then(chats Promise.all(chats.map(chat getUser(chat.author))) )注意这种写法仍然存在全局屏障authorsPromise依赖全部chats完成适用于后续确实需要完整列表的场景若只需要逐条关联数据前两种逐项链式写法更优。变体 3多层嵌套关联规则强调chain dependent fetches within each items promise把依赖拉取链进每条目的 promise该原则可自然推广到多层const results await Promise.all( chatIds.map(async id { const chat await getChat(id) const author await getUser(chat.author) const org await getOrganization(author.orgId) // 第二层依赖 return { chat, author, org } }) )每条链内部的串行依赖不可避免但链与链之间始终并行这正是该规则的精髓。五、规则族与相邻规则的组合使用这条规则不是孤立存在的它与技能包中多个规则构成完整的瀑布消除体系规则文件解决的问题与本文规则的关系async-parallel.md无依赖的独立操作直接用Promise.all并行本文规则是它在有依赖场景下的延伸async-dependencies.md部分依赖的操作用better-all或提前构造 Promise 最大化并行提供提前创建 Promise的等价替代写法async-defer-await.md把await推迟到真正使用的分支避免阻塞无关代码路径从是否需要等待维度消除不必要阻塞server-parallel-fetching.md在 RSC 组件树中通过组件组合实现同级并行拉取同属服务端瀑布消除侧重组件结构维度其中 async-parallel.md 给出了最基础的对照// 错误3 次串行往返 const user await fetchUser() const posts await fetchPosts() const comments await fetchComments() // 正确1 次往返 const [user, posts, comments] await Promise.all([ fetchUser(), fetchPosts(), fetchComments() ])本文的规则可以理解为当并行对象内部存在列表 → 列表成员关联数据的依赖时把依赖链收拢到条目内部从而把上面这种一次往返的理想效果推广到嵌套场景。整个技能包共收录 65 条规则8 大类完整索引见 SKILL.md长文版汇总见 AGENTS.md其中第 3.7 节 Parallel Nested Data Fetching 即为本文规则的扩展版本。六、工程实践错误处理与注意事项在实际编码中还需注意以下几点属于规则之外的常识性补充帮助正确落地1. 失败语义Promise.all的快速失败Promise.all采用fail-fast快速失败语义任意一条链 reject整体立即 reject。若列表拉取中某条getChat失败会连带中断整体可考虑改用Promise.allSettled并在逐项链内降级const chatAuthors await Promise.allSettled( chatIds.map(async id { const chat await getChat(id) return getUser(chat.author) }) ) // 对 fulfilled / rejected 分别处理避免单点拖垮整体2. 逐项链式 ≠ 无限并行当chatIds数量极大如数千条时Promise.all会一次性发起大量并发请求可能打满连接池或触发上游限流。此时应引入并发上限如分批Promise.all、p-limit等逐项链式优化的收益依然成立只是需要控制在合理并发窗口内。3. 与缓存配合嵌套拉取产生的是高基数、低命中率的关联请求同一 author 可能被多条聊天重复请求。可以结合server-cache-reactReact.cache() 做请求级去重与server-cache-lru跨请求 LRU 缓存两条相邻规则在并行化的同时进一步削减重复网络开销。4. 在 OpenMontage 前端子项目中的适用场景本仓库的 remotion-composer 是 React/TypeScript 编写的视频渲染前端使用 Remotion 框架源码位于 src其中 TitledVideo.tsx 等组件会按 props 渲染标题、媒体与场景数据。当这类组件需要先取场景列表、再按场景取对应素材或字幕时同样适用本文规则把场景 → 素材/字幕的依赖链收进每条目的 Promise 内避免某个素材请求缓慢拖慢整页渲染管线。七、总结一条可以机械执行的检查清单将本文规则沉淀为代码评审与自动重构时的检查清单发现两段式Promise.all若代码中先await Promise.all(map(fetchList))、再基于结果await Promise.all(map(fetchDetail))即命中本规则判定依赖方向若第二个请求只依赖该条目自身的数据如chat.author而非整个列表的聚合结果就可以安全地改为逐项链式改写ids.map(id fetchList(id).then(item fetchDetail(item.ref)))或等价 async 写法验证收益最慢条目的耗时不再阻塞其他条目的第二阶段请求整体延迟从两段累加收敛为各链并行的近似最长链结合相邻规则对无依赖操作用 async-parallel.md对部分依赖操作参考 async-dependencies.md对 RSC 组件树场景参考 server-parallel-fetching.md。核心心法一句话Promise.all并行的是链条而不是阶段——把嵌套依赖挂到每条独立的链上慢的条目只慢自己快的条目永远不等别人。【免费下载链接】OpenMontageWorlds first open-source, agentic video production system. 12 production pipelines, 100 tools, 700 agent skill and production-knowledge files. Turn your AI coding assistant into a full video production studio.项目地址: https://gitcode.com/GitHub_Trending/op/OpenMontage创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
)
)
