AutoGPT 前端性能实践用 better-all 做依赖驱动并行化消除部分依赖的数据获取瀑布【免费下载链接】AutoGPTAutoGPT is the vision of accessible AI for everyone, to use and to build on. Our mission is to provide the tools, so that you can focus on what matters.项目地址: https://gitcode.com/GitHub_Trending/au/AutoGPT本篇围绕 AutoGPT 仓库中 Vercel React 最佳实践技能包里的async-dependencies规则Dependency-Based Parallelization展开当多个异步任务之间存在“部分依赖”时如何借助better-all让每个任务在其前置条件满足的瞬间立刻启动从而把串行的瀑布调用链压缩为真正的并行执行。读完本文你将掌握该规则的设计动机、时序收益分析、与Promise.all及 API 路由场景的选型边界并能结合 AutoGPT 平台前端Next.js 15 TanStack Query的真实代码验证这套并行化思路的落地方式。规则定位Eliminating Waterfalls 类别中的 CRITICAL 级规则async-dependencies.md是仓库内 Vercel 官方 React 性能技能包SKILL.md中的一条独立规则文件完整文档见 async-dependencies.md。该技能包收录了 45 条规则横跨 8 个类别按影响程度分级本规则位于优先级最高的第一类 “Eliminating Waterfalls消除瀑布”其 frontmatter 元数据声明了元数据字段取值含义titleDependency-Based Parallelization规则主题依赖驱动的并行化impactCRITICAL影响等级关键级impactDescription2-10× improvement预期性能收益2 到 10 倍tagsasync, parallelization, dependencies, better-all技术标签在 SKILL.md 的优先级分类表中async-前缀消除瀑布与bundle-打包体积并列为最高优先级 CRITICAL 类别。该包配套的完整编译版文档 AGENTS.md 在 “1. Eliminating Waterfalls” 开篇即指出“Waterfalls are the #1 performance killer. Each sequential await adds full network latency.”瀑布是头号性能杀手每个串行await都会叠加一个完整的网络往返延迟。async-dependencies在该文档中对应 1.2 小节是这一类别中专门处理任务间存在依赖关系这一最难场景的规则。核心问题部分依赖下的“过度等待”先看规则中给出的反例代码原样继承自 async-dependencies.mdconst [user, config] await Promise.all([ fetchUser(), fetchConfig() ]) const profile await fetchProfile(user.id)这段代码的典型错误在于profile的获取只依赖user的结果user.id与config毫无关系。但由于fetchProfile被写在Promise.all之后它必须等user和config两者都完成才能开始。换言之profile白白等待了与它无关的config请求。用时序图直观表示设三个请求各自的网络耗时为T_user、T_config、T_profile且T_config T_user错误写法Promise.all 后再串行 fetchUser: |████| fetchConfig: |████████████| fetchProfile: |████| - 被 config 拖住了 总耗时 max(T_user, T_config) T_profile规则给出的正确写法引入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) } })三个关键点值得展开每个任务都是对象里的一个方法。all()接收一个以“逻辑名称”为键、以 async 函数为值的对象返回值是一个以同名键索引的结果对象因此解构得到{ user, config, profile }可读性优于Promise.all的数组位置解构。this.$.user是跨任务引用。this是任务执行上下文this.$.user是一个指向名为user的任务之 Promise 的引用。await this.$.user表达的是“我依赖user任务的结果”而不是“我在user之后排队”。better-all的调度逻辑是一旦user任务 resolveprofile任务立即启动无需等待config。自动最大化并行度。开发者只声明“谁依赖谁”通过this.$引用而不需要手工管理 Promise 句柄、启动顺序或Promise.all的组合层级。依赖图有多宽并行度就有多宽。对照时序正确写法better-all 依赖驱动调度 fetchUser: |████| fetchConfig: |████████████| fetchProfile: |████| - user 一完成就启动与 config 并行 总耗时 T_user T_profileconfig 不占关键路径则被完全隐藏这正是规则声称 2-10× 收益的来源关键路径上每个被消除的“无效等待”节省的都是一个完整的网络往返而非毫秒级的 CPU 时间。与同族规则的边界何时用 Promise.all何时用 better-allasync-dependencies并非孤立规则它在技能包内与另外两条 CRITICAL 级瀑布消除规则形成完整的选型矩阵均位于 rules 目录完整展开版见 AGENTS.md 的 1.2–1.4 小节场景一完全独立 —— 用 Promise.all见 async-parallel.md当异步操作之间没有任何依赖时直接Promise.all即可反模式是逐个await造成的 3 次串行往返// 错误串行执行3 次往返 const user await fetchUser() const posts await fetchPosts() const comments await fetchComments() // 正确并行执行1 次往返 const [user, posts, comments] await Promise.all([ fetchUser(), fetchPosts(), fetchComments() ])场景二API 路由 / Server Actions —— 早启动、晚等待见 async-api-routes.md在路由处理器中应立即发起独立操作拿到 Promise 句柄把await推迟到真正需要结果时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 }) }该规则文末明确指路“For operations with more complex dependency chains, usebetter-allto automatically maximize parallelism (see Dependency-Based Parallelization).”——即依赖链一旦复杂到手写 Promise 句柄难以维护时升级为本规则介绍的better-all方案。选型速查依赖形态推荐方案对应规则文件无依赖纯独立Promise.all([...])async-parallel.md少量依赖需手工控制启动时机显式 Promise 句柄 晚awaitasync-api-routes.md存在部分依赖 / 复杂依赖图better-all的all({...})this.$跨任务引用async-dependencies.md三者不互斥同一段代码里可以先用“早启动句柄”争取最大并发窗口再对剩余依赖图使用better-all声明式描述。在 AutoGPT 平台前端中的落地印证AutoGPT 的平台前端autogpt_platform/frontend是典型的 Next.js App Router 应用package.json 中声明了next: 15.5.21、react: 18.3.1并以tanstack/react-query5.90.6 作为数据层。技能包中的规则正是为这类代码库的性能评审提供检查基准。现状Promise.all 已是主力并行模式从源码结构看当前代码库中尚未直接引入better-all依赖全仓库检索不到该包的使用但同族规则中的Promise.all并行模式已被广泛实践例如市场页预取marketplace/creator/[creator]/page.tsx 在服务端组件中用Promise.all并行预取“创作者的 Store Agent 列表”与“创作者详情”两个无依赖查询再经dehydrate(queryClient)交给HydrationBoundary水合把两次独立往返压缩为一次容错并行useSendMessage.ts/copilot/useSendMessage.ts#L61) 与 useRevokeAPIKey.ts/settings/api-keys/components/hooks/useRevokeAPIKey.ts#L20) 使用Promise.allSettled保证单个失败不拖垮整批任务适合批量操作场景。可以推断对于上述“独立任务并行”场景Promise.all/Promise.allSettled已经是最合适的方案而better-all规则的价值在于——当页面数据出现fetchUser → fetchProfile这类链式且与其他分支交叠的依赖时例如某详情页既要等user完成才能请求profile又要并行拉取与二者都无关的notifications手写 Promise 句柄的写法会出现嵌套和命名混乱此时all({ ... })的对象式声明 this.$引用能同时保证“正确性不多等”和“可维护性依赖关系显式化”。应用前提与限制依赖引入better-all是社区 npm 包规则原文给出的 Reference 指向 shuding/better-all 项目使用前需按 package.json 所在工作区用pnpm add better-all安装本文仅说明引入方式不代表已修改仓库。异常语义better-all的all与原生Promise.all一样遵循“快失败”语义任一任务 reject 整体即 reject若需要部分失败容忍应改用其allSettled变体或回到Promise.allSettled组合。收益边界2-10× 的标注是针对“每个串行 await 叠加一次完整网络延迟”的瀑布场景若被消除的等待是内存级同步计算收益会趋近于零。因此评审代码时应优先在跨网络请求的依赖链上应用本规则这与 AGENTS.md 将水瀑消除列为第一优先级的理由一致。小结与延伸阅读async-dependencies规则给出了一条清晰的工程判断当并行任务之间存在部分依赖时与其靠“先Promise.all再串行”牺牲无关分支的等待时间不如用better-all显式声明依赖图让调度器把每个任务压到最早可启动时刻。结合仓库内三条同族规则文件——async-defer-await.md把await推迟到真正用到的分支、async-parallel.md独立任务用Promise.all、async-api-routes.md路由中早发起、晚等待——以及 AGENTS.md 中完整的 8 类 45 条规则体系即可在 AutoGPT 平台这类 Next.js 应用中系统性地审查并消除数据获取路径上的每一段无效等待。【免费下载链接】AutoGPTAutoGPT is the vision of accessible AI for everyone, to use and to build on. Our mission is to provide the tools, so that you can focus on what matters.项目地址: https://gitcode.com/GitHub_Trending/au/AutoGPT创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 AutoGPT 前端性能实践：用 better-all 做依赖驱动并行化，消除部分依赖的数据获取瀑布
AutoGPT 前端性能实践用 better-all 做依赖驱动并行化消除部分依赖的数据获取瀑布【免费下载链接】AutoGPTAutoGPT is the vision of accessible AI for everyone, to use and to build on. Our mission is to provide the tools, so that you can focus on what matters.项目地址: https://gitcode.com/GitHub_Trending/au/AutoGPT本篇围绕 AutoGPT 仓库中 Vercel React 最佳实践技能包里的async-dependencies规则Dependency-Based Parallelization展开当多个异步任务之间存在“部分依赖”时如何借助better-all让每个任务在其前置条件满足的瞬间立刻启动从而把串行的瀑布调用链压缩为真正的并行执行。读完本文你将掌握该规则的设计动机、时序收益分析、与Promise.all及 API 路由场景的选型边界并能结合 AutoGPT 平台前端Next.js 15 TanStack Query的真实代码验证这套并行化思路的落地方式。规则定位Eliminating Waterfalls 类别中的 CRITICAL 级规则async-dependencies.md是仓库内 Vercel 官方 React 性能技能包SKILL.md中的一条独立规则文件完整文档见 async-dependencies.md。该技能包收录了 45 条规则横跨 8 个类别按影响程度分级本规则位于优先级最高的第一类 “Eliminating Waterfalls消除瀑布”其 frontmatter 元数据声明了元数据字段取值含义titleDependency-Based Parallelization规则主题依赖驱动的并行化impactCRITICAL影响等级关键级impactDescription2-10× improvement预期性能收益2 到 10 倍tagsasync, parallelization, dependencies, better-all技术标签在 SKILL.md 的优先级分类表中async-前缀消除瀑布与bundle-打包体积并列为最高优先级 CRITICAL 类别。该包配套的完整编译版文档 AGENTS.md 在 “1. Eliminating Waterfalls” 开篇即指出“Waterfalls are the #1 performance killer. Each sequential await adds full network latency.”瀑布是头号性能杀手每个串行await都会叠加一个完整的网络往返延迟。async-dependencies在该文档中对应 1.2 小节是这一类别中专门处理任务间存在依赖关系这一最难场景的规则。核心问题部分依赖下的“过度等待”先看规则中给出的反例代码原样继承自 async-dependencies.mdconst [user, config] await Promise.all([ fetchUser(), fetchConfig() ]) const profile await fetchProfile(user.id)这段代码的典型错误在于profile的获取只依赖user的结果user.id与config毫无关系。但由于fetchProfile被写在Promise.all之后它必须等user和config两者都完成才能开始。换言之profile白白等待了与它无关的config请求。用时序图直观表示设三个请求各自的网络耗时为T_user、T_config、T_profile且T_config T_user错误写法Promise.all 后再串行 fetchUser: |████| fetchConfig: |████████████| fetchProfile: |████| - 被 config 拖住了 总耗时 max(T_user, T_config) T_profile规则给出的正确写法引入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) } })三个关键点值得展开每个任务都是对象里的一个方法。all()接收一个以“逻辑名称”为键、以 async 函数为值的对象返回值是一个以同名键索引的结果对象因此解构得到{ user, config, profile }可读性优于Promise.all的数组位置解构。this.$.user是跨任务引用。this是任务执行上下文this.$.user是一个指向名为user的任务之 Promise 的引用。await this.$.user表达的是“我依赖user任务的结果”而不是“我在user之后排队”。better-all的调度逻辑是一旦user任务 resolveprofile任务立即启动无需等待config。自动最大化并行度。开发者只声明“谁依赖谁”通过this.$引用而不需要手工管理 Promise 句柄、启动顺序或Promise.all的组合层级。依赖图有多宽并行度就有多宽。对照时序正确写法better-all 依赖驱动调度 fetchUser: |████| fetchConfig: |████████████| fetchProfile: |████| - user 一完成就启动与 config 并行 总耗时 T_user T_profileconfig 不占关键路径则被完全隐藏这正是规则声称 2-10× 收益的来源关键路径上每个被消除的“无效等待”节省的都是一个完整的网络往返而非毫秒级的 CPU 时间。与同族规则的边界何时用 Promise.all何时用 better-allasync-dependencies并非孤立规则它在技能包内与另外两条 CRITICAL 级瀑布消除规则形成完整的选型矩阵均位于 rules 目录完整展开版见 AGENTS.md 的 1.2–1.4 小节场景一完全独立 —— 用 Promise.all见 async-parallel.md当异步操作之间没有任何依赖时直接Promise.all即可反模式是逐个await造成的 3 次串行往返// 错误串行执行3 次往返 const user await fetchUser() const posts await fetchPosts() const comments await fetchComments() // 正确并行执行1 次往返 const [user, posts, comments] await Promise.all([ fetchUser(), fetchPosts(), fetchComments() ])场景二API 路由 / Server Actions —— 早启动、晚等待见 async-api-routes.md在路由处理器中应立即发起独立操作拿到 Promise 句柄把await推迟到真正需要结果时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 }) }该规则文末明确指路“For operations with more complex dependency chains, usebetter-allto automatically maximize parallelism (see Dependency-Based Parallelization).”——即依赖链一旦复杂到手写 Promise 句柄难以维护时升级为本规则介绍的better-all方案。选型速查依赖形态推荐方案对应规则文件无依赖纯独立Promise.all([...])async-parallel.md少量依赖需手工控制启动时机显式 Promise 句柄 晚awaitasync-api-routes.md存在部分依赖 / 复杂依赖图better-all的all({...})this.$跨任务引用async-dependencies.md三者不互斥同一段代码里可以先用“早启动句柄”争取最大并发窗口再对剩余依赖图使用better-all声明式描述。在 AutoGPT 平台前端中的落地印证AutoGPT 的平台前端autogpt_platform/frontend是典型的 Next.js App Router 应用package.json 中声明了next: 15.5.21、react: 18.3.1并以tanstack/react-query5.90.6 作为数据层。技能包中的规则正是为这类代码库的性能评审提供检查基准。现状Promise.all 已是主力并行模式从源码结构看当前代码库中尚未直接引入better-all依赖全仓库检索不到该包的使用但同族规则中的Promise.all并行模式已被广泛实践例如市场页预取marketplace/creator/[creator]/page.tsx 在服务端组件中用Promise.all并行预取“创作者的 Store Agent 列表”与“创作者详情”两个无依赖查询再经dehydrate(queryClient)交给HydrationBoundary水合把两次独立往返压缩为一次容错并行useSendMessage.ts/copilot/useSendMessage.ts#L61) 与 useRevokeAPIKey.ts/settings/api-keys/components/hooks/useRevokeAPIKey.ts#L20) 使用Promise.allSettled保证单个失败不拖垮整批任务适合批量操作场景。可以推断对于上述“独立任务并行”场景Promise.all/Promise.allSettled已经是最合适的方案而better-all规则的价值在于——当页面数据出现fetchUser → fetchProfile这类链式且与其他分支交叠的依赖时例如某详情页既要等user完成才能请求profile又要并行拉取与二者都无关的notifications手写 Promise 句柄的写法会出现嵌套和命名混乱此时all({ ... })的对象式声明 this.$引用能同时保证“正确性不多等”和“可维护性依赖关系显式化”。应用前提与限制依赖引入better-all是社区 npm 包规则原文给出的 Reference 指向 shuding/better-all 项目使用前需按 package.json 所在工作区用pnpm add better-all安装本文仅说明引入方式不代表已修改仓库。异常语义better-all的all与原生Promise.all一样遵循“快失败”语义任一任务 reject 整体即 reject若需要部分失败容忍应改用其allSettled变体或回到Promise.allSettled组合。收益边界2-10× 的标注是针对“每个串行 await 叠加一次完整网络延迟”的瀑布场景若被消除的等待是内存级同步计算收益会趋近于零。因此评审代码时应优先在跨网络请求的依赖链上应用本规则这与 AGENTS.md 将水瀑消除列为第一优先级的理由一致。小结与延伸阅读async-dependencies规则给出了一条清晰的工程判断当并行任务之间存在部分依赖时与其靠“先Promise.all再串行”牺牲无关分支的等待时间不如用better-all显式声明依赖图让调度器把每个任务压到最早可启动时刻。结合仓库内三条同族规则文件——async-defer-await.md把await推迟到真正用到的分支、async-parallel.md独立任务用Promise.all、async-api-routes.md路由中早发起、晚等待——以及 AGENTS.md 中完整的 8 类 45 条规则体系即可在 AutoGPT 平台这类 Next.js 应用中系统性地审查并消除数据获取路径上的每一段无效等待。【免费下载链接】AutoGPTAutoGPT is the vision of accessible AI for everyone, to use and to build on. Our mission is to provide the tools, so that you can focus on what matters.项目地址: https://gitcode.com/GitHub_Trending/au/AutoGPT创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考