本文探讨在 react 中对同一数组按多个状态值（如 new/purchased/damaged）进行分组时，如何以最少遍历次数实现高效、可维护的代码，重点对比 filter×3、map+filter×3 与 reduce 单次遍历三种方案的性能与可读性。
本文探讨在 react 中对同一数组按多个状态值（如 new/purchased/damaged）进行分组时，如何以最少遍历次数实现高效、可维护的代码，重点对比 filter×3、map+filter×3 与 reduce 单次遍历三种方案的性能与可读性。
在构建带标签页（Tabs）的车辆管理界面时，常见需求是将一个统一的 cars 数组按 status 字段拆分为「新车」「已购」「损毁」三组并分别渲染。由于后端未提供预分组数据，前端必须自行过滤。此时，开发者常面临一个关键权衡：是为每个标签单独调用 .filter()，还是借助 Map 集中处理？哪种方式真正更高效？
直觉上，使用 Map 存储三组结果看似“更结构化”，但若其实现仍依赖三次独立 .filter()（如问题中第二个方案），则时间复杂度并未改善——它仍是 O(3n) = O(n)，且隐含三次完整数组扫描、三次内存分配与三次函数调用开销。而原始的三次独立 useMemo（如 newCars/purchasedCars/damagedCars）更严重：不仅重复遍历，还导致三次独立的 memoization 计算与缓存，增加 React 渲染协调负担。
✅ 真正高效的解法是单次遍历 + 分组聚合，核心工具是 Array.prototype.reduce()：
const carsMap = useMemo(() => {
return cars.reduce((map, car) => {
const { status } = car;
// 确保目标 status 对应的数组存在
if (!map.has(status)) {
map.set(status, []);
}
// 直接推入已映射的数组（避免重复 get + set）
map.get(status)!.push({
id: car.id,
// 按需映射其他字段，如 name, price 等
name: car.name,
price: car.price,
});
return map;
}, new Map<string, Array<{ id: string; name: string; price: number }>>());
}, [cars]);该方案仅遍历 cars 数组 一次（O(n)），通过 Map 的 O(1) 查找与原地 push 实现零冗余分组。后续各标签页可安全复用：
前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。
立即学习“前端免费学习笔记（深入）”；
// 「新车」Tab
{carsMap.get('new')?.map((car, index) => (
<CarItem key={car.id} car={car} />
))}
// 「已购」Tab
{carsMap.get('purchased')?.map((car, index) => (
<CarItem key={car.id} car={car} />
))}
// 「损毁」Tab
{carsMap.get('damaged')?.map((car, index) => (
<CarItem key={car.id} car={car} />
))}⚠️ 关键注意事项：
- key 推荐使用唯一 ID 而非 index：carsMap.get(...) 返回的是新数组，但其元素顺序稳定；若 car.id 可靠，优先用 key={car.id} 保障 React Diff 准确性，避免因排序变动引发重渲染。
- 类型安全增强：TypeScript 中显式声明 Map 的泛型（如 Map<'new' | 'purchased' | 'damaged', Car[]>）可提升类型提示与编译期检查。
- 空状态防御：使用可选链 ?.map() 或提前判断 if (carsMap.has('new'))，避免 undefined.map() 报错。
- 扩展性考量：若未来新增状态（如 'reserved'），只需调整 Map 初始化逻辑或后端约定，无需修改分组核心代码。
总结而言，“一次 reduce + Map 分组” 在性能（最小遍历）、内存（单次分配）、可维护性（逻辑集中、易扩展）上全面优于多次 filter 或多次 useMemo。它不是炫技，而是对数据流本质的尊重：当输入相同、输出多维时，单次消费永远是最优起点。
