可观测性AI 评测LLMOpsAI 应用人工智能【免费下载链接】phoenixAI Observability Evaluation项目地址https://gitcode.com/gh_mirrors/phoenix13/phoenix点击查看免费下载导读在 React / Next.js 应用中请求瀑布流Waterfall是最常见的性能杀手每次await都会引入一次完整的网络往返延迟串行依赖链越长页面耗时越高。本文聚焦 Phoenix 仓库中 .agents/skills/vercel-react-best-practices 技能集内编号规则 async-dependencies.md 所讲解的基于依赖的并行化Dependency-Based Parallelization方案从问题成因、better-all解法、无第三方依赖的原生替代写法到相邻规则的配合带你彻底掌握部分依赖场景下的最大并行化技术让耗时从串行累加降为最长链路实测收益可达 2–10 倍该数据来自规则元数据impactDescription。一、规则定位为什么它属于 CRITICAL 级别在 .agents/skills/vercel-react-best-practices 技能集中规则按 8 大类别组织其中第一节 Eliminating Waterfalls前缀async-被标为CRITICAL最高优先级。根据 _sections.md 的说明Waterfalls are the #1 performance killer. Each sequential await adds full network latency. Eliminating them yields the largest gains.瀑布流是第一号性能杀手每次串行await都会累加完整的网络延迟消除它们带来的收益最大。async-dependencies正是这一类别中的关键规则之一其在 SKILL.md 的 Quick Reference 中位列 Eliminating Waterfalls 第 4 条元数据标注为title: Dependency-Based Parallelization impact: CRITICAL impactDescription: 2-10× improvement tags: async, parallelization, dependencies, better-all同一章节还包含 5 条配套规则async-parallel、async-api-routes、async-suspense-boundaries、async-defer-await、async-cheap-condition-before-await它们共同构成一套完整的消除瀑布流方法论——本文所讲的依赖并行化是其中针对操作之间存在部分依赖这一最复杂场景的解法。二、问题场景部分依赖操作如何悄悄形成瀑布流当多个异步操作之间存在部分依赖时例如获取配置和获取用户互相独立但获取个人资料依赖用户 ID最常见的写法是const [user, config] await Promise.all([ fetchUser(), fetchConfig() ]) const profile await fetchProfile(user.id)这段代码有两个问题Promise.all只保证了fetchUser与fetchConfig并发但fetchProfile必须等fetchUser完全 resolve 之后才开始形成第二段串行等待更严重的是fetchConfig与fetchProfile之间没有任何依赖关系——fetchProfile只依赖user.id却被迫等待config也一起返回白白多等一次网络往返。最终时间线为max(fetchUser, fetchConfig) fetchProfile其中fetchConfig的耗时被浪费地串行进了第二段。配置越慢资料页就越慢。三、解法一使用 better-all 实现依赖感知的自动并行针对上述场景规则推荐的正确写法是使用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({...})对象中的一个方法任务之间通过this.$.任务名声明依赖。从示例代码可以直观看到该 API 的两个关键行为尽早启动earliest possible moment规则原文明确说明 It automatically starts each task at the earliest possible moment即user与config在调用时立即并行启动互不等待依赖就绪即运行profile任务内部通过await this.$.user取得user任务的解析结果取.id后传给fetchProfile框架自动保证依赖关系同时不会因为config未完成而阻塞profile。于是时间线变为max(fetchUser, fetchConfig, fetchProfile)——三个任务在依赖允许的前提下全部并发总耗时收敛为最长单链而不是串行累加。这正是规则标题基于依赖的并行化的含义并行度由依赖图驱动而非由代码书写顺序驱动。注better-all是一个独立发布在 npm 上的第三方工具库由 Vercel 工程师 shuding 维护原规则文件的 Reference 字段指向其 GitHub 仓库。本文不展开其内部实现仅依据规则示例还原其公开 API 用法。四、解法二零依赖的 Promise 先行写法如果项目不希望引入额外依赖规则给出了完全等价的原生写法先把所有 Promise 创建出来fetchUser()一旦被调用请求就已发出再用then串起依赖关系最后统一Promise.allconst userPromise fetchUser() const profilePromise userPromise.then(user fetchProfile(user.id)) const [user, config, profile] await Promise.all([ userPromise, fetchConfig(), profilePromise ])这段代码的精妙之处在于第 1 行fetchUser()立即执行——请求在赋值给userPromise的瞬间就已发出而不是在await时才发出第 2 行通过userPromise.then(...)声明依赖——profilePromise会在userPromise兑现后自动开始与fetchConfig()并行第 4–8 行Promise.all只负责汇合由于三个 Promise 都已提前启动config与profile天然并发。该方案与better-all达到相同的并行效果时间线同为max(...)代价是需要手动编排then链。这正是规则提供的无额外依赖回退路径适合依赖受控或禁止引入第三方库的工程环境。五、原生方案 vs better-all如何选择对比维度原生 Promise 先行写法better-all额外依赖无纯语言特性需安装better-all依赖声明方式手动promise.then(...)链式编排对象方法 this.$.任务名声明式声明依赖图复杂度简单 1–2 层依赖尚可维护深层依赖时代码易嵌套任意复杂依赖图均自动调度可读性依赖越深越难读每个任务自包含依赖就地可见适用场景少量任务、单层依赖复杂依赖链、任务数量多的场景从 async-api-routes.md 的结尾注释可以印证技能集的取向For operations with more complex dependency chains, usebetter-allto automatically maximize parallelism (see Dependency-Based Parallelization)——即简单场景用原生写法复杂依赖链交给better-all自动调度。六、与相邻规则的组合构建完整的瀑布流消除体系async-dependencies不是孤立的一招它在技能集中与以下规则形成互补覆盖从完全独立到部分依赖再到条件分支的全部场景async-parallel.mdPromise.all() for Independent Operations当操作完全无依赖时直接Promise.all把 3 次串行往返压缩为 1 次。这是最基础的规则也是本规则的前置知识。async-api-routes.mdPrevent Waterfall Chains in API Routes在 API Route 与 Server Action 中把const config await fetchConfig()改写为const configPromise fetchConfig()让独立请求在鉴权的同时先行启动——与本文先创建 Promise 再汇合的思路同源。async-defer-await.mdDefer Await Until Needed把await移入真正使用它的分支避免阻塞不需要该数据的分支。async-cheap-condition-before-await.md当await getFlag()与一个廉价的同步条件如flag someCondition组合时先判同步条件再决定是否发起异步请求——该规则文档明确自称是async-defer-await的特化同样服务于少做异步工作。async-suspense-boundaries.mdStrategic Suspense Boundaries在组件层用Suspense代替整体await让布局先渲染、数据流式到达并可通过共享 Promise 让多个组件只发起一次请求。实践建议先按async-parallel处理完全独立的操作再按async-dependencies处理部分依赖的操作最后用async-defer-await/async-cheap-condition-before-await剔除分支中根本不需要的异步开销——三者组合即可覆盖绝大多数数据加载场景。七、规则文件结构为什么每条规则都带坏例/好例作为技能集的组成部分async-dependencies.md 遵循 _template.md 定义的统一模板frontmattertitle / impact / impactDescription / tags 规则说明 Incorrect 坏例 Correct 好例 Reference。这种先展示反模式、再给出正解的结构是专门为Agent 与 LLM 自动重构代码设计的——metadata.json 的摘要明确指出该技能集面向 AI Agent 与 LLM每条规则附带的对比示例用于指导自动化重构与代码生成guide automated refactoring and code generation。因此在 Phoenix 仓库中使用本技能生成或审查代码时async-dependencies这类规则会作为显式约束注入提示词确保产出代码不会退化为串行瀑布流。八、小结基于依赖的并行化解决的是数据加载中最棘手的部分依赖场景用better-all的all({...})this.$.任务名声明式描述依赖图或退而求其次用先建 Promise、then串链、最后Promise.all的原生写法都可以把max(A,B) C型的串行时间线压缩为max(A,B,C)型的最长链路。结合 async-parallel、async-api-routes、async-defer-await 等相邻规则即可系统性地消灭 React / Next.js 应用中的请求瀑布流获得规则元数据所标注的 2–10× 耗时改善。赞分享可观测性AI 评测LLMOpsAI 应用人工智能【免费下载链接】phoenixAI Observability Evaluation项目地址https://gitcode.com/gh_mirrors/phoenix13/phoenix点击查看免费下载相关推荐Sanity 仓库 Vercel React 最佳实践基于依赖的并行化async-dependencies与 better-all 实践Sanity 仓库 Vercel React 最佳实践基于依赖的并行化async dependencies与 better all 实践 本篇技术文章解析CMS前端OpenMontage 依赖并行化实践用 better-all 消除 React/Next.js 串行瀑布请求OpenMontage 依赖并行化实践用 better all 消除 React/Next.js 串行瀑布请求 本篇文章围绕 OpenMontage 仓库中人工智能AI Agent音视频媒体生成工作流自动化消除 API Routes 瀑布式请求链cherry-studio 中的 Vercel 异步并行化最佳实践消除 API Routes 瀑布式请求链cherry studio 中的 Vercel 异步并行化最佳实践 在 API Routes 与 Server ActAI 应用大模型桌面应用本地部署RAG创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/23 10:42:49 · 阅读 1.2k Phoenix 仓库 Vercel React 最佳实践解析：基于依赖的并行化（async-dependencies）消除请求瀑布流
可观测性AI 评测LLMOpsAI 应用人工智能【免费下载链接】phoenixAI Observability Evaluation项目地址https://gitcode.com/gh_mirrors/phoenix13/phoenix点击查看免费下载导读在 React / Next.js 应用中请求瀑布流Waterfall是最常见的性能杀手每次await都会引入一次完整的网络往返延迟串行依赖链越长页面耗时越高。本文聚焦 Phoenix 仓库中 .agents/skills/vercel-react-best-practices 技能集内编号规则 async-dependencies.md 所讲解的基于依赖的并行化Dependency-Based Parallelization方案从问题成因、better-all解法、无第三方依赖的原生替代写法到相邻规则的配合带你彻底掌握部分依赖场景下的最大并行化技术让耗时从串行累加降为最长链路实测收益可达 2–10 倍该数据来自规则元数据impactDescription。一、规则定位为什么它属于 CRITICAL 级别在 .agents/skills/vercel-react-best-practices 技能集中规则按 8 大类别组织其中第一节 Eliminating Waterfalls前缀async-被标为CRITICAL最高优先级。根据 _sections.md 的说明Waterfalls are the #1 performance killer. Each sequential await adds full network latency. Eliminating them yields the largest gains.瀑布流是第一号性能杀手每次串行await都会累加完整的网络延迟消除它们带来的收益最大。async-dependencies正是这一类别中的关键规则之一其在 SKILL.md 的 Quick Reference 中位列 Eliminating Waterfalls 第 4 条元数据标注为title: Dependency-Based Parallelization impact: CRITICAL impactDescription: 2-10× improvement tags: async, parallelization, dependencies, better-all同一章节还包含 5 条配套规则async-parallel、async-api-routes、async-suspense-boundaries、async-defer-await、async-cheap-condition-before-await它们共同构成一套完整的消除瀑布流方法论——本文所讲的依赖并行化是其中针对操作之间存在部分依赖这一最复杂场景的解法。二、问题场景部分依赖操作如何悄悄形成瀑布流当多个异步操作之间存在部分依赖时例如获取配置和获取用户互相独立但获取个人资料依赖用户 ID最常见的写法是const [user, config] await Promise.all([ fetchUser(), fetchConfig() ]) const profile await fetchProfile(user.id)这段代码有两个问题Promise.all只保证了fetchUser与fetchConfig并发但fetchProfile必须等fetchUser完全 resolve 之后才开始形成第二段串行等待更严重的是fetchConfig与fetchProfile之间没有任何依赖关系——fetchProfile只依赖user.id却被迫等待config也一起返回白白多等一次网络往返。最终时间线为max(fetchUser, fetchConfig) fetchProfile其中fetchConfig的耗时被浪费地串行进了第二段。配置越慢资料页就越慢。三、解法一使用 better-all 实现依赖感知的自动并行针对上述场景规则推荐的正确写法是使用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({...})对象中的一个方法任务之间通过this.$.任务名声明依赖。从示例代码可以直观看到该 API 的两个关键行为尽早启动earliest possible moment规则原文明确说明 It automatically starts each task at the earliest possible moment即user与config在调用时立即并行启动互不等待依赖就绪即运行profile任务内部通过await this.$.user取得user任务的解析结果取.id后传给fetchProfile框架自动保证依赖关系同时不会因为config未完成而阻塞profile。于是时间线变为max(fetchUser, fetchConfig, fetchProfile)——三个任务在依赖允许的前提下全部并发总耗时收敛为最长单链而不是串行累加。这正是规则标题基于依赖的并行化的含义并行度由依赖图驱动而非由代码书写顺序驱动。注better-all是一个独立发布在 npm 上的第三方工具库由 Vercel 工程师 shuding 维护原规则文件的 Reference 字段指向其 GitHub 仓库。本文不展开其内部实现仅依据规则示例还原其公开 API 用法。四、解法二零依赖的 Promise 先行写法如果项目不希望引入额外依赖规则给出了完全等价的原生写法先把所有 Promise 创建出来fetchUser()一旦被调用请求就已发出再用then串起依赖关系最后统一Promise.allconst userPromise fetchUser() const profilePromise userPromise.then(user fetchProfile(user.id)) const [user, config, profile] await Promise.all([ userPromise, fetchConfig(), profilePromise ])这段代码的精妙之处在于第 1 行fetchUser()立即执行——请求在赋值给userPromise的瞬间就已发出而不是在await时才发出第 2 行通过userPromise.then(...)声明依赖——profilePromise会在userPromise兑现后自动开始与fetchConfig()并行第 4–8 行Promise.all只负责汇合由于三个 Promise 都已提前启动config与profile天然并发。该方案与better-all达到相同的并行效果时间线同为max(...)代价是需要手动编排then链。这正是规则提供的无额外依赖回退路径适合依赖受控或禁止引入第三方库的工程环境。五、原生方案 vs better-all如何选择对比维度原生 Promise 先行写法better-all额外依赖无纯语言特性需安装better-all依赖声明方式手动promise.then(...)链式编排对象方法 this.$.任务名声明式声明依赖图复杂度简单 1–2 层依赖尚可维护深层依赖时代码易嵌套任意复杂依赖图均自动调度可读性依赖越深越难读每个任务自包含依赖就地可见适用场景少量任务、单层依赖复杂依赖链、任务数量多的场景从 async-api-routes.md 的结尾注释可以印证技能集的取向For operations with more complex dependency chains, usebetter-allto automatically maximize parallelism (see Dependency-Based Parallelization)——即简单场景用原生写法复杂依赖链交给better-all自动调度。六、与相邻规则的组合构建完整的瀑布流消除体系async-dependencies不是孤立的一招它在技能集中与以下规则形成互补覆盖从完全独立到部分依赖再到条件分支的全部场景async-parallel.mdPromise.all() for Independent Operations当操作完全无依赖时直接Promise.all把 3 次串行往返压缩为 1 次。这是最基础的规则也是本规则的前置知识。async-api-routes.mdPrevent Waterfall Chains in API Routes在 API Route 与 Server Action 中把const config await fetchConfig()改写为const configPromise fetchConfig()让独立请求在鉴权的同时先行启动——与本文先创建 Promise 再汇合的思路同源。async-defer-await.mdDefer Await Until Needed把await移入真正使用它的分支避免阻塞不需要该数据的分支。async-cheap-condition-before-await.md当await getFlag()与一个廉价的同步条件如flag someCondition组合时先判同步条件再决定是否发起异步请求——该规则文档明确自称是async-defer-await的特化同样服务于少做异步工作。async-suspense-boundaries.mdStrategic Suspense Boundaries在组件层用Suspense代替整体await让布局先渲染、数据流式到达并可通过共享 Promise 让多个组件只发起一次请求。实践建议先按async-parallel处理完全独立的操作再按async-dependencies处理部分依赖的操作最后用async-defer-await/async-cheap-condition-before-await剔除分支中根本不需要的异步开销——三者组合即可覆盖绝大多数数据加载场景。七、规则文件结构为什么每条规则都带坏例/好例作为技能集的组成部分async-dependencies.md 遵循 _template.md 定义的统一模板frontmattertitle / impact / impactDescription / tags 规则说明 Incorrect 坏例 Correct 好例 Reference。这种先展示反模式、再给出正解的结构是专门为Agent 与 LLM 自动重构代码设计的——metadata.json 的摘要明确指出该技能集面向 AI Agent 与 LLM每条规则附带的对比示例用于指导自动化重构与代码生成guide automated refactoring and code generation。因此在 Phoenix 仓库中使用本技能生成或审查代码时async-dependencies这类规则会作为显式约束注入提示词确保产出代码不会退化为串行瀑布流。八、小结基于依赖的并行化解决的是数据加载中最棘手的部分依赖场景用better-all的all({...})this.$.任务名声明式描述依赖图或退而求其次用先建 Promise、then串链、最后Promise.all的原生写法都可以把max(A,B) C型的串行时间线压缩为max(A,B,C)型的最长链路。结合 async-parallel、async-api-routes、async-defer-await 等相邻规则即可系统性地消灭 React / Next.js 应用中的请求瀑布流获得规则元数据所标注的 2–10× 耗时改善。赞分享可观测性AI 评测LLMOpsAI 应用人工智能【免费下载链接】phoenixAI Observability Evaluation项目地址https://gitcode.com/gh_mirrors/phoenix13/phoenix点击查看免费下载相关推荐Sanity 仓库 Vercel React 最佳实践基于依赖的并行化async-dependencies与 better-all 实践Sanity 仓库 Vercel React 最佳实践基于依赖的并行化async dependencies与 better all 实践 本篇技术文章解析CMS前端OpenMontage 依赖并行化实践用 better-all 消除 React/Next.js 串行瀑布请求OpenMontage 依赖并行化实践用 better all 消除 React/Next.js 串行瀑布请求 本篇文章围绕 OpenMontage 仓库中人工智能AI Agent音视频媒体生成工作流自动化消除 API Routes 瀑布式请求链cherry-studio 中的 Vercel 异步并行化最佳实践消除 API Routes 瀑布式请求链cherry studio 中的 Vercel 异步并行化最佳实践 在 API Routes 与 Server ActAI 应用大模型桌面应用本地部署RAG创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考