open-agents 性能规则实践js-cache-property-access在热循环中缓存属性访问的写法与原理【免费下载链接】open-agentsAn open source template for building cloud agents.项目地址: https://gitcode.com/GitHub_Trending/op/open-agents本文基于 open-agents 仓库内置的 Vercel React 最佳实践技能vercel-react-best-practices中的规则文件 js-cache-property-access.md 展开完整讲解「在循环中缓存对象属性访问」这条 JavaScript 性能规则它的规则元数据、错误/正确两种写法的完整对照、在 58 条规则优先级体系中的定位以及仓库内真实代码中可验证的应用场景。读完后你可以掌握如何识别「热路径中重复的属性查找」反模式如何改写为一次查找的缓存写法以及何时值得做、何时不值得做这类微优化。规则文件本体完整继承原文档内容该规则定义在技能目录下的 rules/js-cache-property-access.md。规则文件采用统一的 frontmatter 结构由技能构建流程编译进汇总文档。完整内容如下--- title: Cache Property Access in Loops impact: LOW-MEDIUM impactDescription: reduces lookups tags: javascript, loops, optimization, caching ---title规则标题「Cache Property Access in Loops在循环中缓存属性访问」即文件名去掉js-前缀后的语义主题impact影响等级为LOW-MEDIUM低-中按照技能 README 定义的六级影响标尺介于LOW增量改进与MEDIUM中等性能提升之间impactDescription一句话说明收益来源——reduces lookups减少属性查找次数tagsjavascript, loops, optimization, caching用于按主题检索规则。规则正文的核心论断只有一句话Cache object property lookups in hot paths在热路径中缓存对象属性查找。随后给出「错误/正确」两段完整对照代码这是原文档的骨架必须原样理解错误写法3 次查找 × N 次迭代for (let i 0; i arr.length; i) { process(obj.config.settings.value) }正确写法全程 1 次查找const value obj.config.settings.value const len arr.length for (let i 0; i len; i) { process(value) }对照两个版本可以精确数出查找次数的差异查找点错误写法正确写法arr.length每次迭代 1 次共 N 次1 次提升为lenobj.config.settings.value每次迭代 3 级链式查找obj→config→settings→value共 3×N 次1 次提升为value循环体内的属性操作3 1 4 次/迭代0 次原文档用「3 lookups × N iterations」对「1 lookup total」的标注正是指obj.config.settings.value这条四级链上的 3 次.访问被重复执行了 N 遍。编译产物印证规则在汇总文档中的位置技能目录下的 SKILL.md 声明了这套技能的运行方式它收录 Vercel 工程团队维护的 58 条 React/Next.js 性能规则按影响分为 8 大类「优先用于指导自动化重构和代码生成」并在编写、评审、重构 React/Next.js 代码时触发。本规则属于第 7 类JavaScript Performancejs-前缀LOW-MEDIUM技能中给出的速查条目为js-cache-property-access- Cache object properties in loops技能还说明了每个规则文件的固定结构「简要说明为什么重要 错误代码示例 正确代码示例 附加上下文与引用」。本文开头继承的 frontmatter 与两段代码正是该结构的实例。编译产物 AGENTS.md 中该规则被编号为7.3 Cache Property Access in Loops与源文件内容一致并位于整个「JavaScript Performance」章节该章节在编译文档中的开篇说明是Micro-optimizations for hot paths can add up to meaningful improvements——热路径上的微优化累积起来会产生有意义的提升。这一章节定位直接回答了一个关键问题这条规则的收益预期是「累积型」的而不是单点爆发型的它服务于大 N 的循环与高频重渲染路径而非冷启动代码。规则在 8 类优先级体系中的定位SKILL.md 的优先级表是理解这条规则「权重」的坐标系优先级类别影响前缀1Eliminating WaterfallsCRITICALasync-2Bundle Size OptimizationCRITICALbundle-3Server-Side PerformanceHIGHserver-4Client-Side Data FetchingMEDIUM-HIGHclient-5Re-render OptimizationMEDIUMrerender-6Rendering PerformanceMEDIUMrendering-7JavaScript PerformanceLOW-MEDIUMjs-8Advanced PatternsLOWadvanced-js-cache-property-access排在第 7 位意味着在资源有限时应先处理瀑布式await、包体积、服务端与重渲染问题再做 JS 热路径微优化。这一点在 open-agents 仓库自身的实践记录中有直接证据react-best-practices-audit.md 是该仓库对apps/web应用 57 条规则的审计记录其发现项按影响排序全部聚焦在第 16 类顺序 await 链、缺失 Suspense 边界、next/dynamic缺失、桶式导入、Context 未记忆化等第 7 类 JS 微优化并未成为审计重点——这与优先级表完全吻合。与同族规则的组合为什么「缓存查找」常与「合并迭代」成对出现同目录下还有两条与js-cache-property-access语义强关联的规则理解它们的配合关系能加深对本规则的把握js-combine-iterations.mdLOW-MEDIUMreduces iterations多次.filter()/.map()遍历同一数组应合并为一个循环。原文档示例把 3 次users.filter(...)迭代改写为单次for...of加多个push。js-cache-function-results.mdMEDIUMavoid redundant computation对渲染期间以相同入参被反复调用的纯函数用模块级Map缓存结果如slugify结果缓存且明确要求「用 Map 而非 Hook使其在工具函数、事件处理程序等非 React 场景同样可用」。组合起来看一条热循环的完整优化链路是先减少迭代次数combine-iterations再减少每次迭代内的查找次数cache-property-access最后把循环体内昂贵的纯函数调用改为查表cache-function-results。本规则负责的是其中「每次迭代内的属性查找」这一环。源码级原理为什么const len arr.length是有效的从 JavaScript 引擎的执行模型看这条规则的价值取决于「属性读取的实际成本」arr.length普通数组上读取length是 O(1) 且极易被 JIT 内联现代引擎下单次成本很低但它是每次迭代都要执行的读取N 越大总次数越多。将其提升为len是把 N 次读取压成 1 次属于零风险、零语义变化的改写。obj.config.settings.value这类链式访问成本随链路深度线性增长——每一级.都涉及一次属性查找可能含原型链遍历。若中间某层是 getter、Proxy例如 React 的useRef对象、状态管理库的 observable 对象、Proxy包装的 SDK 配置每次迭代还会触发额外的陷阱函数调用此时重复读取的成本远不止「几次哈希查表」。把它提升到循环外既减少总查找次数也避免了重复触发 getter 的副作用与开销。适用前提被缓存的取值在循环期间保持不可变。若obj在循环体内会被修改、或value依赖迭代状态则不能提升——缓存的前提是值稳定。正确写法示例中process(value)隐含了这一前提。同时要注意适用边界这类改写的收益上限由「查找次数 × 单次成本」决定因此它只对大 N 循环、每帧/每 token 执行的热路径如消息流式渲染中逐 token 重算列表、长列表滚动绘制、工具输出解析有意义对一次性执行、N 很小的代码块改写的可读性代价大于收益这也正是它被标为 LOW-MEDIUM 而非 CRITICAL 的原因。在 open-agents 仓库中的可验证实践技能文件被放在仓库的.agents/skills/下说明该仓库把这套规则作为 Agent 协作的技能库直接加载使用SKILL.md的When to Apply列举了触发场景编写新组件、实现数据获取、评审性能、重构、优化包体积。仓库内的现有代码可作为该规则的观察样本packages/agent/tools/glob.tsAgent 的 glob 工具在解析模式前缀时使用了for (let i 0; i patternParts.length - 1; i)形式的索引循环。这里patternParts.length每迭代读取一次属于规则覆盖的形态由于length是单层读取且循环次数受模式段数限制通常很小实际收益有限——这正体现了规则影响等级的含义识别出模式但只在热路径上优先套用。packages/shared/lib/diff.tscreateEditDiffLines在构建 diff 行时使用forEach遍历oldLines/newLines并在循环外一次性读取oldLines.length/newLines.length计算removals/additions——长度在循环外只取一次与规则「1 lookup total」的方向一致。此外code-style.md 明确了本仓库的工程约束TypeScript strict 模式开启、noUncheckedIndexedAccess: true索引访问必须判空如 glob.ts 中对patternParts[i]!的处理、Bun 作为唯一包管理器、测试用bun:test并采用.test.ts后缀与源码同目录存放。做热路径优化重构时这些约束是必须遵守的前提改写后仍要保证严格类型下索引访问的安全且可用同目录测试验证行为不变。实操清单如何对一段循环套用本规则把上面内容收敛成可执行的检查步骤定位热路径找出每次用户交互、每个流式 token、每帧滚动都会执行的循环如消息列表渲染、工具输出解析、diff 计算冷代码直接跳过。数查找次数对循环条件与循环体逐条标记属性读取。arr.length写在for条件里即是一次/迭代a.b.c.d链即 3 次/迭代。确认可变性确认这些值在循环期间不会被任何分支修改。可变则不能提升可拆分为「循环内必须重读」与「循环外可提升」两组。改写并验证按原文档正确写法将稳定值提升为const循环内只引用局部变量在本仓库中运行对应的bun test测试与源码同目录确认行为不变。配合相邻规则若同一函数存在多次遍历同一数组先做 combine-iterations 的合并若循环体内有重复入参的纯函数调用再做 cache-function-results 的模块级Map缓存。关键文件索引文件说明rules/js-cache-property-access.md本文主体规则 frontmatter 错误/正确完整代码对照SKILL.md技能入口58 条规则、8 类优先级表、触发时机AGENTS.md编译产物本规则编号 7.3内容经编译与源文件一致README.md规则文件结构、影响等级定义、构建脚本说明rules/js-combine-iterations.md相邻规则合并多次数组遍历rules/js-cache-function-results.md相邻规则模块级 Map 缓存函数结果docs/agents/react-best-practices-audit.md仓库对apps/web的规则审计记录印证优先级排序的实际用法packages/agent/tools/glob.ts仓库内索引循环形态的实例packages/shared/lib/diff.ts循环外一次性读取长度的 diff 构建实现【免费下载链接】open-agentsAn open source template for building cloud agents.项目地址: https://gitcode.com/GitHub_Trending/op/open-agents创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 open-agents 性能规则实践：js-cache-property-access，在热循环中缓存属性访问的写法与原理
open-agents 性能规则实践js-cache-property-access在热循环中缓存属性访问的写法与原理【免费下载链接】open-agentsAn open source template for building cloud agents.项目地址: https://gitcode.com/GitHub_Trending/op/open-agents本文基于 open-agents 仓库内置的 Vercel React 最佳实践技能vercel-react-best-practices中的规则文件 js-cache-property-access.md 展开完整讲解「在循环中缓存对象属性访问」这条 JavaScript 性能规则它的规则元数据、错误/正确两种写法的完整对照、在 58 条规则优先级体系中的定位以及仓库内真实代码中可验证的应用场景。读完后你可以掌握如何识别「热路径中重复的属性查找」反模式如何改写为一次查找的缓存写法以及何时值得做、何时不值得做这类微优化。规则文件本体完整继承原文档内容该规则定义在技能目录下的 rules/js-cache-property-access.md。规则文件采用统一的 frontmatter 结构由技能构建流程编译进汇总文档。完整内容如下--- title: Cache Property Access in Loops impact: LOW-MEDIUM impactDescription: reduces lookups tags: javascript, loops, optimization, caching ---title规则标题「Cache Property Access in Loops在循环中缓存属性访问」即文件名去掉js-前缀后的语义主题impact影响等级为LOW-MEDIUM低-中按照技能 README 定义的六级影响标尺介于LOW增量改进与MEDIUM中等性能提升之间impactDescription一句话说明收益来源——reduces lookups减少属性查找次数tagsjavascript, loops, optimization, caching用于按主题检索规则。规则正文的核心论断只有一句话Cache object property lookups in hot paths在热路径中缓存对象属性查找。随后给出「错误/正确」两段完整对照代码这是原文档的骨架必须原样理解错误写法3 次查找 × N 次迭代for (let i 0; i arr.length; i) { process(obj.config.settings.value) }正确写法全程 1 次查找const value obj.config.settings.value const len arr.length for (let i 0; i len; i) { process(value) }对照两个版本可以精确数出查找次数的差异查找点错误写法正确写法arr.length每次迭代 1 次共 N 次1 次提升为lenobj.config.settings.value每次迭代 3 级链式查找obj→config→settings→value共 3×N 次1 次提升为value循环体内的属性操作3 1 4 次/迭代0 次原文档用「3 lookups × N iterations」对「1 lookup total」的标注正是指obj.config.settings.value这条四级链上的 3 次.访问被重复执行了 N 遍。编译产物印证规则在汇总文档中的位置技能目录下的 SKILL.md 声明了这套技能的运行方式它收录 Vercel 工程团队维护的 58 条 React/Next.js 性能规则按影响分为 8 大类「优先用于指导自动化重构和代码生成」并在编写、评审、重构 React/Next.js 代码时触发。本规则属于第 7 类JavaScript Performancejs-前缀LOW-MEDIUM技能中给出的速查条目为js-cache-property-access- Cache object properties in loops技能还说明了每个规则文件的固定结构「简要说明为什么重要 错误代码示例 正确代码示例 附加上下文与引用」。本文开头继承的 frontmatter 与两段代码正是该结构的实例。编译产物 AGENTS.md 中该规则被编号为7.3 Cache Property Access in Loops与源文件内容一致并位于整个「JavaScript Performance」章节该章节在编译文档中的开篇说明是Micro-optimizations for hot paths can add up to meaningful improvements——热路径上的微优化累积起来会产生有意义的提升。这一章节定位直接回答了一个关键问题这条规则的收益预期是「累积型」的而不是单点爆发型的它服务于大 N 的循环与高频重渲染路径而非冷启动代码。规则在 8 类优先级体系中的定位SKILL.md 的优先级表是理解这条规则「权重」的坐标系优先级类别影响前缀1Eliminating WaterfallsCRITICALasync-2Bundle Size OptimizationCRITICALbundle-3Server-Side PerformanceHIGHserver-4Client-Side Data FetchingMEDIUM-HIGHclient-5Re-render OptimizationMEDIUMrerender-6Rendering PerformanceMEDIUMrendering-7JavaScript PerformanceLOW-MEDIUMjs-8Advanced PatternsLOWadvanced-js-cache-property-access排在第 7 位意味着在资源有限时应先处理瀑布式await、包体积、服务端与重渲染问题再做 JS 热路径微优化。这一点在 open-agents 仓库自身的实践记录中有直接证据react-best-practices-audit.md 是该仓库对apps/web应用 57 条规则的审计记录其发现项按影响排序全部聚焦在第 16 类顺序 await 链、缺失 Suspense 边界、next/dynamic缺失、桶式导入、Context 未记忆化等第 7 类 JS 微优化并未成为审计重点——这与优先级表完全吻合。与同族规则的组合为什么「缓存查找」常与「合并迭代」成对出现同目录下还有两条与js-cache-property-access语义强关联的规则理解它们的配合关系能加深对本规则的把握js-combine-iterations.mdLOW-MEDIUMreduces iterations多次.filter()/.map()遍历同一数组应合并为一个循环。原文档示例把 3 次users.filter(...)迭代改写为单次for...of加多个push。js-cache-function-results.mdMEDIUMavoid redundant computation对渲染期间以相同入参被反复调用的纯函数用模块级Map缓存结果如slugify结果缓存且明确要求「用 Map 而非 Hook使其在工具函数、事件处理程序等非 React 场景同样可用」。组合起来看一条热循环的完整优化链路是先减少迭代次数combine-iterations再减少每次迭代内的查找次数cache-property-access最后把循环体内昂贵的纯函数调用改为查表cache-function-results。本规则负责的是其中「每次迭代内的属性查找」这一环。源码级原理为什么const len arr.length是有效的从 JavaScript 引擎的执行模型看这条规则的价值取决于「属性读取的实际成本」arr.length普通数组上读取length是 O(1) 且极易被 JIT 内联现代引擎下单次成本很低但它是每次迭代都要执行的读取N 越大总次数越多。将其提升为len是把 N 次读取压成 1 次属于零风险、零语义变化的改写。obj.config.settings.value这类链式访问成本随链路深度线性增长——每一级.都涉及一次属性查找可能含原型链遍历。若中间某层是 getter、Proxy例如 React 的useRef对象、状态管理库的 observable 对象、Proxy包装的 SDK 配置每次迭代还会触发额外的陷阱函数调用此时重复读取的成本远不止「几次哈希查表」。把它提升到循环外既减少总查找次数也避免了重复触发 getter 的副作用与开销。适用前提被缓存的取值在循环期间保持不可变。若obj在循环体内会被修改、或value依赖迭代状态则不能提升——缓存的前提是值稳定。正确写法示例中process(value)隐含了这一前提。同时要注意适用边界这类改写的收益上限由「查找次数 × 单次成本」决定因此它只对大 N 循环、每帧/每 token 执行的热路径如消息流式渲染中逐 token 重算列表、长列表滚动绘制、工具输出解析有意义对一次性执行、N 很小的代码块改写的可读性代价大于收益这也正是它被标为 LOW-MEDIUM 而非 CRITICAL 的原因。在 open-agents 仓库中的可验证实践技能文件被放在仓库的.agents/skills/下说明该仓库把这套规则作为 Agent 协作的技能库直接加载使用SKILL.md的When to Apply列举了触发场景编写新组件、实现数据获取、评审性能、重构、优化包体积。仓库内的现有代码可作为该规则的观察样本packages/agent/tools/glob.tsAgent 的 glob 工具在解析模式前缀时使用了for (let i 0; i patternParts.length - 1; i)形式的索引循环。这里patternParts.length每迭代读取一次属于规则覆盖的形态由于length是单层读取且循环次数受模式段数限制通常很小实际收益有限——这正体现了规则影响等级的含义识别出模式但只在热路径上优先套用。packages/shared/lib/diff.tscreateEditDiffLines在构建 diff 行时使用forEach遍历oldLines/newLines并在循环外一次性读取oldLines.length/newLines.length计算removals/additions——长度在循环外只取一次与规则「1 lookup total」的方向一致。此外code-style.md 明确了本仓库的工程约束TypeScript strict 模式开启、noUncheckedIndexedAccess: true索引访问必须判空如 glob.ts 中对patternParts[i]!的处理、Bun 作为唯一包管理器、测试用bun:test并采用.test.ts后缀与源码同目录存放。做热路径优化重构时这些约束是必须遵守的前提改写后仍要保证严格类型下索引访问的安全且可用同目录测试验证行为不变。实操清单如何对一段循环套用本规则把上面内容收敛成可执行的检查步骤定位热路径找出每次用户交互、每个流式 token、每帧滚动都会执行的循环如消息列表渲染、工具输出解析、diff 计算冷代码直接跳过。数查找次数对循环条件与循环体逐条标记属性读取。arr.length写在for条件里即是一次/迭代a.b.c.d链即 3 次/迭代。确认可变性确认这些值在循环期间不会被任何分支修改。可变则不能提升可拆分为「循环内必须重读」与「循环外可提升」两组。改写并验证按原文档正确写法将稳定值提升为const循环内只引用局部变量在本仓库中运行对应的bun test测试与源码同目录确认行为不变。配合相邻规则若同一函数存在多次遍历同一数组先做 combine-iterations 的合并若循环体内有重复入参的纯函数调用再做 cache-function-results 的模块级Map缓存。关键文件索引文件说明rules/js-cache-property-access.md本文主体规则 frontmatter 错误/正确完整代码对照SKILL.md技能入口58 条规则、8 类优先级表、触发时机AGENTS.md编译产物本规则编号 7.3内容经编译与源文件一致README.md规则文件结构、影响等级定义、构建脚本说明rules/js-combine-iterations.md相邻规则合并多次数组遍历rules/js-cache-function-results.md相邻规则模块级 Map 缓存函数结果docs/agents/react-best-practices-audit.md仓库对apps/web的规则审计记录印证优先级排序的实际用法packages/agent/tools/glob.ts仓库内索引循环形态的实例packages/shared/lib/diff.ts循环外一次性读取长度的 diff 构建实现【免费下载链接】open-agentsAn open source template for building cloud agents.项目地址: https://gitcode.com/GitHub_Trending/op/open-agents创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考