AutoGPT Platform 前端性能实践用 Promise.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-parallel展开当多个异步操作彼此没有依赖关系时应使用Promise.all()并发执行而非顺序await从而把 N 次网络往返压缩为 1 次。读完后你将理解这条规则为何被列为 CRITICAL 级优化掌握其正确/错误写法的判断标准并能在 AutoGPT Platform 的 Next.js 前端源码中找到多处真实落地的并行化案例与进阶变体并发受限的 worker 池。规则定位它来自哪套规范、优先级多高async-parallel规则保存在 AutoGPT 仓库的 Vercel React 最佳实践技能目录中rules/async-parallel.md。该目录的 SKILL.md 说明这是一套面向 React/Next.js 的 45 条性能优化规则按影响程度分为 8 个类别并在编写、评审或重构 React 组件、Next.js 页面、数据获取逻辑时被触发使用。在这套规范中消除瀑布Eliminating Waterfalls是优先级第 1 的类别影响级别为 CRITICAL规则文件以前缀async-标识。async-parallel的 frontmatter 元数据明确写着impact: CRITICALimpactDescription: 2-10× improvement文档给出的改进幅度估计为 2 到 10 倍tags: async, parallelization, promises, waterfalls同一规则在技能目录的完整汇编文档 AGENTS.md 第 1.4 节Promise.all() for Independent Operations中有更完整的展开与规则文件内容一致。核心规则顺序 await 对比 Promise.all() 并行规则正文的核心陈述只有一句话当异步操作之间不存在相互依赖时使用Promise.all()让它们并发执行。错误写法顺序执行3 次往返const user await fetchUser() const posts await fetchPosts() const comments await fetchComments()正确写法并行执行1 次往返const [user, posts, comments] await Promise.all([ fetchUser(), fetchPosts(), fetchComments() ])两种写法的语义差异可以这样理解顺序await执行流在第一个await处挂起直到fetchUser()完成才开始发起fetchPosts()三次请求首尾相接总耗时约等于三者之和3 个 round trip。这正是规则所说的瀑布——每个await都叠加了一整段网络延迟。Promise.all()三个 fetch 函数在遇到await之前就被同步调用三个 Promise 几乎同时开始Promise.all只是等待其中最慢的一个。总耗时约等于三者中的最大值1 个 round trip。请求数量越多、单次延迟越高收益越大——这也是文档标注 2-10× 改进幅度的直观来源。使用前提与注意点适用于任何 JavaScript/TypeScript 环境确认操作之间无依赖。如果fetchComments()需要posts返回的 id 作为入参就不能直接放进同一个Promise.all——那种部分依赖场景应使用配套的async-dependencies规则依赖感知的并行化参见 async-dependencies.md。失败语义是 fail-fast。Promise.all中任意一个 Promise 拒绝整体立即拒绝。若业务上需要部分成功比如 3 个接口挂了 1 个仍要渲染其余部分可考虑Promise.allSettled或逐分支catch这属于规则未覆盖的通用 JS 语义按需取舍。返回值按输入数组顺序对齐。解构const [user, posts, comments]的顺序与传入数组的顺序严格对应与谁先完成无关。案例一Next.js 服务端组件中的数据并行预热Marketplace 首页AutoGPT Platform 前端Next.js App Router在 marketplace/page.tsx/marketplace/page.tsx#L53-L97) 中完整实践了这条规则。该页面在服务端组件里通过 TanStack Query 生成的 prefetch 函数将三个独立的 Store 数据请求放入同一个Promise.all并发执行export default async function MarketplacePage(): PromiseReact.ReactElement { const queryClient getQueryClient(); // Prefetch all data on server with proper caching await Promise.all([ prefetchGetV2ListStoreAgentsQuery( queryClient, { featured: true }, { query: { staleTime: 60 * 1000, gcTime: 5 * 60 * 1000 } }, ), prefetchGetV2ListStoreAgentsQuery( queryClient, { sorted_by: runs, page_size: 1000 }, { query: { staleTime: 60 * 1000, gcTime: 5 * 60 * 1000 } }, ), prefetchGetV2ListStoreCreatorsQuery( queryClient, { featured: true, sorted_by: num_agents }, { query: { staleTime: 60 * 1000, gcTime: 5 * 60 * 1000 } }, ), ]); return ( HydrationBoundary state{dehydrate(queryClient)} Suspense fallback{MainMarketplacePageLoading /} MainMarkeplacePage / /Suspense /HydrationBoundary ); }这个案例体现了规则的几个落地细节三个请求精选 Agents、按运行数排序的 Agents、精选 Creators相互独立任何一者的响应都不影响另一者的发起是典型的无互依赖场景服务端并发完成后通过dehydrate(queryClient)把结果脱水注入HydrationBoundary客户端组件复用同一份缓存避免水合后再发起重复请求每个 prefetch 单独配置了staleTime: 60s、gcTime: 5min控制缓存新鲜度。页面还导出了dynamic force-dynamic表明数据不走静态缓存而是每次请求时并行拉取——并行化收益因此每次都会被用到。Marketplace 的 Agent 详情页 agent/[creator]/[slug]/page.tsx 采用了相同结构await Promise.all([...])同时预取当前 Agent 详情、该创作者的 Agent 列表、基于 slug 的搜索结果三个查询仅当详情返回 200 且用户已登录时才在并行块之外追加发起一次按 Store id 取 Agent的预取——后一步依赖前一步的active_version_id恰好说明了有依赖的请求不进同一个 Promise.all的边界判断。案例二客户端事件后的并行缓存失效useProcessReviews规则不仅适用于取数据也适用于任何一组无依赖的异步操作。useProcessReviews.ts 中的processReviews在处理完人工审核process review请求后需要同时刷新待审核列表缓存和多个按执行 id 划分的子列表缓存async function processReviews(items: ReviewItem[], graphExecIds: string[]) { try { return await mutateAsync({ data: { reviews: items } }); } finally { // Awaited so callers can keep a row locked until the refetch settles; // firing and forgetting leaves React Query serving the just-acted-on // review for the whole GET. await Promise.all([ queryClient.invalidateQueries({ queryKey: getGetV2GetPendingReviewsQueryKey(), }), ...[...new Set(graphExecIds)].map((graphExecId) queryClient.invalidateQueries({ queryKey: getGetV2GetPendingReviewsForExecutionQueryKey(graphExecId), }), ), ]); onSettled?.(); } }这里Promise.all等待的是 N 个invalidateQueries触发的重取完成。源码注释解释了对齐规则的原因调用方需要锁定该行直到 refetch 落定fire-and-forget 会让 React Query 在整个 GET 周期内继续返回刚处理过的那条审核项。可以看到并行化不只是提速手段也是保证所有异步副作用全部落定后再继续的语义工具——若改为循环内逐个await总耗时将随执行数量线性增长。案例三并发受限的并行worker 池变体Promise.all的适用前提是可以一次性发起所有请求。当任务数量大、需要限制同时进行的请求数避免压垮后端或触发限流时AutoGPT 的 download-outputs.ts 给出了一个通用变体——基于 worker 池的fetchInParallelasync function fetchInParallelT( tasks: (() PromiseT)[], concurrency: number, ): PromiseT[] { const results: T[] []; let index 0; async function worker() { while (index tasks.length) { const i index; results[i] await tasks[i](); } } await Promise.all( Array.from({ length: Math.min(concurrency, tasks.length) }, () worker()), ); return results; }结构拆解启动Math.min(concurrency, tasks.length)个 worker每个 worker 循环地从共享游标index领取下一个任务并await完成后继续领取Promise.all在这里只负责等待所有 worker 全部空闲。相比直接Promise.all(tasks.map(...))并发度被钳制在concurrency个以内而结果数组仍按任务原始下标results[i]对齐不会因完成顺序不同而错位。仓库中其他位置也存在大量Promise.all的常规用法如 useBrainDumpRecorder.ts/onboarding/steps/BrainDumpStep/useBrainDumpRecorder.ts#L238)、credentials-provider.tsx、playwright/utils/auth.ts 中按 worker 数量扇出并发任务模式与规则一致。规则边界它与同族规则如何分工async-parallel是消除瀑布类别中最基础的一条实际使用时建议对照同目录下的相邻规则选择正确工具均为 rules/ 下的规则文件场景应选用的规则文件操作之间完全独立async-parallel本文主题async-parallel.md操作存在部分依赖B 需要 A 的结果C 独立async-dependencies使用better-all让每个任务尽早启动async-dependencies.md在条件分支中await了未必用到的数据async-defer-await把 await 移到真正使用的分支async-defer-await.mdAPI Route / Server Action 中希望尽早发起、尽量晚 awaitasync-api-routesasync-api-routes.md用组件树结构天然并行化 Server Components 的取数server-parallel-fetchingserver-parallel-fetching.md例如async-defer-await.md 指出若skipProcessing为真时代码根本用不到userData先await fetchUserData再做分支判断仍会白白阻塞两个分支正确做法是把await移到真正需要它的分支内。这条规则与async-parallel互补——前者减少不需要的等待后者压缩必要等待的叠加。自检清单在评审或编写 AutoGPT Platform 前端以及同类 Next.js 项目中的异步代码时可以用以下清单快速验证这段代码里连续出现了几次await 独立请求它们之间是否真的存在数据依赖若无依赖改为Promise.all([...])若某个请求的入参来自另一个请求的响应不要硬塞进同一个Promise.all评估better-allasync-dependencies或先发起无依赖项、拿到中间结果后再并行剩余项的写法async-api-routes并行块之后是否依赖所有操作都已完成的语义如缓存失效、写操作收尾await Promise.all正是提供这种 all-settled 语义的标准手段任务量大时是否需要限制并发度参考fetchInParallel的 worker 池写法而不是无条件全量扇出。综上async-parallel这条 CRITICAL 级规则的本质是把依次等待改造成同时发起、一次性收口。在 AutoGPT Platform 的 Marketplace 页面、执行审核流程和输出下载工具中都能找到与规则描述一一对应的真实实现可作为团队内落地该模式的可查证参照。【免费下载链接】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），仅供参考