尧图网站建设 
可观测性AI 评测LLMOpsAI 应用人工智能【免费下载链接】phoenixAI Observability Evaluation项目地址https://gitcode.com/gh_mirrors/phoenix13/phoenix点击查看免费下载本文围绕当前仓库.agents/skills/vercel-react-best-practices技能目录中的规则模板rules/_template.md展开系统讲解 Vercel Engineering 维护的 React / Next.js 性能优化规则体系从模板字段语义、8 大优化类别与影响等级到规则文件的命名、构建与校验工作流并结合仓库内已落地的数十条规则实例给出可直接复用的编写范式。读完本文你将掌握如何为 React / Next.js 性能优化知识库新增一条结构化、可被 Agent 检索与引用的规则并理解规则模板背后的性能工程方法论。规则体系全景8 大类别与优先级排序在深入模板之前先理解这套规则体系的结构骨架。技能目录的核心索引文件 SKILL.md 声明这是一份由 Vercel 维护、面向 Agent 与 LLM 优化的 React / Next.js 性能优化指南共包含 70 条规则按影响程度impact优先级排列用于指导自动化重构与代码生成。类别元数据定义在 rules/_sections.md 中每个类别对应一个文件名前缀Prefix规则文件即通过该前缀归组。优先级类别影响等级文件名前缀1Eliminating Waterfalls消除瀑布请求CRITICALasync-2Bundle Size Optimization包体积优化CRITICALbundle-3Server-Side Performance服务端性能HIGHserver-4Client-Side Data Fetching客户端数据获取MEDIUM-HIGHclient-5Re-render Optimization重渲染优化MEDIUMrerender-6Rendering Performance渲染性能MEDIUMrendering-7JavaScript PerformanceJavaScript 性能LOW-MEDIUMjs-8Advanced Patterns高级模式LOWadvanced-分类逻辑体现了性能优化的收益排序_sections.md明确指出waterfall串行请求瀑布是头号性能杀手每一次顺序await都会累加完整的网络延迟因此消除瀑布被列为第 1 优先级CRITICAL其次是通过减小初始包体积来改善 TTITime to Interactive与 LCPLargest Contentful Paint服务端渲染与数据获取优化能消除服务端瀑布并缩短响应时间再往后是客户端请求去重、减少不必要的重渲染、降低浏览器渲染工作量、JavaScript 热路径微优化最后才是针对特定场景、需要谨慎实现的高级模式。从仓库实际规则文件看8 个前缀均已落地例如async-parallel.md、bundle-dynamic-imports.md、server-cache-react.md、client-swr-dedup.md、rerender-memo.md、rendering-content-visibility.md、js-hoist-regexp.md、advanced-use-latest.md等可见该模板是支撑 70 条规则量产的结构化约定。规则模板逐字段解析规则模板 本身是一份规则的规则定义了每条规则文件的标准结构。整体分为两部分YAML frontmatter 元数据段与 Markdown 正文段。frontmatter 元数据机器可读的规则索引模板开头的 YAML frontmatter 是 Agent 与 LLM 检索规则的核心索引共 4 个字段--- title: Rule Title Here impact: MEDIUM impactDescription: Optional description of impact (e.g., 20-50% improvement) tags: tag1, tag2 ---title规则标题描述本条规则的动作如Promise.all() for Independent Operations、Avoid Barrel File Imports。impact影响等级。README 定义了六级体系CRITICAL最高优先级、收益巨大、HIGH显著提升、MEDIUM-HIGH中高收益、MEDIUM中等收益、LOW-MEDIUM中低收益、LOW增量改进。这是规则排序与 Agent 决策的依据。impactDescription可选的量化描述说明收益的量级。例如 async-parallel.md 标注2-10× improvementbundle-barrel-imports.md 标注200-800ms import cost, slow builds。这类量化描述让 Agent 能根据收益大小决定重构优先级。tags逗号分隔的标签列表用于跨类别检索。观察仓库中的真实规则标签设计为领域词 技术词的组合如async, parallelization, promises, waterfalls、bundle, imports, tree-shaking, barrel-files, performance、regexp, optimization, memoization这能显著提升语义检索的命中率。正文结构Bad / Good 示例驱动的规则说明正文同样有固定骨架二级标题、Impact 声明、规则解释、**Incorrect**错误示例、**Correct**正确示例、以及可选的补充说明与 Reference。## Rule Title Here **Impact: MEDIUM (optional impact description)** Brief explanation of the rule and why it matters... **Incorrect (description of whats wrong):** typescript // Bad code example hereCorrect (description of whats right):// Good code example hereReference: Link to documentation or resource各要素的作用 - **规则解释**用简明语言说明做什么与为什么重要并给出性能影响。这是模板中最强调clear and concise的部分——规则面向 Agent 自动重构解释必须让 LLM 无需阅读上下文即可理解适用条件。 - **Incorrect / Correct 对比**模板要求每条规则必须同时给出错误与正确两种代码示例且示例须可运行、贴近真实场景。从仓库规则看示例都配了简短注释说明问题与代价例如 // Loads 1,583 modules, takes ~2.8s extra in dev。这种反面教材 正面教材的对照结构是整份指南的核心方法论它让 Agent 既能识别坏模式又能直接套用修复后的写法。 - **Reference**可选的资料引用指向官方文档或博客为规则提供权威依据。 ## 规则文件命名与构建工作流 模板是单一规则文件的格式约定而整套体系还配套了文件命名规范与自动化构建流程定义在 [README.md](https://link.gitcode.com/i/072839166db20f67c8b7ede061edddb8) 中。 ### 命名约定 - 以下划线 _ 开头的文件是特殊文件不参与构建_template.md 与 _sections.md 即属于此类 - 规则文件按 area-description.md 模式命名如 async-parallel.md其中 async- 是类别前缀 - 规则所属类别由文件名前缀自动推断构建时按标题字母序在各自类别内排序并为每条规则自动生成 ID如 1.1、1.2——因此**作者无需手动管理编号**这降低了维护成本并保证一致性。 ### 新增一条规则的完整流程 1. 复制 rules/_template.md 为 rules/area-description.md 2. 从 8 个前缀中选择与规则内容匹配的类别前缀 3. 填写 frontmatter 与正文确保包含清晰的错误/正确示例及解释 4. 运行 pnpm build 重新生成编译产物 AGENTS.md 与 test-cases.json。 配套脚本定义于 README还包括 - pnpm validate校验所有规则文件格式是否合规 - pnpm extract-tests从规则中抽取测试用例用于 LLM 评估 - pnpm dev构建并校验的组合命令。 这套工作流的意义在于规则不是散落的 Markdown而是通过构建脚本汇聚成一份编译后的完整指南即 AGENTS.md并抽出可供 LLM 评测的测试集形成编写 → 校验 → 编译 → 评估的闭环。 ## 实战规则示例从模板到落地 以下选取仓库中覆盖不同类别与影响等级的规则实例展示模板如何在真实场景中展开。这些文件均位于 [rules](https://link.gitcode.com/i/12da5c3ef9b996bd24cda5eadab42ba2) 目录下。 ### 示例一async-parallelCRITICAL消除瀑布 [async-parallel.md](https://link.gitcode.com/i/03c5ffac58859229b5e570ace359ccd3) 展示了最基本的瀑布消除当多个异步操作彼此独立时应使用 Promise.all() 并发执行。 **Incorrect顺序执行3 次网络往返** typescript const user await fetchUser() const posts await fetchPosts() const comments await fetchComments()Correct并行执行1 次往返const [user, posts, comments] await Promise.all([ fetchUser(), fetchPosts(), fetchComments() ])impactDescription标注的2-10×提升量级来自网络延迟被合并为单次往返这一事实——这正是_sections.md中每个顺序 await 累加完整网络延迟的直接体现。示例二async-cheap-condition-before-awaitHIGH短路守卫前置async-cheap-condition-before-await.md 是flag cheapCondition型判断的专项优化当分支同时依赖异步标志位与廉价的同步条件时应先求值同步条件避免在条件必然不成立时仍发起网络请求、特性开关查询或React.cache()/ 数据库调用。Incorrectconst someFlag await getFlag() if (someFlag someCondition) { // ... }Correctif (someCondition) { const someFlag await getFlag() if (someFlag) { // ... } }该规则同时给出了适用边界若someCondition本身昂贵、依赖标志位结果或必须按固定顺序执行副作用则应保持原始顺序——这体现了规则模板对适用前提与限制的重视避免 Agent 盲目套用。示例三bundle-barrel-importsCRITICAL包体积优化bundle-barrel-imports.md 针对桶文件barrel file即通过export * from ./module聚合导出的入口文件问题流行图标与组件库的入口文件可能包含多达上万个 re-export许多 React 包仅 import 就需要200-800ms同时拖慢开发启动与生产冷启动。文档还解释了 tree-shaking 在此场景失效的原因——当库被标记为 external不打包时bundler 无法优化它而为了启用 tree-shaking 将其打入 bundle又会让构建因分析整个模块图而显著变慢。该规则给出了两条修复路径方案一Next.js 13.5 推荐构建期自动优化桶导入// next.config.js module.exports { experimental: { optimizePackageImports: [lucide-react, mui/material] } }// 保持标准导入Next.js 会在构建时将其改写为直接导入 import { Check, X, Menu } from lucide-react该方案的优势是保留 TypeScript 类型安全与编辑器自动补全同时消除桶导入成本。方案二非 Next.js 项目直接深层导入import Button from mui/material/Button import TextField from mui/material/TextField // 只加载实际使用到的模块规则还给出了 TypeScript 陷阱提示部分库如lucide-react不为深层导入路径提供.d.ts类型声明在strict/noImplicitAny下会退化为隐式any因此应优先使用optimizePackageImports或先确认库为其子路径导出类型。这种方案 坑位预警的结构正是模板Correct 示例 补充说明的延伸。示例四server-cache-reactMEDIUM请求内去重server-cache-react.md 讲解用React.cache()在服务端单次请求内做去重收益最大的场景是认证与数据库查询import { cache } from react export const getCurrentUser cache(async () { const session await auth() if (!session?.user?.id) return null return await db.user.findUnique({ where: { id: session.user.id } }) })同一请求内多次调用getCurrentUser()只会真正执行一次查询。规则特别提醒了一个反直觉的坑React.cache()使用浅比较Object.is判断缓存命中内联对象每次调用都会创建新引用导致永久缓存失效应改用原始类型参数或复用同一对象引用// 错误每次调用创建新对象永不命中缓存 getUser({ uid: 1 }) getUser({ uid: 1 }) // 缓存未命中再次执行查询 // 正确原始类型按值相等命中 getUser(1) getUser(1) // 缓存命中 // 若必须传对象请复用同一引用 const params { uid: 1 } getUser(params) getUser(params) // 同一引用缓存命中规则还划清了与 Next.js 内建能力的边界Next.js 已为fetch自动扩展请求记忆化同 URL 同参数的请求在单次请求内自动去重因此React.cache()主要用于数据库查询、重型计算、认证检查、文件系统操作等非fetch的异步任务。示例五rerender-memoMEDIUM重渲染优化rerender-memo.md 展示了提取为 memoized 组件以支持提前返回的模式将昂贵计算拆进独立的memo()组件后父组件可在 loading 状态下直接 return从而跳过子组件内useMemo的计算Incorrectloading 时仍计算头像function Profile({ user, loading }: Props) { const avatar useMemo(() { const id computeAvatarId(user) return Avatar id{id} / }, [user]) if (loading) return Skeleton / return div{avatar}/div }Correctloading 时跳过计算const UserAvatar memo(function UserAvatar({ user }: { user: User }) { const id useMemo(() computeAvatarId(user), [user]) return Avatar id{id} / }) function Profile({ user, loading }: Props) { if (loading) return Skeleton / return ( div UserAvatar user{user} / /div ) }规则末尾特别注明若项目启用了 React Compiler手动memo()/useMemo()不再是必须的编译器会自动优化重渲染。这体现了规则体系对 React 生态演进的追踪。示例六js-hoist-regexpLOW-MEDIUMJS 热路径微优化j s-hoist-regexp.md 属于第 7 类别热路径微优化不要在渲染内创建 RegExp应提升到模块作用域或用useMemo()记忆化function Highlighter({ text, query }: Props) { const regex new RegExp((${query}), gi) // 每次渲染都重建 ... }const EMAIL_REGEX /^[^\s][^\s]\.[^\s]$/ // 静态正则提升到模块级 function Highlighter({ text, query }: Props) { const regex useMemo( () new RegExp((${escapeRegex(query)}), gi), [query] ) ... }规则还附带一个经典陷阱警示带g标志的正则具有可变的lastIndex状态复用全局正则时test()结果会交替变化——这类使用注意事项正是模板鼓励的Additional context。编写高质量规则的最佳实践综合模板、README 与仓库内规则实例可以提炼出面向 Agent / LLM 消费场景的规则编写规范结构即契约严格遵循模板的 frontmatter 正文骨架。frontmatter 保证机器可读正文的**Incorrect**/**Correct**对照保证 LLM 可以识别坏模式、套用好模式。量化影响尽可能在impactDescription中给出量级或成本描述如2-10×、200-800ms、Loads 1,583 modules帮助 Agent 按收益排序重构动作。示例要真实可运行代码示例贴近真实业务用户查询、图标导入、正则高亮等并带注释说明代价避免抽象占位符。标注适用边界如async-cheap-condition-before-await明确何时应保持原顺序、server-cache-react明确何时不需要React.cache()防止 Agent 在不适用的场景误用。追踪生态演进如 React Compiler 的启用会取代手动 memoization、Next.js 对fetch的内建记忆化会取代部分React.cache()用法规则应及时补充这类版本与前提说明。正确归类与命名按 8 大类别选择前缀、按area-description.md命名让构建脚本能自动归组、排序并生成 ID。结语_template.md虽然只是一份十几行的模板文件但它定义了 Vercel React Best Practices 这套 70 条规则体系的生产标准——机器可读的元数据、Bad/Good 对照的正文、量化到毫秒/倍数的收益声明加上命名约定与构建脚本共同构成了一套面向 Agent 与 LLM 的规则即代码工作流。当前仓库已在.agents/skills/vercel-react-best-practices下完整保留了这份体系含 SKILL.md 快速索引、README.md 维护指南、metadata.json 元数据与全部规则文件无论是想为自己的 React / Next.js 项目沉淀性能规范还是希望让 Agent 具备可检索的性能重构能力这套模板与方法论都值得直接借鉴。赞分享可观测性AI 评测LLMOpsAI 应用人工智能【免费下载链接】phoenixAI Observability Evaluation项目地址https://gitcode.com/gh_mirrors/phoenix13/phoenix点击查看免费下载相关推荐Polar 仓库中的 Vercel React 性能优化规则库如何用 _template.md 编写一条可被 Agent 与 LLM 理解执行的性能规则Polar 仓库中的 Vercel React 性能优化规则库如何用 _template.md 编写一条可被 Agent 与 LLM 理解执行的性能规则 导读后端前端金融科技3分钟搞定电子课本批量下载免代码操作存下智慧平台教材PDF3分钟搞定电子课本批量下载免代码操作存下智慧平台教材PDF 上完课想让学生预习你只能在网页里一页页翻找 PDF 入口翻三本教材就过去十分钟。tchMate网页爬虫教育Sanity 仓库内置的 Vercel React 最佳实践面向 AI Agent 的 57 条 React/Next.js 性能优化规则Sanity 仓库内置的 Vercel React 最佳实践面向 AI Agent 的 57 条 React/Next.js 性能优化规则 Sanity 单仓CMS前端创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Vercel React 性能优化规则模板全解：面向 Agent 与 LLM 的高质量规则编写实战
可观测性AI 评测LLMOpsAI 应用人工智能【免费下载链接】phoenixAI Observability Evaluation项目地址https://gitcode.com/gh_mirrors/phoenix13/phoenix点击查看免费下载本文围绕当前仓库.agents/skills/vercel-react-best-practices技能目录中的规则模板rules/_template.md展开系统讲解 Vercel Engineering 维护的 React / Next.js 性能优化规则体系从模板字段语义、8 大优化类别与影响等级到规则文件的命名、构建与校验工作流并结合仓库内已落地的数十条规则实例给出可直接复用的编写范式。读完本文你将掌握如何为 React / Next.js 性能优化知识库新增一条结构化、可被 Agent 检索与引用的规则并理解规则模板背后的性能工程方法论。规则体系全景8 大类别与优先级排序在深入模板之前先理解这套规则体系的结构骨架。技能目录的核心索引文件 SKILL.md 声明这是一份由 Vercel 维护、面向 Agent 与 LLM 优化的 React / Next.js 性能优化指南共包含 70 条规则按影响程度impact优先级排列用于指导自动化重构与代码生成。类别元数据定义在 rules/_sections.md 中每个类别对应一个文件名前缀Prefix规则文件即通过该前缀归组。优先级类别影响等级文件名前缀1Eliminating Waterfalls消除瀑布请求CRITICALasync-2Bundle Size Optimization包体积优化CRITICALbundle-3Server-Side Performance服务端性能HIGHserver-4Client-Side Data Fetching客户端数据获取MEDIUM-HIGHclient-5Re-render Optimization重渲染优化MEDIUMrerender-6Rendering Performance渲染性能MEDIUMrendering-7JavaScript PerformanceJavaScript 性能LOW-MEDIUMjs-8Advanced Patterns高级模式LOWadvanced-分类逻辑体现了性能优化的收益排序_sections.md明确指出waterfall串行请求瀑布是头号性能杀手每一次顺序await都会累加完整的网络延迟因此消除瀑布被列为第 1 优先级CRITICAL其次是通过减小初始包体积来改善 TTITime to Interactive与 LCPLargest Contentful Paint服务端渲染与数据获取优化能消除服务端瀑布并缩短响应时间再往后是客户端请求去重、减少不必要的重渲染、降低浏览器渲染工作量、JavaScript 热路径微优化最后才是针对特定场景、需要谨慎实现的高级模式。从仓库实际规则文件看8 个前缀均已落地例如async-parallel.md、bundle-dynamic-imports.md、server-cache-react.md、client-swr-dedup.md、rerender-memo.md、rendering-content-visibility.md、js-hoist-regexp.md、advanced-use-latest.md等可见该模板是支撑 70 条规则量产的结构化约定。规则模板逐字段解析规则模板 本身是一份规则的规则定义了每条规则文件的标准结构。整体分为两部分YAML frontmatter 元数据段与 Markdown 正文段。frontmatter 元数据机器可读的规则索引模板开头的 YAML frontmatter 是 Agent 与 LLM 检索规则的核心索引共 4 个字段--- title: Rule Title Here impact: MEDIUM impactDescription: Optional description of impact (e.g., 20-50% improvement) tags: tag1, tag2 ---title规则标题描述本条规则的动作如Promise.all() for Independent Operations、Avoid Barrel File Imports。impact影响等级。README 定义了六级体系CRITICAL最高优先级、收益巨大、HIGH显著提升、MEDIUM-HIGH中高收益、MEDIUM中等收益、LOW-MEDIUM中低收益、LOW增量改进。这是规则排序与 Agent 决策的依据。impactDescription可选的量化描述说明收益的量级。例如 async-parallel.md 标注2-10× improvementbundle-barrel-imports.md 标注200-800ms import cost, slow builds。这类量化描述让 Agent 能根据收益大小决定重构优先级。tags逗号分隔的标签列表用于跨类别检索。观察仓库中的真实规则标签设计为领域词 技术词的组合如async, parallelization, promises, waterfalls、bundle, imports, tree-shaking, barrel-files, performance、regexp, optimization, memoization这能显著提升语义检索的命中率。正文结构Bad / Good 示例驱动的规则说明正文同样有固定骨架二级标题、Impact 声明、规则解释、**Incorrect**错误示例、**Correct**正确示例、以及可选的补充说明与 Reference。## Rule Title Here **Impact: MEDIUM (optional impact description)** Brief explanation of the rule and why it matters... **Incorrect (description of whats wrong):** typescript // Bad code example hereCorrect (description of whats right):// Good code example hereReference: Link to documentation or resource各要素的作用 - **规则解释**用简明语言说明做什么与为什么重要并给出性能影响。这是模板中最强调clear and concise的部分——规则面向 Agent 自动重构解释必须让 LLM 无需阅读上下文即可理解适用条件。 - **Incorrect / Correct 对比**模板要求每条规则必须同时给出错误与正确两种代码示例且示例须可运行、贴近真实场景。从仓库规则看示例都配了简短注释说明问题与代价例如 // Loads 1,583 modules, takes ~2.8s extra in dev。这种反面教材 正面教材的对照结构是整份指南的核心方法论它让 Agent 既能识别坏模式又能直接套用修复后的写法。 - **Reference**可选的资料引用指向官方文档或博客为规则提供权威依据。 ## 规则文件命名与构建工作流 模板是单一规则文件的格式约定而整套体系还配套了文件命名规范与自动化构建流程定义在 [README.md](https://link.gitcode.com/i/072839166db20f67c8b7ede061edddb8) 中。 ### 命名约定 - 以下划线 _ 开头的文件是特殊文件不参与构建_template.md 与 _sections.md 即属于此类 - 规则文件按 area-description.md 模式命名如 async-parallel.md其中 async- 是类别前缀 - 规则所属类别由文件名前缀自动推断构建时按标题字母序在各自类别内排序并为每条规则自动生成 ID如 1.1、1.2——因此**作者无需手动管理编号**这降低了维护成本并保证一致性。 ### 新增一条规则的完整流程 1. 复制 rules/_template.md 为 rules/area-description.md 2. 从 8 个前缀中选择与规则内容匹配的类别前缀 3. 填写 frontmatter 与正文确保包含清晰的错误/正确示例及解释 4. 运行 pnpm build 重新生成编译产物 AGENTS.md 与 test-cases.json。 配套脚本定义于 README还包括 - pnpm validate校验所有规则文件格式是否合规 - pnpm extract-tests从规则中抽取测试用例用于 LLM 评估 - pnpm dev构建并校验的组合命令。 这套工作流的意义在于规则不是散落的 Markdown而是通过构建脚本汇聚成一份编译后的完整指南即 AGENTS.md并抽出可供 LLM 评测的测试集形成编写 → 校验 → 编译 → 评估的闭环。 ## 实战规则示例从模板到落地 以下选取仓库中覆盖不同类别与影响等级的规则实例展示模板如何在真实场景中展开。这些文件均位于 [rules](https://link.gitcode.com/i/12da5c3ef9b996bd24cda5eadab42ba2) 目录下。 ### 示例一async-parallelCRITICAL消除瀑布 [async-parallel.md](https://link.gitcode.com/i/03c5ffac58859229b5e570ace359ccd3) 展示了最基本的瀑布消除当多个异步操作彼此独立时应使用 Promise.all() 并发执行。 **Incorrect顺序执行3 次网络往返** typescript const user await fetchUser() const posts await fetchPosts() const comments await fetchComments()Correct并行执行1 次往返const [user, posts, comments] await Promise.all([ fetchUser(), fetchPosts(), fetchComments() ])impactDescription标注的2-10×提升量级来自网络延迟被合并为单次往返这一事实——这正是_sections.md中每个顺序 await 累加完整网络延迟的直接体现。示例二async-cheap-condition-before-awaitHIGH短路守卫前置async-cheap-condition-before-await.md 是flag cheapCondition型判断的专项优化当分支同时依赖异步标志位与廉价的同步条件时应先求值同步条件避免在条件必然不成立时仍发起网络请求、特性开关查询或React.cache()/ 数据库调用。Incorrectconst someFlag await getFlag() if (someFlag someCondition) { // ... }Correctif (someCondition) { const someFlag await getFlag() if (someFlag) { // ... } }该规则同时给出了适用边界若someCondition本身昂贵、依赖标志位结果或必须按固定顺序执行副作用则应保持原始顺序——这体现了规则模板对适用前提与限制的重视避免 Agent 盲目套用。示例三bundle-barrel-importsCRITICAL包体积优化bundle-barrel-imports.md 针对桶文件barrel file即通过export * from ./module聚合导出的入口文件问题流行图标与组件库的入口文件可能包含多达上万个 re-export许多 React 包仅 import 就需要200-800ms同时拖慢开发启动与生产冷启动。文档还解释了 tree-shaking 在此场景失效的原因——当库被标记为 external不打包时bundler 无法优化它而为了启用 tree-shaking 将其打入 bundle又会让构建因分析整个模块图而显著变慢。该规则给出了两条修复路径方案一Next.js 13.5 推荐构建期自动优化桶导入// next.config.js module.exports { experimental: { optimizePackageImports: [lucide-react, mui/material] } }// 保持标准导入Next.js 会在构建时将其改写为直接导入 import { Check, X, Menu } from lucide-react该方案的优势是保留 TypeScript 类型安全与编辑器自动补全同时消除桶导入成本。方案二非 Next.js 项目直接深层导入import Button from mui/material/Button import TextField from mui/material/TextField // 只加载实际使用到的模块规则还给出了 TypeScript 陷阱提示部分库如lucide-react不为深层导入路径提供.d.ts类型声明在strict/noImplicitAny下会退化为隐式any因此应优先使用optimizePackageImports或先确认库为其子路径导出类型。这种方案 坑位预警的结构正是模板Correct 示例 补充说明的延伸。示例四server-cache-reactMEDIUM请求内去重server-cache-react.md 讲解用React.cache()在服务端单次请求内做去重收益最大的场景是认证与数据库查询import { cache } from react export const getCurrentUser cache(async () { const session await auth() if (!session?.user?.id) return null return await db.user.findUnique({ where: { id: session.user.id } }) })同一请求内多次调用getCurrentUser()只会真正执行一次查询。规则特别提醒了一个反直觉的坑React.cache()使用浅比较Object.is判断缓存命中内联对象每次调用都会创建新引用导致永久缓存失效应改用原始类型参数或复用同一对象引用// 错误每次调用创建新对象永不命中缓存 getUser({ uid: 1 }) getUser({ uid: 1 }) // 缓存未命中再次执行查询 // 正确原始类型按值相等命中 getUser(1) getUser(1) // 缓存命中 // 若必须传对象请复用同一引用 const params { uid: 1 } getUser(params) getUser(params) // 同一引用缓存命中规则还划清了与 Next.js 内建能力的边界Next.js 已为fetch自动扩展请求记忆化同 URL 同参数的请求在单次请求内自动去重因此React.cache()主要用于数据库查询、重型计算、认证检查、文件系统操作等非fetch的异步任务。示例五rerender-memoMEDIUM重渲染优化rerender-memo.md 展示了提取为 memoized 组件以支持提前返回的模式将昂贵计算拆进独立的memo()组件后父组件可在 loading 状态下直接 return从而跳过子组件内useMemo的计算Incorrectloading 时仍计算头像function Profile({ user, loading }: Props) { const avatar useMemo(() { const id computeAvatarId(user) return Avatar id{id} / }, [user]) if (loading) return Skeleton / return div{avatar}/div }Correctloading 时跳过计算const UserAvatar memo(function UserAvatar({ user }: { user: User }) { const id useMemo(() computeAvatarId(user), [user]) return Avatar id{id} / }) function Profile({ user, loading }: Props) { if (loading) return Skeleton / return ( div UserAvatar user{user} / /div ) }规则末尾特别注明若项目启用了 React Compiler手动memo()/useMemo()不再是必须的编译器会自动优化重渲染。这体现了规则体系对 React 生态演进的追踪。示例六js-hoist-regexpLOW-MEDIUMJS 热路径微优化j s-hoist-regexp.md 属于第 7 类别热路径微优化不要在渲染内创建 RegExp应提升到模块作用域或用useMemo()记忆化function Highlighter({ text, query }: Props) { const regex new RegExp((${query}), gi) // 每次渲染都重建 ... }const EMAIL_REGEX /^[^\s][^\s]\.[^\s]$/ // 静态正则提升到模块级 function Highlighter({ text, query }: Props) { const regex useMemo( () new RegExp((${escapeRegex(query)}), gi), [query] ) ... }规则还附带一个经典陷阱警示带g标志的正则具有可变的lastIndex状态复用全局正则时test()结果会交替变化——这类使用注意事项正是模板鼓励的Additional context。编写高质量规则的最佳实践综合模板、README 与仓库内规则实例可以提炼出面向 Agent / LLM 消费场景的规则编写规范结构即契约严格遵循模板的 frontmatter 正文骨架。frontmatter 保证机器可读正文的**Incorrect**/**Correct**对照保证 LLM 可以识别坏模式、套用好模式。量化影响尽可能在impactDescription中给出量级或成本描述如2-10×、200-800ms、Loads 1,583 modules帮助 Agent 按收益排序重构动作。示例要真实可运行代码示例贴近真实业务用户查询、图标导入、正则高亮等并带注释说明代价避免抽象占位符。标注适用边界如async-cheap-condition-before-await明确何时应保持原顺序、server-cache-react明确何时不需要React.cache()防止 Agent 在不适用的场景误用。追踪生态演进如 React Compiler 的启用会取代手动 memoization、Next.js 对fetch的内建记忆化会取代部分React.cache()用法规则应及时补充这类版本与前提说明。正确归类与命名按 8 大类别选择前缀、按area-description.md命名让构建脚本能自动归组、排序并生成 ID。结语_template.md虽然只是一份十几行的模板文件但它定义了 Vercel React Best Practices 这套 70 条规则体系的生产标准——机器可读的元数据、Bad/Good 对照的正文、量化到毫秒/倍数的收益声明加上命名约定与构建脚本共同构成了一套面向 Agent 与 LLM 的规则即代码工作流。当前仓库已在.agents/skills/vercel-react-best-practices下完整保留了这份体系含 SKILL.md 快速索引、README.md 维护指南、metadata.json 元数据与全部规则文件无论是想为自己的 React / Next.js 项目沉淀性能规范还是希望让 Agent 具备可检索的性能重构能力这套模板与方法论都值得直接借鉴。赞分享可观测性AI 评测LLMOpsAI 应用人工智能【免费下载链接】phoenixAI Observability Evaluation项目地址https://gitcode.com/gh_mirrors/phoenix13/phoenix点击查看免费下载相关推荐Polar 仓库中的 Vercel React 性能优化规则库如何用 _template.md 编写一条可被 Agent 与 LLM 理解执行的性能规则Polar 仓库中的 Vercel React 性能优化规则库如何用 _template.md 编写一条可被 Agent 与 LLM 理解执行的性能规则 导读后端前端金融科技3分钟搞定电子课本批量下载免代码操作存下智慧平台教材PDF3分钟搞定电子课本批量下载免代码操作存下智慧平台教材PDF 上完课想让学生预习你只能在网页里一页页翻找 PDF 入口翻三本教材就过去十分钟。tchMate网页爬虫教育Sanity 仓库内置的 Vercel React 最佳实践面向 AI Agent 的 57 条 React/Next.js 性能优化规则Sanity 仓库内置的 Vercel React 最佳实践面向 AI Agent 的 57 条 React/Next.js 性能优化规则 Sanity 单仓CMS前端创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考