 成员判断)
Mastra 前端性能优化实战用 Set/Map 替代数组查找实现 O(1) 成员判断【免费下载链接】mastraMastra is the modern TypeScript framework for AI-powered applications and agents.项目地址: https://gitcode.com/GitHub_Trending/ma/mastra在 React 应用中重复的成员资格检查membership check是高频且容易被忽视的性能热点一次Array.prototype.includes()是 O(n)而当它出现在filter、事件处理或渲染循环等热路径上时n 次调用就退化成 O(n²)。本文基于 Mastra 仓库中react-best-practices技能体系js-set-map-lookups.md的官方规则系统讲解为何要把数组改为Set/Map进行 O(1) 查找并剖析packages/playground-ui中多个真实落地案例帮助你写出既快又稳的查找代码。规则出处与定位这条规则来自 Mastra 仓库维护的 react-best-practices 技能目录它是面向 Agent 与 LLM 的 26 条 React 性能与质量规则之一位于第 6 类JavaScript Performancejs-*前缀共 3 条与js-tosorted-immutable不可变排序、js-length-check-first数组比较先查长度并列。规则文件的元数据直接给出了适用画像标题Use Set/Map for O(1) Lookups影响等级LOW-MEDIUM影响描述O(n) to O(1标签javascript、set、map、data-structures、performance所谓LOW-MEDIUM并非意味着不重要——单个查找的常数级提升看似微小但正如规则强调的当这些查找发生在filter回调、事件处理函数、渲染循环等热路径上时量变会累积成质变页面响应速度的差异会非常明显。问题本质为什么includes()会拖慢渲染规则给出的反例非常简洁// 错误示范每次检查都是 O(n) const allowedIds [a, b, c, ...] items.filter(item allowedIds.includes(item.id))这里的性能瓶颈在两层单次检查是线性扫描includes()从数组头开始逐个比较直到命中或遍历完。allowedIds有 n 个元素最坏情况就是 n 次比较。检查次数随数据量放大filter会对items的每一个元素调用一次回调因此总成本是items.length × allowedIds.length。当items有 m 个元素时整体复杂度是 O(m × n)。在真实 React 场景里这种模式常出现在权限过滤、白名单校验、选中态判断等逻辑中。数据规模一上来每次setState触发重渲染都会重新执行整条扫描链路界面卡顿随之而来。正确姿势Set与Map的 O(1) 哈希查找规则给出的正确写法一行之差复杂度天壤之别// 正确示范每次检查都是 O(1) const allowedIds new Set([a, b, c, ...]) items.filter(item allowedIds.has(item.id))Set与Map底层基于哈希表实现has()/get()的平均时间复杂度为 O(1)。把构建查找结构一次 O(n) 初始化和重复查询每次 O(1)分离后整体成本从 O(m × n) 降到 O(m n)。两者的选择很简单只关心在不在用Set判断走has()不仅判断存在还要取回关联值用Map查询走get()例如把id → 名称、状态码 → 文案这类映射放进Map。初始化成本建议放在模块作用域或useMemo中避免每次渲染都重建哈希表Set/Map的构建本身是 O(n)重建等于浪费。这一点与rerender-lazy-state-init等重渲染规则的思路一脉相承——一次性准备工作绝不放进渲染热路径。仓库实证一枚举白名单校验metrics-filters.tsMastra 的playground-ui在度量面板中需要校验来自 URL 参数或本地存储的rootEntityType是否为后端合法枚举值。由于外部输入是任意字符串不能直接信任代码用Set构建了白名单// packages/playground-ui/src/domains/metrics/metrics-filters.ts#L312-L318 const VALID_ROOT_ENTITY_TYPES: ReadonlySetEntityTypeValue new Set( METRICS_ROOT_ENTITY_TYPE_OPTIONS.map(o o.entityType), ); function toValidRootEntityType(v: string): EntityType | undefined { const trimmed v.trim(); return VALID_ROOT_ENTITY_TYPES.has(trimmed as EntityTypeValue) ? (trimmed as EntityType) : undefined; }关键点查找结构在模块顶层只构建一次所有渲染与过滤共享同一份Set类型上标注ReadonlySet防止后续代码误修改has()承担了真正的校验逻辑返回undefined表示非法值干净利落。同样的模式也出现在度量预设校验中use-metrics.tsxVALID_PRESETS.has(value)一行完成合法预设判断。仓库实证二跨页数据去重use-logs.ts日志列表使用 offset 分页拉取而两次fetchNextPage之间若插入了新日志页面边界处就会出现重复行。若不处理重复数据会生成重复的 React key、打乱虚拟滚动偏移量。实现用Set做 O(1) 去重// packages/playground-ui/src/domains/logs/hooks/use-logs.ts#L40-L52 function selectLogs(data: { pages: ListLogsResponse[] }) { const seen new Setstring(); const result []; for (const page of data.pages) { for (const log of page.logs ?? []) { const key log.logId ?? JSON.stringify(log); if (seen.has(key)) continue; seen.add(key); result.push(log); } } return result; }seen.has(key)与seen.add(key)的组合让每个日志条目只被检查一次。如果改用数组seen.includes(key)在日志量大时这段代码会迅速退化为性能灾难。此外logs/log-filters.ts中过滤字段的seen集合log-filters.ts也采用了同一策略。仓库实证三集合运算与状态派生trace-timeline-span.tsTrace 时间线组件需要维护已展开节点的集合并在展开/折叠时对节点 ID 做集合运算源码中大量使用Set进行差集、并集处理// packages/playground-ui/src/domains/traces/components/trace-timeline-span.tsx#L77-L118 // 展开加入自身与所有后代 id return Array.from(new Set([...prev, span.id, ...allDescendantIds])); // 折叠构造待移除 id 集合再过滤 const idsToRemove new Set(allDescendantIds);这里Set不仅承担 O(1) 成员判断还天然具备自动去重能力——把多个来源的 id 合并进Set再Array.from展开去重逻辑零成本完成。trace-data-panel-view.tsx中payloadOnlyMatchIds.has(span.spanId)trace-data-panel-view.tsx则是另一个批量搜索命中 id 的 O(1) 标记用例。仓库实证四枚举去重与唯一单位收集度量卡片组件需要从数据行中收集唯一的计费单位集合同样依赖Set去重// packages/playground-ui/src/domains/metrics/components/token-usage-by-agent-card-view.tsx#L45 const uniqueCostUnits new Set(costRows.map(d d.costUnit ?? usd));以及 flame-graph 数据预处理中跨两个 Map 键的并集// packages/playground-ui/src/domains/memory/components/flame-graph-data.ts#L119 const allTimes Array.from(new Set([...areaValueByTime.keys(), ...eventsByTime.keys()])).sort((a, b) a - b);Map.keys()直接配合Set做时间戳并集读取与去重一步到位代码意图一目了然。使用边界与注意事项掌握规则的同时也要明白何时不该使用避免过度优化数据量小且只查一次数组只有三五个元素、查询只发生一次时Set的构建开销可能超过省下的比较时间可读性上也未必更优对象相等性陷阱Set/Map的has()/get()基于 SameValueZero 语义两个内容相同的普通对象不是同一个引用不能命中。需要按对象字段判断时先把字段序列化为 key如JSON.stringify或改用 Map 的 key 对象引用管理内存与 GCSet对成员的引用是强引用长期持有的大集合会阻止成员被回收需评估生命周期构建后不再变化的集合建议冻结引用如ReadonlySet防止误写避免在渲染中重建把查找结构提升到模块作用域或缓存到useMemo否则每次渲染重建哈希表优化会打折扣类型安全规则体系中的types-no-type-assertions同样适用于此——仓库案例里出现的as EntityTypeValue断言属于边界收窄场景日常代码中应优先用类型守卫收窄后再has()保持类型流完整详见 types-no-type-assertions.md。与相邻规则的协同js-set-map-lookups属于 JavaScript 微优化类别和另外两条规则经常组合出现js-length-check-first.md数组比较先比长度O(1) 提前返回避免无谓的排序与序列化——先廉价判断再昂贵运算的同一哲学js-tosorted-immutable.md用toSorted()替代原地sort()避免污染 React 的 props/state 不可变模型——查找结构同样应保持只读。三条规则共同构成 Mastra 前端数据操作微优化的完整工具箱查找用哈希Set/Map、比较先查长度、排序保持不可变。在日常 Code Review 中看到someArray.includes(x)出现在循环或filter回调里就应该警觉并考虑转换为Set.has()这套判断依据可以直接沉淀为团队的 lint 检查或 Agent 审查清单。小结把数组换成Set/Map做重复成员判断是投入产出比极高的一行式优化平均复杂度从 O(n) 降到 O(1)整体过滤流程从 O(m × n) 降到 O(m n)。Mastra 的playground-ui在枚举白名单校验、跨页日志去重、trace 节点集合运算、度量单位收集四个场景中均落地了这一模式并遵循结构提升到模块作用域、类型标注只读、与类型守卫配合的最佳实践。下次再写includes()前先问自己一句这个数组会被查询多少次如果答案不止一次——请换成Set。【免费下载链接】mastraMastra is the modern TypeScript framework for AI-powered applications and agents.项目地址: https://gitcode.com/GitHub_Trending/ma/mastra创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Mastra 前端性能优化实战：用 Set/Map 替代数组查找实现 O(1) 成员判断
Mastra 前端性能优化实战用 Set/Map 替代数组查找实现 O(1) 成员判断【免费下载链接】mastraMastra is the modern TypeScript framework for AI-powered applications and agents.项目地址: https://gitcode.com/GitHub_Trending/ma/mastra在 React 应用中重复的成员资格检查membership check是高频且容易被忽视的性能热点一次Array.prototype.includes()是 O(n)而当它出现在filter、事件处理或渲染循环等热路径上时n 次调用就退化成 O(n²)。本文基于 Mastra 仓库中react-best-practices技能体系js-set-map-lookups.md的官方规则系统讲解为何要把数组改为Set/Map进行 O(1) 查找并剖析packages/playground-ui中多个真实落地案例帮助你写出既快又稳的查找代码。规则出处与定位这条规则来自 Mastra 仓库维护的 react-best-practices 技能目录它是面向 Agent 与 LLM 的 26 条 React 性能与质量规则之一位于第 6 类JavaScript Performancejs-*前缀共 3 条与js-tosorted-immutable不可变排序、js-length-check-first数组比较先查长度并列。规则文件的元数据直接给出了适用画像标题Use Set/Map for O(1) Lookups影响等级LOW-MEDIUM影响描述O(n) to O(1标签javascript、set、map、data-structures、performance所谓LOW-MEDIUM并非意味着不重要——单个查找的常数级提升看似微小但正如规则强调的当这些查找发生在filter回调、事件处理函数、渲染循环等热路径上时量变会累积成质变页面响应速度的差异会非常明显。问题本质为什么includes()会拖慢渲染规则给出的反例非常简洁// 错误示范每次检查都是 O(n) const allowedIds [a, b, c, ...] items.filter(item allowedIds.includes(item.id))这里的性能瓶颈在两层单次检查是线性扫描includes()从数组头开始逐个比较直到命中或遍历完。allowedIds有 n 个元素最坏情况就是 n 次比较。检查次数随数据量放大filter会对items的每一个元素调用一次回调因此总成本是items.length × allowedIds.length。当items有 m 个元素时整体复杂度是 O(m × n)。在真实 React 场景里这种模式常出现在权限过滤、白名单校验、选中态判断等逻辑中。数据规模一上来每次setState触发重渲染都会重新执行整条扫描链路界面卡顿随之而来。正确姿势Set与Map的 O(1) 哈希查找规则给出的正确写法一行之差复杂度天壤之别// 正确示范每次检查都是 O(1) const allowedIds new Set([a, b, c, ...]) items.filter(item allowedIds.has(item.id))Set与Map底层基于哈希表实现has()/get()的平均时间复杂度为 O(1)。把构建查找结构一次 O(n) 初始化和重复查询每次 O(1)分离后整体成本从 O(m × n) 降到 O(m n)。两者的选择很简单只关心在不在用Set判断走has()不仅判断存在还要取回关联值用Map查询走get()例如把id → 名称、状态码 → 文案这类映射放进Map。初始化成本建议放在模块作用域或useMemo中避免每次渲染都重建哈希表Set/Map的构建本身是 O(n)重建等于浪费。这一点与rerender-lazy-state-init等重渲染规则的思路一脉相承——一次性准备工作绝不放进渲染热路径。仓库实证一枚举白名单校验metrics-filters.tsMastra 的playground-ui在度量面板中需要校验来自 URL 参数或本地存储的rootEntityType是否为后端合法枚举值。由于外部输入是任意字符串不能直接信任代码用Set构建了白名单// packages/playground-ui/src/domains/metrics/metrics-filters.ts#L312-L318 const VALID_ROOT_ENTITY_TYPES: ReadonlySetEntityTypeValue new Set( METRICS_ROOT_ENTITY_TYPE_OPTIONS.map(o o.entityType), ); function toValidRootEntityType(v: string): EntityType | undefined { const trimmed v.trim(); return VALID_ROOT_ENTITY_TYPES.has(trimmed as EntityTypeValue) ? (trimmed as EntityType) : undefined; }关键点查找结构在模块顶层只构建一次所有渲染与过滤共享同一份Set类型上标注ReadonlySet防止后续代码误修改has()承担了真正的校验逻辑返回undefined表示非法值干净利落。同样的模式也出现在度量预设校验中use-metrics.tsxVALID_PRESETS.has(value)一行完成合法预设判断。仓库实证二跨页数据去重use-logs.ts日志列表使用 offset 分页拉取而两次fetchNextPage之间若插入了新日志页面边界处就会出现重复行。若不处理重复数据会生成重复的 React key、打乱虚拟滚动偏移量。实现用Set做 O(1) 去重// packages/playground-ui/src/domains/logs/hooks/use-logs.ts#L40-L52 function selectLogs(data: { pages: ListLogsResponse[] }) { const seen new Setstring(); const result []; for (const page of data.pages) { for (const log of page.logs ?? []) { const key log.logId ?? JSON.stringify(log); if (seen.has(key)) continue; seen.add(key); result.push(log); } } return result; }seen.has(key)与seen.add(key)的组合让每个日志条目只被检查一次。如果改用数组seen.includes(key)在日志量大时这段代码会迅速退化为性能灾难。此外logs/log-filters.ts中过滤字段的seen集合log-filters.ts也采用了同一策略。仓库实证三集合运算与状态派生trace-timeline-span.tsTrace 时间线组件需要维护已展开节点的集合并在展开/折叠时对节点 ID 做集合运算源码中大量使用Set进行差集、并集处理// packages/playground-ui/src/domains/traces/components/trace-timeline-span.tsx#L77-L118 // 展开加入自身与所有后代 id return Array.from(new Set([...prev, span.id, ...allDescendantIds])); // 折叠构造待移除 id 集合再过滤 const idsToRemove new Set(allDescendantIds);这里Set不仅承担 O(1) 成员判断还天然具备自动去重能力——把多个来源的 id 合并进Set再Array.from展开去重逻辑零成本完成。trace-data-panel-view.tsx中payloadOnlyMatchIds.has(span.spanId)trace-data-panel-view.tsx则是另一个批量搜索命中 id 的 O(1) 标记用例。仓库实证四枚举去重与唯一单位收集度量卡片组件需要从数据行中收集唯一的计费单位集合同样依赖Set去重// packages/playground-ui/src/domains/metrics/components/token-usage-by-agent-card-view.tsx#L45 const uniqueCostUnits new Set(costRows.map(d d.costUnit ?? usd));以及 flame-graph 数据预处理中跨两个 Map 键的并集// packages/playground-ui/src/domains/memory/components/flame-graph-data.ts#L119 const allTimes Array.from(new Set([...areaValueByTime.keys(), ...eventsByTime.keys()])).sort((a, b) a - b);Map.keys()直接配合Set做时间戳并集读取与去重一步到位代码意图一目了然。使用边界与注意事项掌握规则的同时也要明白何时不该使用避免过度优化数据量小且只查一次数组只有三五个元素、查询只发生一次时Set的构建开销可能超过省下的比较时间可读性上也未必更优对象相等性陷阱Set/Map的has()/get()基于 SameValueZero 语义两个内容相同的普通对象不是同一个引用不能命中。需要按对象字段判断时先把字段序列化为 key如JSON.stringify或改用 Map 的 key 对象引用管理内存与 GCSet对成员的引用是强引用长期持有的大集合会阻止成员被回收需评估生命周期构建后不再变化的集合建议冻结引用如ReadonlySet防止误写避免在渲染中重建把查找结构提升到模块作用域或缓存到useMemo否则每次渲染重建哈希表优化会打折扣类型安全规则体系中的types-no-type-assertions同样适用于此——仓库案例里出现的as EntityTypeValue断言属于边界收窄场景日常代码中应优先用类型守卫收窄后再has()保持类型流完整详见 types-no-type-assertions.md。与相邻规则的协同js-set-map-lookups属于 JavaScript 微优化类别和另外两条规则经常组合出现js-length-check-first.md数组比较先比长度O(1) 提前返回避免无谓的排序与序列化——先廉价判断再昂贵运算的同一哲学js-tosorted-immutable.md用toSorted()替代原地sort()避免污染 React 的 props/state 不可变模型——查找结构同样应保持只读。三条规则共同构成 Mastra 前端数据操作微优化的完整工具箱查找用哈希Set/Map、比较先查长度、排序保持不可变。在日常 Code Review 中看到someArray.includes(x)出现在循环或filter回调里就应该警觉并考虑转换为Set.has()这套判断依据可以直接沉淀为团队的 lint 检查或 Agent 审查清单。小结把数组换成Set/Map做重复成员判断是投入产出比极高的一行式优化平均复杂度从 O(n) 降到 O(1)整体过滤流程从 O(m × n) 降到 O(m n)。Mastra 的playground-ui在枚举白名单校验、跨页日志去重、trace 节点集合运算、度量单位收集四个场景中均落地了这一模式并遵循结构提升到模块作用域、类型标注只读、与类型守卫配合的最佳实践。下次再写includes()前先问自己一句这个数组会被查询多少次如果答案不止一次——请换成Set。【免费下载链接】mastraMastra is the modern TypeScript framework for AI-powered applications and agents.项目地址: https://gitcode.com/GitHub_Trending/ma/mastra创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考