OpenMontage 服务端并行嵌套数据获取用 Promise 链式组合消除 RSC 瀑布流【免费下载链接】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导读本文讲解 OpenMontage 仓库中vercel-react-best-practices技能集内的一条CRITICAL 级性能规则——「并行嵌套数据获取」Parallel Nested Data Fetching。它针对 React Server Components 与 Next.js 服务端数据加载中最隐蔽的一类性能陷阱看似并行、实则被单个慢请求拖垮全局的两阶段Promise.all瀑布流。读完本文你将掌握在批量嵌套取数时「在每项 promise 内部链式组合依赖请求」的核心写法并理解它与组件组合、better-all、API 路由延迟 await 等相邻规则之间的配合关系可直接套用于自己项目中的 RSC 与 API 路由改造。一、规则来源与定位该规则以独立 Markdown 文件的形式存放于仓库中规则主文件完全一致的副本.claude与.agents两个技能目录各维护一份实测 diff 内容完全一致文件头部 frontmatter 给出了它的元信息--- title: Parallel Nested Data Fetching impact: CRITICAL impactDescription: eliminates server-side waterfalls tags: server, rsc, parallel-fetching, promise-chaining ---三个关键信号impact: CRITICAL——整个技能集中最高优先级的两个级别之一impact 级别体系见 SKILL.md 的 Impact Levels 说明CRITICAL代表能带来最大性能收益的规则impactDescription: eliminates server-side waterfalls——它直接对治服务端瀑布流问题tags: server, rsc, parallel-fetching, promise-chaining——它属于server-前缀的「服务端性能」分类适用场景是 React Server Components。按照 _sections.md 的分类定义server-前缀属于第 3 类「Server-Side Performance服务端性能」影响级别为HIGH而 SKILL.md 的 Quick Reference 中本规则server-parallel-nested-fetching与server-parallel-fetching、server-cache-react等 9 条规则并列。根据 SKILL.md 的描述该技能集专门用于编写、审查或重构 React/Next.js 代码时保证性能模式正确是 Agent 在生成或评审 React 代码时的重要约束来源。二、问题背景服务端瀑布流Waterfall为什么是头号性能杀手在理解这条规则之前需要先建立「瀑布流」的概念。_sections.md对其定性非常直接Waterfalls are the #1 performance killer. Each sequential await adds full network latency.即每多一次顺序await就多付出整整一轮完整的网络往返延迟。假设单次数据库/外部 API 调用耗时 100ms三次顺序调用就是 300ms 起步而如果其中某次调用本身又慢比如 500ms所有后续调用都会跟着排队等待总耗时变成各项耗时之和而不是最大值。RSC 场景下问题会更严重React Server Components 在组件树内是串行执行的父组件await完成前子树无法开始渲染所以任何藏在组件树深处的顺序await都会让整个页面的流式渲染被拖慢。这正是为什么消除瀑布流被列为技能集的第 1 类「Eliminating Waterfallsasync」且同为 CRITICAL。瀑布流的典型来源有几种对应的规则各有分工瀑布流形态对治规则文件无依赖的多个独立请求被逐个await用Promise.all并发执行async-parallel.md组件树串行导致父子取数排队用组件组合重构让兄弟组件并行取数server-parallel-fetching.md批量列表内每项还依赖各自的二次取数在每项 promise 内部链式组合本文主角server-parallel-nested-fetching.md部分请求之间存在依赖关系用better-all自动最大化并行async-dependencies.md本规则解决的是其中最隐蔽的一种数据本身有依赖先取 chat 才能取作者但批量层面又希望并行的场景。三、反例解析两阶段 Promise.all 造成的「隐性瀑布流」规则文档首先给出的错误写法如下const chats await Promise.all( chatIds.map(id getChat(id)) ) const chatAuthors await Promise.all( chats.map(chat getUser(chat.author)) )表面上看这里用了两次Promise.all第一眼甚至会觉得「已经并行了」。但关键在于两个Promise.all之间是严格串行的——第二阶段必须等第一阶段的Promise.all整体完成之后才能启动。规则文档点明了代价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.即100 个 chat 中只要有 1 个getChat(id)极慢其余 99 个 chat 的作者请求就必须干等着尽管它们的数据早就齐了。用时间线可以看得更清楚假设每个getChat平均 50ms第 50 个 chat 的getChat慢到 2s第一阶段所有 getChat 并行 ├── chat_1..49, chat_51..100: 完成于 ~50ms └── chat_50: 完成于 ~2000ms ← 整个阶段被拖到 2000ms 第二阶段所有 getUser 并行但必须等第一阶段结束 ├── 全部 getUser 开始于 ~2000ms └── 全部 getUser 完成于 ~2050ms 总耗时 ≈ 2050ms问题本质是Promise.all的完成时机取决于最慢的成员而第二阶段又整体依赖第一阶段完成。两个Promise.all拼接等于把「最慢项耗时」和「第二阶段耗时」强行相加制造了一条虽然两端各自并行、中间却被最慢项卡死的隐性瀑布流。四、正解在每项 promise 内部链式组合依赖请求规则文档给出的正确写法非常简洁const chatAuthors await Promise.all( chatIds.map(id getChat(id).then(chat getUser(chat.author))) )核心变化只有一处把「取 chat」和「取 chat 的作者」这两个有依赖关系的请求用.then()在单个 item 的 promise 内部链起来然后让Promise.all去并行调度这 100 条独立的 promise 链。规则文档的解释Each item independently chainsgetChat→getUser, so a slow chat doesnt block author fetches for the others.即每个 item 独立执行getChat→getUser的链某个 chat 慢只会影响它自己那条链不会阻塞其他 99 条链上的作者请求。再看时间线100 条独立链Promise.all 同时启动 ├── chat_1: getChat(50ms) → getUser(50ms) 完成于 ~100ms ├── chat_2: getChat(50ms) → getUser(50ms) 完成于 ~100ms ├── ... ├── chat_49: 完成于 ~100ms ├── chat_50: getChat(2000ms) → getUser(50ms) 完成于 ~2050ms ← 只拖慢自己 └── chat_51..100: 完成于 ~100ms 总耗时 ≈ 2050ms但 99 条链在 100ms 就已交付总耗时数字上两者相近因为Promise.all的完成时间始终取决于最慢成员但差异在于其余 99 条链的完成时刻错误写法里它们要等到 2000ms 之后才开始getUser正确写法里它们在 100ms 就已经拿到了作者数据。在 React Server Components 中这意味着页面可以更早地流式输出已经就绪的部分——能早交付 1.9 秒的数据对用户体验TTFB、首屏流式渲染和下游渲染流水线是质的差别。这条规则可以推广到任意深度的依赖链例如getChat(id).then(getAuthor).then(getAuthorPosts)只要依赖是线性的就在同一条 promise 内链下去让Promise.all在链之间保持并行。五、扩展一部分依赖场景——先建 Promise 再统一 awaitPromise.all 链式组合解决了「批量内每项有依赖」的问题但还有一种更复杂的形态多个请求中只有一部分互相依赖另一部分相互独立。规则集为此提供了两个方案见 async-dependencies.md。第一个方案是引入better-all让每个任务在最早可启动的时机自动启动import { all } from better-all const { user, config, profile } await all({ async user() { return fetchUser() }, async config() { return fetchConfig() }, async profile() { return fetchProfile((await this.$.user).id) } })其中config与profile互不依赖better-all会让二者并行只有profile需要等待user。第二个方案不引入任何额外依赖思路与本文主规则一脉相承——先把 promise 创建出来promise 一旦创建就开始执行需要依赖的地方用.then()接上最后统一Promise.allconst userPromise fetchUser() const profilePromise userPromise.then(user fetchProfile(user.id)) const [user, config, profile] await Promise.all([ userPromise, fetchConfig(), profilePromise ])注意这个写法与第三节反例的本质区别反例是先await完第一批、再启动第二批而这里所有 promise 在await之前就已全部创建并开始执行Promise.all只是最后汇总结果。这与本规则的底层原则完全一致——尽早启动、链式接依赖、统一收口。六、扩展二尽早开始、推迟 await——API 路由与分支优化本规则的思路还可以沿两条相邻规则继续深化。6.1 API 路由先发起、后 await在 API Routes 与 Server Actions 中async-api-routes.md 给出了同样的「尽早启动」原则独立操作立刻发起即使暂时不await它们。// 错误config 等 authdata 等两者 export async function GET(request: Request) { const session await auth() const config await fetchConfig() const data await fetchData(session.user.id) return Response.json({ data, config }) }// 正确auth 和 config 立即启动 export async function GET(request: Request) { const sessionPromise auth() const configPromise fetchConfig() const session await sessionPromise const [config, data] await Promise.all([ configPromise, fetchData(session.user.id) ]) return Response.json({ data, config }) }这里的sessionPromise/configPromise模式本质上就是把本文「在 promise 内部链式组合」从批量列表推广到了路由层的多请求编排。6.2 延迟 await只在真正需要的分支里 awaitasync-defer-await.md 则从另一个角度消除等待把await移进真正使用它的代码分支让不需要该数据的代码路径不被阻塞。async function handleRequest(userId: string, skipProcessing: boolean) { if (skipProcessing) { // 立即返回不用等 userData return { skipped: true } } // 只在需要时才取数 const userData await fetchUserData(userId) return processUserData(userData) }该规则特别强调当被跳过的分支是高频路径、或被延迟的操作成本很高时收益最为明显——这与本文「一个慢 item 不该拖垮其他 99 个 item」的思想一脉相承把等待限制在最小必要范围内。七、扩展三与组件组合式并行server-parallel-fetching的配合本文规则解决的是单个组件内部的批量取数并行而 server-parallel-fetching.md 解决的是组件树层面的串行问题——RSC 组件在树内串行执行父组件await会阻塞子树渲染。// 错误Sidebar 必须等 Page 的 fetch 完成 export default async function Page() { const header await fetchHeader() return ( div div{header}/div Sidebar / /div ) } async function Sidebar() { const items await fetchSidebarItems() return nav{items.map(renderItem)}/nav }// 正确两个组件各自取数同时进行 async function Header() { const data await fetchHeader() return div{data}/div } async function Sidebar() { const items await fetchSidebarItems() return nav{items.map(renderItem)}/nav } export default function Page() { return ( div Header / Sidebar / /div ) }两条规则是互补关系可以叠加使用组件层面把无依赖的取数拆到兄弟组件/叶子组件中让组件树并行取数数据层面在每个组件内部对批量列表的嵌套依赖用本文的「item 内链式」写法并行化。一个实际页面往往是两者结合外层用组件组合让Header、Sidebar、Main并行Main内部再用Promise.all(chatIds.map(...))的链式写法批量取嵌套数据。八、实战决策指南什么时候用哪种写法综合技能集内各条规则可以给出一个面向实际编码的决策表场景推荐写法依据规则多个请求完全独立await Promise.all([a(), b(), c()])async-parallel.md批量列表每项内部有线性依赖Promise.all(items.map(item fetchA(item).then(a fetchB(a))))本文规则部分请求互相依赖网状依赖better-all或「先建 promise then 链 统一 Promise.all」async-dependencies.mdAPI 路由/Server Action 多请求编排先const p fetchX()后统一await Promise.all([...])async-api-routes.md数据只在某分支使用把await移进该分支async-defer-await.md组件间无依赖取数被树形串行阻塞拆成兄弟组件/叶子组件server-parallel-fetching.md边界情况与注意事项Promise.all的 fail-fast 特性任一 promise reject 会立即整体失败。若希望「单项失败不影响其他项」可改用Promise.allSettled并在链内处理错误。列表过大时上百个 item 的链式请求虽然并行但仍要注意对下游数据库、外部 API的并发压力必要时可分批如每批 20 个执行。重复取数的去重同一请求在单次渲染中可能被多处引用服务端可用React.cache()做按请求维度的去重见规则 server-cache-react.md避免并发改写后反而放大请求量。九、在 OpenMontage 中的应用场景OpenMontage 的 SKILL.md 明确指出这套技能在编写、审查或重构 React/Next.js 代码时触发使用。从仓库结构看OpenMontage 恰好包含一块基于 Remotion 的 React TypeScript 前端工程 remotion-composer含CinematicRenderer.tsx、Explainer.tsx、TalkingHead.tsx等组件以及配套的渲染契约测试如 test_remotion_video_transition_contract.py、test_remotion_audio_mux.py。虽然这些组件主要面向视频合成场景但 RSC/服务端数据加载的并发原则同样适用于其中的任何异步数据准备逻辑。在 OpenMontage 的 Agent 工作流中这条规则的典型落地方式包括代码生成阶段Agent 生成 React 组件的数据加载代码时若出现「先await Promise.all(...)一批再await Promise.all(...)下一批」的写法应自动改写为「每项 promise 内链式组合」代码审查阶段作为 CRITICAL 级约束在 review 清单中优先排查服务端瀑布流规则扩展仓库的 _template.md 提供了新增规则的模板README.md则说明了pnpm build/pnpm validate的构建验证流程团队可按需沉淀自己的并行取数约束。十、小结「并行嵌套数据获取」这条 CRITICAL 规则浓缩成一句话就是批量有依赖的嵌套取数时把依赖链写进每个 item 自己的 promise 里让Promise.all只管并行调度。它通过消除「两阶段Promise.all」之间被最慢项卡死的隐性瀑布流让已就绪的数据可以第一时间流向渲染流水线。它与组件组合server-parallel-fetching、better-all部分依赖并行async-dependencies、API 路由延迟 awaitasync-api-routes等规则共同构成了 RSC 服务端性能优化从组件树到单组件、从批量到路由的完整工具箱。后续在 OpenMontage 中审查或生成 React/Next.js 取数代码时建议始终带着这条规则做一次「瀑布流体检」凡出现连续两次await 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 服务端并行嵌套数据获取：用 Promise 链式组合消除 RSC 瀑布流
OpenMontage 服务端并行嵌套数据获取用 Promise 链式组合消除 RSC 瀑布流【免费下载链接】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导读本文讲解 OpenMontage 仓库中vercel-react-best-practices技能集内的一条CRITICAL 级性能规则——「并行嵌套数据获取」Parallel Nested Data Fetching。它针对 React Server Components 与 Next.js 服务端数据加载中最隐蔽的一类性能陷阱看似并行、实则被单个慢请求拖垮全局的两阶段Promise.all瀑布流。读完本文你将掌握在批量嵌套取数时「在每项 promise 内部链式组合依赖请求」的核心写法并理解它与组件组合、better-all、API 路由延迟 await 等相邻规则之间的配合关系可直接套用于自己项目中的 RSC 与 API 路由改造。一、规则来源与定位该规则以独立 Markdown 文件的形式存放于仓库中规则主文件完全一致的副本.claude与.agents两个技能目录各维护一份实测 diff 内容完全一致文件头部 frontmatter 给出了它的元信息--- title: Parallel Nested Data Fetching impact: CRITICAL impactDescription: eliminates server-side waterfalls tags: server, rsc, parallel-fetching, promise-chaining ---三个关键信号impact: CRITICAL——整个技能集中最高优先级的两个级别之一impact 级别体系见 SKILL.md 的 Impact Levels 说明CRITICAL代表能带来最大性能收益的规则impactDescription: eliminates server-side waterfalls——它直接对治服务端瀑布流问题tags: server, rsc, parallel-fetching, promise-chaining——它属于server-前缀的「服务端性能」分类适用场景是 React Server Components。按照 _sections.md 的分类定义server-前缀属于第 3 类「Server-Side Performance服务端性能」影响级别为HIGH而 SKILL.md 的 Quick Reference 中本规则server-parallel-nested-fetching与server-parallel-fetching、server-cache-react等 9 条规则并列。根据 SKILL.md 的描述该技能集专门用于编写、审查或重构 React/Next.js 代码时保证性能模式正确是 Agent 在生成或评审 React 代码时的重要约束来源。二、问题背景服务端瀑布流Waterfall为什么是头号性能杀手在理解这条规则之前需要先建立「瀑布流」的概念。_sections.md对其定性非常直接Waterfalls are the #1 performance killer. Each sequential await adds full network latency.即每多一次顺序await就多付出整整一轮完整的网络往返延迟。假设单次数据库/外部 API 调用耗时 100ms三次顺序调用就是 300ms 起步而如果其中某次调用本身又慢比如 500ms所有后续调用都会跟着排队等待总耗时变成各项耗时之和而不是最大值。RSC 场景下问题会更严重React Server Components 在组件树内是串行执行的父组件await完成前子树无法开始渲染所以任何藏在组件树深处的顺序await都会让整个页面的流式渲染被拖慢。这正是为什么消除瀑布流被列为技能集的第 1 类「Eliminating Waterfallsasync」且同为 CRITICAL。瀑布流的典型来源有几种对应的规则各有分工瀑布流形态对治规则文件无依赖的多个独立请求被逐个await用Promise.all并发执行async-parallel.md组件树串行导致父子取数排队用组件组合重构让兄弟组件并行取数server-parallel-fetching.md批量列表内每项还依赖各自的二次取数在每项 promise 内部链式组合本文主角server-parallel-nested-fetching.md部分请求之间存在依赖关系用better-all自动最大化并行async-dependencies.md本规则解决的是其中最隐蔽的一种数据本身有依赖先取 chat 才能取作者但批量层面又希望并行的场景。三、反例解析两阶段 Promise.all 造成的「隐性瀑布流」规则文档首先给出的错误写法如下const chats await Promise.all( chatIds.map(id getChat(id)) ) const chatAuthors await Promise.all( chats.map(chat getUser(chat.author)) )表面上看这里用了两次Promise.all第一眼甚至会觉得「已经并行了」。但关键在于两个Promise.all之间是严格串行的——第二阶段必须等第一阶段的Promise.all整体完成之后才能启动。规则文档点明了代价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.即100 个 chat 中只要有 1 个getChat(id)极慢其余 99 个 chat 的作者请求就必须干等着尽管它们的数据早就齐了。用时间线可以看得更清楚假设每个getChat平均 50ms第 50 个 chat 的getChat慢到 2s第一阶段所有 getChat 并行 ├── chat_1..49, chat_51..100: 完成于 ~50ms └── chat_50: 完成于 ~2000ms ← 整个阶段被拖到 2000ms 第二阶段所有 getUser 并行但必须等第一阶段结束 ├── 全部 getUser 开始于 ~2000ms └── 全部 getUser 完成于 ~2050ms 总耗时 ≈ 2050ms问题本质是Promise.all的完成时机取决于最慢的成员而第二阶段又整体依赖第一阶段完成。两个Promise.all拼接等于把「最慢项耗时」和「第二阶段耗时」强行相加制造了一条虽然两端各自并行、中间却被最慢项卡死的隐性瀑布流。四、正解在每项 promise 内部链式组合依赖请求规则文档给出的正确写法非常简洁const chatAuthors await Promise.all( chatIds.map(id getChat(id).then(chat getUser(chat.author))) )核心变化只有一处把「取 chat」和「取 chat 的作者」这两个有依赖关系的请求用.then()在单个 item 的 promise 内部链起来然后让Promise.all去并行调度这 100 条独立的 promise 链。规则文档的解释Each item independently chainsgetChat→getUser, so a slow chat doesnt block author fetches for the others.即每个 item 独立执行getChat→getUser的链某个 chat 慢只会影响它自己那条链不会阻塞其他 99 条链上的作者请求。再看时间线100 条独立链Promise.all 同时启动 ├── chat_1: getChat(50ms) → getUser(50ms) 完成于 ~100ms ├── chat_2: getChat(50ms) → getUser(50ms) 完成于 ~100ms ├── ... ├── chat_49: 完成于 ~100ms ├── chat_50: getChat(2000ms) → getUser(50ms) 完成于 ~2050ms ← 只拖慢自己 └── chat_51..100: 完成于 ~100ms 总耗时 ≈ 2050ms但 99 条链在 100ms 就已交付总耗时数字上两者相近因为Promise.all的完成时间始终取决于最慢成员但差异在于其余 99 条链的完成时刻错误写法里它们要等到 2000ms 之后才开始getUser正确写法里它们在 100ms 就已经拿到了作者数据。在 React Server Components 中这意味着页面可以更早地流式输出已经就绪的部分——能早交付 1.9 秒的数据对用户体验TTFB、首屏流式渲染和下游渲染流水线是质的差别。这条规则可以推广到任意深度的依赖链例如getChat(id).then(getAuthor).then(getAuthorPosts)只要依赖是线性的就在同一条 promise 内链下去让Promise.all在链之间保持并行。五、扩展一部分依赖场景——先建 Promise 再统一 awaitPromise.all 链式组合解决了「批量内每项有依赖」的问题但还有一种更复杂的形态多个请求中只有一部分互相依赖另一部分相互独立。规则集为此提供了两个方案见 async-dependencies.md。第一个方案是引入better-all让每个任务在最早可启动的时机自动启动import { all } from better-all const { user, config, profile } await all({ async user() { return fetchUser() }, async config() { return fetchConfig() }, async profile() { return fetchProfile((await this.$.user).id) } })其中config与profile互不依赖better-all会让二者并行只有profile需要等待user。第二个方案不引入任何额外依赖思路与本文主规则一脉相承——先把 promise 创建出来promise 一旦创建就开始执行需要依赖的地方用.then()接上最后统一Promise.allconst userPromise fetchUser() const profilePromise userPromise.then(user fetchProfile(user.id)) const [user, config, profile] await Promise.all([ userPromise, fetchConfig(), profilePromise ])注意这个写法与第三节反例的本质区别反例是先await完第一批、再启动第二批而这里所有 promise 在await之前就已全部创建并开始执行Promise.all只是最后汇总结果。这与本规则的底层原则完全一致——尽早启动、链式接依赖、统一收口。六、扩展二尽早开始、推迟 await——API 路由与分支优化本规则的思路还可以沿两条相邻规则继续深化。6.1 API 路由先发起、后 await在 API Routes 与 Server Actions 中async-api-routes.md 给出了同样的「尽早启动」原则独立操作立刻发起即使暂时不await它们。// 错误config 等 authdata 等两者 export async function GET(request: Request) { const session await auth() const config await fetchConfig() const data await fetchData(session.user.id) return Response.json({ data, config }) }// 正确auth 和 config 立即启动 export async function GET(request: Request) { const sessionPromise auth() const configPromise fetchConfig() const session await sessionPromise const [config, data] await Promise.all([ configPromise, fetchData(session.user.id) ]) return Response.json({ data, config }) }这里的sessionPromise/configPromise模式本质上就是把本文「在 promise 内部链式组合」从批量列表推广到了路由层的多请求编排。6.2 延迟 await只在真正需要的分支里 awaitasync-defer-await.md 则从另一个角度消除等待把await移进真正使用它的代码分支让不需要该数据的代码路径不被阻塞。async function handleRequest(userId: string, skipProcessing: boolean) { if (skipProcessing) { // 立即返回不用等 userData return { skipped: true } } // 只在需要时才取数 const userData await fetchUserData(userId) return processUserData(userData) }该规则特别强调当被跳过的分支是高频路径、或被延迟的操作成本很高时收益最为明显——这与本文「一个慢 item 不该拖垮其他 99 个 item」的思想一脉相承把等待限制在最小必要范围内。七、扩展三与组件组合式并行server-parallel-fetching的配合本文规则解决的是单个组件内部的批量取数并行而 server-parallel-fetching.md 解决的是组件树层面的串行问题——RSC 组件在树内串行执行父组件await会阻塞子树渲染。// 错误Sidebar 必须等 Page 的 fetch 完成 export default async function Page() { const header await fetchHeader() return ( div div{header}/div Sidebar / /div ) } async function Sidebar() { const items await fetchSidebarItems() return nav{items.map(renderItem)}/nav }// 正确两个组件各自取数同时进行 async function Header() { const data await fetchHeader() return div{data}/div } async function Sidebar() { const items await fetchSidebarItems() return nav{items.map(renderItem)}/nav } export default function Page() { return ( div Header / Sidebar / /div ) }两条规则是互补关系可以叠加使用组件层面把无依赖的取数拆到兄弟组件/叶子组件中让组件树并行取数数据层面在每个组件内部对批量列表的嵌套依赖用本文的「item 内链式」写法并行化。一个实际页面往往是两者结合外层用组件组合让Header、Sidebar、Main并行Main内部再用Promise.all(chatIds.map(...))的链式写法批量取嵌套数据。八、实战决策指南什么时候用哪种写法综合技能集内各条规则可以给出一个面向实际编码的决策表场景推荐写法依据规则多个请求完全独立await Promise.all([a(), b(), c()])async-parallel.md批量列表每项内部有线性依赖Promise.all(items.map(item fetchA(item).then(a fetchB(a))))本文规则部分请求互相依赖网状依赖better-all或「先建 promise then 链 统一 Promise.all」async-dependencies.mdAPI 路由/Server Action 多请求编排先const p fetchX()后统一await Promise.all([...])async-api-routes.md数据只在某分支使用把await移进该分支async-defer-await.md组件间无依赖取数被树形串行阻塞拆成兄弟组件/叶子组件server-parallel-fetching.md边界情况与注意事项Promise.all的 fail-fast 特性任一 promise reject 会立即整体失败。若希望「单项失败不影响其他项」可改用Promise.allSettled并在链内处理错误。列表过大时上百个 item 的链式请求虽然并行但仍要注意对下游数据库、外部 API的并发压力必要时可分批如每批 20 个执行。重复取数的去重同一请求在单次渲染中可能被多处引用服务端可用React.cache()做按请求维度的去重见规则 server-cache-react.md避免并发改写后反而放大请求量。九、在 OpenMontage 中的应用场景OpenMontage 的 SKILL.md 明确指出这套技能在编写、审查或重构 React/Next.js 代码时触发使用。从仓库结构看OpenMontage 恰好包含一块基于 Remotion 的 React TypeScript 前端工程 remotion-composer含CinematicRenderer.tsx、Explainer.tsx、TalkingHead.tsx等组件以及配套的渲染契约测试如 test_remotion_video_transition_contract.py、test_remotion_audio_mux.py。虽然这些组件主要面向视频合成场景但 RSC/服务端数据加载的并发原则同样适用于其中的任何异步数据准备逻辑。在 OpenMontage 的 Agent 工作流中这条规则的典型落地方式包括代码生成阶段Agent 生成 React 组件的数据加载代码时若出现「先await Promise.all(...)一批再await Promise.all(...)下一批」的写法应自动改写为「每项 promise 内链式组合」代码审查阶段作为 CRITICAL 级约束在 review 清单中优先排查服务端瀑布流规则扩展仓库的 _template.md 提供了新增规则的模板README.md则说明了pnpm build/pnpm validate的构建验证流程团队可按需沉淀自己的并行取数约束。十、小结「并行嵌套数据获取」这条 CRITICAL 规则浓缩成一句话就是批量有依赖的嵌套取数时把依赖链写进每个 item 自己的 promise 里让Promise.all只管并行调度。它通过消除「两阶段Promise.all」之间被最慢项卡死的隐性瀑布流让已就绪的数据可以第一时间流向渲染流水线。它与组件组合server-parallel-fetching、better-all部分依赖并行async-dependencies、API 路由延迟 awaitasync-api-routes等规则共同构成了 RSC 服务端性能优化从组件树到单组件、从批量到路由的完整工具箱。后续在 OpenMontage 中审查或生成 React/Next.js 取数代码时建议始终带着这条规则做一次「瀑布流体检」凡出现连续两次await 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），仅供参考