01
缓存与快速查找
- 业务例子
- 把 userID → 用户信息、skuID → 商品配置、规则ID → 规则对象缓存在进程内，避免每次都遍历 slice 或重复查数据库。
- 为什么适合
- 业务天然有唯一 key，而且主要操作是按 key 查询，map 的平均 O(1) 查找非常匹配。
- 注意
- 如果多个 goroutine 会同时读写，普通 map 不能直接当并发缓存使用，需要 RWMutex、sync.Map 或更完整的缓存组件。
Application Scenarios
应用场景：这个知识点实际用在哪里
Map 最典型的价值是把‘按 key 查找’从线性遍历变成平均 O(1) 的哈希定位。真正做业务时，要先判断你的问题是不是‘根据唯一 key 快速定位数据’，而不是看到键值对就机械使用 map。
02
去重与集合判断
- 业务例子
- 批量处理订单时判断 orderID 是否已经处理过，或者过滤重复的用户 ID、SKU ID。
- 为什么适合
- 使用 map[T]struct{} 可以把‘是否存在’变成一次哈希查找，不需要每来一个元素都扫描整个 slice。
- 注意
- 数据规模很大且需要跨进程、跨机器共享时，进程内 map 不够，需要 Redis、数据库唯一约束等外部存储。
03
计数与聚合
- 业务例子
- 统计每个状态的订单数量、每个商户的商品数、日志中每个错误码出现次数。
- 为什么适合
- key 代表分组维度，value 保存累计值，写法直接：counts[key]++。
- 注意
- 如果需要强一致的并发聚合，必须处理并发写问题；超大基数聚合也要考虑内存占用。
04
索引和路由表
- 业务例子
- 把 handlerName → handler、事件类型 → 处理函数、配置名 → 配置对象建立映射，用于快速分发请求或事件。
- 为什么适合
- 本质是建立一个轻量索引，先通过 key 定位目标对象，再执行后续逻辑，比大量 if/else 或 switch 更容易扩展。
- 注意
- 如果业务要求稳定顺序、范围查询、前缀查询或按大小排序，单纯 map 并不合适。
什么时候不应该硬用
- 需要稳定遍历顺序时不要依赖 map；应该额外维护有序 key，或使用适合排序的数据结构。
- 需要范围查询，例如查 100~200 之间所有 key 时，哈希表不是优势场景，树结构或数据库索引更合适。
- 只是十几个元素且只遍历一两次时，不必为了理论 O(1) 强行建 map，构建哈希表本身也有成本。
- 并发读写场景不能直接使用普通 map；先明确锁粒度、sync.Map 适用性或是否应该把状态放到外部存储。
面试里可以这样落地
比如我需要根据 skuID 高频读取商品配置，就会把数据组织成 map[string]Config，因为核心操作是按唯一 key 查找；如果只是顺序展示或范围查询，我不会用 map。实际工程里我还会同时考虑并发安全、数据量和是否需要跨进程共享。