 查找，告别数组 includes 的 O(n) 循环)
OpenMontage 前端性能优化用 Set/Map 实现 O(1) 查找告别数组 includes 的 O(n) 循环【免费下载链接】OpenMontageWorlds first open-source, agentic video production system. 12 production pipelines, 100 tools, 700 agent skill and production-knowledge files. Turn your AI coding assistant into a full video production studio.项目地址: https://gitcode.com/GitHub_Trending/op/OpenMontage导读本篇文章围绕 OpenMontage 仓库内 Vercel React 最佳实践技能包.claude/skills/vercel-react-best-practices中的js-set-map-lookups规则展开讲解在 React/Next.js 及任何前端代码中如何用Set/Map把反复执行的数组成员/关联查找从 O(n) 降到 O(1)。读完本文你将掌握规则原文、算法原理、适用与不适用场景、以及仓库源码中可对应落地的优化点可直接用于日常编码、代码评审与性能重构。规则原文Use Set/Map for O(1) Lookups规则文件位于 .claude/skills/vercel-react-best-practices/rules/js-set-map-lookups.md它的 frontmatter 定义了该规则的元信息--- title: Use Set/Map for O(1) Lookups impact: LOW-MEDIUM impactDescription: O(n) to O(1) tags: javascript, set, map,>const allowedIds [a, b, c, ...] items.filter(item allowedIds.includes(item.id))正确的写法每次检查 O(1)const allowedIds new Set([a, b, c, ...]) items.filter(item allowedIds.has(item.id))规则位于技能包分类中的第 7 类JavaScript Performancejs-前缀影响级别 LOW-MEDIUM同类的姊妹规则还包括js-index-maps为重复查找构建索引 Map、js-cache-function-results模块级 Map 缓存函数结果、js-hoist-regexp循环外提升正则等详见 .claude/skills/vercel-react-best-practices/SKILL.md 的分类总表。为什么 O(n) 和 O(1) 差别巨大算法原理解读Array.prototype.includes 是线性扫描allowedIds.includes(item.id)底层等价于从下标 0 开始逐个比较元素直到命中为止。数组越长单次检查的期望比较次数越多时间复杂度为O(n)。Set/Map 基于哈希表均摊 O(1)Set.prototype.has与Map.prototype.get基于哈希表实现JS 引擎如 V8 采用哈希 桶结构必要时退化为查找树单次查找是均摊 O(1)先对键计算哈希定位桶再在桶内通常极少量元素做相等性判断。虽然构造 Set/Map 本身要 O(n) 遍历一次但只要查找次数足够多一次性构建成本被摊薄整体收益显著。定量感受10 万次检查的差距沿用规则姊妹篇 js-index-maps.md 中的估算方式若对 1000 个元素做 1000 次查找数组方案是 1000 × 1000 100 万次比较而先构建一次索引1000 次再查找1000 × 1 次只需约 2000 次操作。数据量扩大后这个差距从毫秒级抖动变成可感知的卡顿这就是本规则定位为impact: LOW-MEDIUM却仍值得遵守的原因——在热路径hot path上微优化会累积成可观的整体提升。Set 与 Map 如何选择规则标题同时给出Set与Map两个选项选用标准非常明确场景数据结构关键方法只关心元素是否存在成员检查/白名单/去重Setset.has(x)需要按键取值关联查找、构建索引Mapmap.get(key)Set 是唯一键的集合没有值语义只回答在不在。适合权限白名单、已处理 ID 去重、允许的枚举值过滤Map 是键→值的映射回答键对应的值是什么。适合把用户列表按id建索引后批量关联订单这正是js-index-maps规则的场景、模块级缓存js-cache-function-results规则。需要说明的是Map/Set内部的键比较遵循SameValueZero语义即NaN NaN成立、-0 0成立而对象键按引用身份比较而非深比较。因此对由多个字段拼出的复合键应先用模板字符串或嵌套 Map 归一化不能直接塞入对象字面量并期望按内容匹配。两个容易忽略的关键点Set/Map 要放在循环/渲染之外构建。若每次filter回调里都new Set(...)那构建成本反而叠加成 O(n²)违背规则初衷。正确姿势是把 Set/Map 提升为模块级常量、组件外的模块变量或用useMemo在依赖不变时缓存构建结果——这与规则文件js-cache-property-access、js-cache-storage的缓存思想一脉相承。小数组不必强转 Set。当候选数组只有 23 个元素、且只查询一次时includes与has的常数因子差异可忽略过度重构反而降低可读性。规则的适用前提是重复成员检查repeated membership checks务必先量化调用频率再动手。典型实战改写白名单过滤与关联索引结合规则原文与仓库可落地的场景给出三个可直接复制的模式。模式一白名单成员过滤规则原文直译// Before: 每次 has 都要扫描整个数组O(n * m) const allowedIds [a, b, c, ...] const visible items.filter(item allowedIds.includes(item.id)) // After: Set.has 均摊 O(1)整体 O(n m) const allowedIds new Set([a, b, c, ...]) const visible items.filter(item allowedIds.has(item.id))模式二多键枚举检查Set 版分支判断// Before: 多条件 includes 连写 const isHardCut [cut, none].includes(transition.toLowerCase()) // After: 常量 Set 提升语义更清晰 const HARD_TRANSITIONS new Set([cut, none]) const isHardCut HARD_TRANSITIONS.has(transition.toLowerCase())这类枚举值白名单判断在 OpenMontage 的 Remotion 渲染器中真实存在例如 remotion-composer/src/Explainer.tsx 中就有[cut, none].includes((transitionIn || ).toLowerCase())的写法——当这类判断位于每帧渲染或大量分镜循环内时就属于本规则建议改写的候选热路径若只是偶发单次判断保持原样亦可读。模式三重复关联查找Map 索引姊妹规则场景// Before: 订单 × 用户笛卡尔扫描O(n*m) const withUser orders.map(order ({ ...order, user: users.find(u u.id order.userId) }) ) // After: 先建索引O(n m) const userById new Map(users.map(u [u.id, u])) const withUser orders.map(order ({ ...order, user: userById.get(order.userId) }) )该模式即姊妹规则 js-index-maps.md 的核心规则内给出量级示例1000 个订单 × 1000 个用户从 100 万次操作降到约 2000 次。本规则在技能包中的定位与使用方法定位本规则隶属于 OpenMontage 仓库内 vendored 的 Vercel React 最佳实践技能包.claude/skills/vercel-react-best-practices是其中65 条规则之一归属 JavaScript Performance 分类js-前缀。技能包按优先级把 8 个分类从 CRITICAL消除 Waterfall、包体积优化到 LOW高级模式排序本规则处于第 7 档属于低成本、可批量实施的改进项适用时机编写新 React 组件 / Next.js 页面、实现客户端或服务端数据获取、做代码评审、重构性能热点时均可套用阅读方式每条规则独立成文件于 rules/ 目录遵循统一模板见 rules/_template.md包含为什么重要 → 错误示例 → 正确示例 → 补充上下文四段式结构分类与优先级总览见 SKILL.md。落地自查清单完成重构后可用以下清单做快速验收数据结构正确纯成员检查用Set.has键值关联用Map.get构建时机正确Set/Map 是否在循环、渲染回调、事件处理器之外只构建一次模块级常量或useMemo缓存调用频率确认确属重复检查热路径才改写避免为一次性小数组引入过度设计键的语义正确基本类型键可直接使用对象键需注意引用身份比较复合键需先归一化可读性保持为 Set/Map 取语义化名字如allowedIds、userById、HARD_TRANSITIONS让意图自解释。小结js-set-map-lookups规则用最简练的对比includesvshas点破了 JavaScript 性能优化中最常见的一类浪费在热路径上用线性扫描反复查同一个数组。将数组转为Set/Map后单次查找从 O(n) 降为均摊 O(1)尤其适合白名单过滤、去重与按 ID 关联索引三类高频场景。在 OpenMontage 的技能体系中它与其他js-前缀规则共同构成一套低成本高复用的 JavaScript 微优化清单可作为日常编码与代码评审的常备检查项。【免费下载链接】OpenMontageWorlds first open-source, agentic video production system. 12 production pipelines, 100 tools, 700 agent skill and production-knowledge files. Turn your AI coding assistant into a full video production studio.项目地址: https://gitcode.com/GitHub_Trending/op/OpenMontage创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
OpenMontage 前端性能优化：用 Set/Map 实现 O(1) 查找，告别数组 includes 的 O(n) 循环
OpenMontage 前端性能优化用 Set/Map 实现 O(1) 查找告别数组 includes 的 O(n) 循环【免费下载链接】OpenMontageWorlds first open-source, agentic video production system. 12 production pipelines, 100 tools, 700 agent skill and production-knowledge files. Turn your AI coding assistant into a full video production studio.项目地址: https://gitcode.com/GitHub_Trending/op/OpenMontage导读本篇文章围绕 OpenMontage 仓库内 Vercel React 最佳实践技能包.claude/skills/vercel-react-best-practices中的js-set-map-lookups规则展开讲解在 React/Next.js 及任何前端代码中如何用Set/Map把反复执行的数组成员/关联查找从 O(n) 降到 O(1)。读完本文你将掌握规则原文、算法原理、适用与不适用场景、以及仓库源码中可对应落地的优化点可直接用于日常编码、代码评审与性能重构。规则原文Use Set/Map for O(1) Lookups规则文件位于 .claude/skills/vercel-react-best-practices/rules/js-set-map-lookups.md它的 frontmatter 定义了该规则的元信息--- title: Use Set/Map for O(1) Lookups impact: LOW-MEDIUM impactDescription: O(n) to O(1) tags: javascript, set, map,>const allowedIds [a, b, c, ...] items.filter(item allowedIds.includes(item.id))正确的写法每次检查 O(1)const allowedIds new Set([a, b, c, ...]) items.filter(item allowedIds.has(item.id))规则位于技能包分类中的第 7 类JavaScript Performancejs-前缀影响级别 LOW-MEDIUM同类的姊妹规则还包括js-index-maps为重复查找构建索引 Map、js-cache-function-results模块级 Map 缓存函数结果、js-hoist-regexp循环外提升正则等详见 .claude/skills/vercel-react-best-practices/SKILL.md 的分类总表。为什么 O(n) 和 O(1) 差别巨大算法原理解读Array.prototype.includes 是线性扫描allowedIds.includes(item.id)底层等价于从下标 0 开始逐个比较元素直到命中为止。数组越长单次检查的期望比较次数越多时间复杂度为O(n)。Set/Map 基于哈希表均摊 O(1)Set.prototype.has与Map.prototype.get基于哈希表实现JS 引擎如 V8 采用哈希 桶结构必要时退化为查找树单次查找是均摊 O(1)先对键计算哈希定位桶再在桶内通常极少量元素做相等性判断。虽然构造 Set/Map 本身要 O(n) 遍历一次但只要查找次数足够多一次性构建成本被摊薄整体收益显著。定量感受10 万次检查的差距沿用规则姊妹篇 js-index-maps.md 中的估算方式若对 1000 个元素做 1000 次查找数组方案是 1000 × 1000 100 万次比较而先构建一次索引1000 次再查找1000 × 1 次只需约 2000 次操作。数据量扩大后这个差距从毫秒级抖动变成可感知的卡顿这就是本规则定位为impact: LOW-MEDIUM却仍值得遵守的原因——在热路径hot path上微优化会累积成可观的整体提升。Set 与 Map 如何选择规则标题同时给出Set与Map两个选项选用标准非常明确场景数据结构关键方法只关心元素是否存在成员检查/白名单/去重Setset.has(x)需要按键取值关联查找、构建索引Mapmap.get(key)Set 是唯一键的集合没有值语义只回答在不在。适合权限白名单、已处理 ID 去重、允许的枚举值过滤Map 是键→值的映射回答键对应的值是什么。适合把用户列表按id建索引后批量关联订单这正是js-index-maps规则的场景、模块级缓存js-cache-function-results规则。需要说明的是Map/Set内部的键比较遵循SameValueZero语义即NaN NaN成立、-0 0成立而对象键按引用身份比较而非深比较。因此对由多个字段拼出的复合键应先用模板字符串或嵌套 Map 归一化不能直接塞入对象字面量并期望按内容匹配。两个容易忽略的关键点Set/Map 要放在循环/渲染之外构建。若每次filter回调里都new Set(...)那构建成本反而叠加成 O(n²)违背规则初衷。正确姿势是把 Set/Map 提升为模块级常量、组件外的模块变量或用useMemo在依赖不变时缓存构建结果——这与规则文件js-cache-property-access、js-cache-storage的缓存思想一脉相承。小数组不必强转 Set。当候选数组只有 23 个元素、且只查询一次时includes与has的常数因子差异可忽略过度重构反而降低可读性。规则的适用前提是重复成员检查repeated membership checks务必先量化调用频率再动手。典型实战改写白名单过滤与关联索引结合规则原文与仓库可落地的场景给出三个可直接复制的模式。模式一白名单成员过滤规则原文直译// Before: 每次 has 都要扫描整个数组O(n * m) const allowedIds [a, b, c, ...] const visible items.filter(item allowedIds.includes(item.id)) // After: Set.has 均摊 O(1)整体 O(n m) const allowedIds new Set([a, b, c, ...]) const visible items.filter(item allowedIds.has(item.id))模式二多键枚举检查Set 版分支判断// Before: 多条件 includes 连写 const isHardCut [cut, none].includes(transition.toLowerCase()) // After: 常量 Set 提升语义更清晰 const HARD_TRANSITIONS new Set([cut, none]) const isHardCut HARD_TRANSITIONS.has(transition.toLowerCase())这类枚举值白名单判断在 OpenMontage 的 Remotion 渲染器中真实存在例如 remotion-composer/src/Explainer.tsx 中就有[cut, none].includes((transitionIn || ).toLowerCase())的写法——当这类判断位于每帧渲染或大量分镜循环内时就属于本规则建议改写的候选热路径若只是偶发单次判断保持原样亦可读。模式三重复关联查找Map 索引姊妹规则场景// Before: 订单 × 用户笛卡尔扫描O(n*m) const withUser orders.map(order ({ ...order, user: users.find(u u.id order.userId) }) ) // After: 先建索引O(n m) const userById new Map(users.map(u [u.id, u])) const withUser orders.map(order ({ ...order, user: userById.get(order.userId) }) )该模式即姊妹规则 js-index-maps.md 的核心规则内给出量级示例1000 个订单 × 1000 个用户从 100 万次操作降到约 2000 次。本规则在技能包中的定位与使用方法定位本规则隶属于 OpenMontage 仓库内 vendored 的 Vercel React 最佳实践技能包.claude/skills/vercel-react-best-practices是其中65 条规则之一归属 JavaScript Performance 分类js-前缀。技能包按优先级把 8 个分类从 CRITICAL消除 Waterfall、包体积优化到 LOW高级模式排序本规则处于第 7 档属于低成本、可批量实施的改进项适用时机编写新 React 组件 / Next.js 页面、实现客户端或服务端数据获取、做代码评审、重构性能热点时均可套用阅读方式每条规则独立成文件于 rules/ 目录遵循统一模板见 rules/_template.md包含为什么重要 → 错误示例 → 正确示例 → 补充上下文四段式结构分类与优先级总览见 SKILL.md。落地自查清单完成重构后可用以下清单做快速验收数据结构正确纯成员检查用Set.has键值关联用Map.get构建时机正确Set/Map 是否在循环、渲染回调、事件处理器之外只构建一次模块级常量或useMemo缓存调用频率确认确属重复检查热路径才改写避免为一次性小数组引入过度设计键的语义正确基本类型键可直接使用对象键需注意引用身份比较复合键需先归一化可读性保持为 Set/Map 取语义化名字如allowedIds、userById、HARD_TRANSITIONS让意图自解释。小结js-set-map-lookups规则用最简练的对比includesvshas点破了 JavaScript 性能优化中最常见的一类浪费在热路径上用线性扫描反复查同一个数组。将数组转为Set/Map后单次查找从 O(n) 降为均摊 O(1)尤其适合白名单过滤、去重与按 ID 关联索引三类高频场景。在 OpenMontage 的技能体系中它与其他js-前缀规则共同构成一套低成本高复用的 JavaScript 微优化清单可作为日常编码与代码评审的常备检查项。【免费下载链接】OpenMontageWorlds first open-source, agentic video production system. 12 production pipelines, 100 tools, 700 agent skill and production-knowledge files. Turn your AI coding assistant into a full video production studio.项目地址: https://gitcode.com/GitHub_Trending/op/OpenMontage创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
