Object.groupBy 不支持多维分组，因其返回 plain object、键限字符串/Symbol、无法嵌套或保留中间聚合态；需用 Map 手动构建可迭代、任意键类型、内存友好的嵌套索引结构。
Object.groupBy 本身不支持多维分组，必须配合 Map 手动构建嵌套索引结构；直接链式调用或期望原生返回 Map 是常见误解。
为什么不能直接用 Object.groupBy 做多维索引
Object.groupBy 返回的是 plain object（无原型），键只能是字符串或 Symbol，且不支持嵌套键路径、动态层级、或非字符串键（如对象、数组）。当你尝试按 { category: "A", status: "active" } 分组时，({ category, status }) => `${category}-${status}` 这种拼接方式会丢失原始结构语义，且在 key 冲突（如 "A-10" 和 "A1-0"）时不可靠。更关键的是：它无法保留中间维度的聚合态（比如先按 category 分，再在每个 category 下按 status 统计数量），而这是多维索引的核心需求。
常见错误现象包括：
- 分组结果中出现
undefined键，因回调返回了undefined或null而未做兜底 - 多个维度组合后 key 被强制转为
[object Object]，导致全部数据挤进同一个组 - 后续想对某一层子组再做
groupby，但 plain object 不提供entries()或迭代协议，需额外Object.entries()转换，性能损耗明显
用 Map 构建可迭代、可嵌套的多维索引结构
Map 天然支持任意类型作为 key，并提供 entries()、get()、set() 和迭代能力，适合逐层构建索引。例如实现「按 type → 按 status → 元素数组」三级索引：
const index = new Map();
for (const item of data) {
const { type, status } = item;
if (!index.has(type)) {
index.set(type, new Map());
}
const statusMap = index.get(type);
if (!statusMap.has(status)) {
statusMap.set(status, []);
}
statusMap.get(status).push(item);
}
// 使用：index.get("fruit")?.get("in_stock") → 返回对应数组
这种结构的优势在于：
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
- 支持任意深度嵌套，只需在循环内增加
if (!map.has(x)) map.set(x, new Map())判断 - key 类型自由：可用
{ type, status }对象作 key（需确保hasOwnProperty或自定义比较逻辑），也可用JSON.stringify仅限简单值 - 内存友好：只存引用，不深拷贝原始数据；遍历时可直接用
for...of index.entries()，无需转换 - 可增量更新：新增数据时，只需走相同路径
set，无需重建整个索引
结合 Object.groupBy 做首层预分组，再用 Map 展开
如果首层分组逻辑固定且轻量（如按字符串字段），可用 Object.groupBy 快速切分，再对每组用 Map 构建下层索引——这样能利用其内置优化，避免手写 for 循环的冗余判断：
const byType = Object.groupBy(data, ({ type }) => type);
const index = new Map();
for (const [type, items] of Object.entries(byType)) {
const statusMap = new Map();
for (const item of items) {
const { status } = item;
if (!statusMap.has(status)) statusMap.set(status, []);
statusMap.get(status).push(item);
}
index.set(type, statusMap);
}
注意点：
-
Object.entries(byType)是必须的，因为byType是 plain object，不能直接for...of - 若
type可能为null或undefined，Object.groupBy会将其转为"null"字符串键，需提前过滤或映射 - 该模式适用于首层区分度高、次层维度较浅的场景；若所有维度都高基数，纯 Map 嵌套更可控
性能与内存边界必须手动控制
大规模 JSON 数据（如 >10 万条）下，嵌套 Map 的内存占用和 GC 压力容易被低估。一个 Map 实例本身约 40–60 字节，但每项 set(key, value) 都会创建内部节点，深层嵌套会放大开销。实际使用中必须：
- 限制最大嵌套层数（如不超过 3 层），超过则改用扁平化 key（
`${a}_${b}_${c}`）+ 单层 Map - 对高频查询字段预计算 hash 或使用
WeakMap（仅当 key 是对象且生命周期明确时） - 避免在索引中存储重复大字段（如完整 JSON 字符串），只存引用或必要字段投影
- 定期用
index.clear()或局部map.delete(key)清理过期分组，尤其在长周期服务中
真正难的不是写几行嵌套 Map，而是判断哪一层该用字符串 key、哪一层该用对象 key、以及什么时候该放弃内存索引转向磁盘/服务端聚合——这些决策点往往藏在数据分布和查询 pattern 里，而不是语法里。
