不能直接用 delete() 在并发场景下操作 Go 原生 map，因其非并发安全，多 goroutine 同时读写（含 delete、range、len 等）会触发 panic；sync.Map 仅适用于读多写少、键长期存在的场景，高频增删反而更慢；需根据 key 生命周期、读写比例及业务语义选择 sync.Map、带锁封装或 channel 单协程方案。
为什么不能直接用 delete() 在并发场景下操作 Map
Go 的原生 map 不是并发安全的，多个 goroutine 同时读写（哪怕只是 delete() 或 map[key]）会触发 panic：fatal error: concurrent map read and map write。这不是概率问题，只要存在读+删、删+删、删+遍历等任意组合，就可能崩溃。别指望“我只删不读”能绕过——range 遍历、len()、甚至 GC 扫描都可能触发内部读操作。
用 sync.Map 替代普通 Map 的适用边界
sync.Map 是 Go 标准库提供的并发安全 Map，但它不是万能替代品。它适合读多写少、键值生命周期较长的场景；如果频繁删除 + 插入新键，性能反而比加锁的普通 map 差，因为 sync.Map 内部用了冗余存储和延迟清理机制。
- ✅ 适合：缓存、配置快照、连接池状态映射（key 基本不变，value 偶尔更新）
- ❌ 不适合：高频增删的计数器、实时 session 管理（大量 key 短期存在后被删）
- ⚠️ 注意：
sync.Map的Delete()方法本身安全，但它的Range()是快照语义，删完再Range()可能看不到刚删的项；且不支持获取当前长度或批量清空
手动加锁实现高可控的并发安全删除函数
当需要精确控制删除逻辑（比如删前校验 value、触发回调、或与其它字段联动更新），推荐封装带 sync.RWMutex 的结构体。关键点在于：读操作用 RLock()，写操作（含 delete()）必须用 Lock()，且避免在锁内做耗时操作。
type SafeMap[K comparable, V any] struct {
mu sync.RWMutex
m map[K]V
}
func (sm *SafeMap[K, V]) Delete(key K) bool {
sm.mu.Lock()
defer sm.mu.Unlock()
if _, exists := sm.m[key]; !exists {
return false
}
delete(sm.m, key)
return true
}
// 使用示例：
m := &SafeMap[string, int]{m: make(map[string]int)}
m.Store("a", 1)
m.Delete("a") // 返回 true
m.Delete("b") // 返回 false
- 不要把
delete()和业务逻辑（如日志、网络调用）塞进锁内 - 如果只删不关心是否存在，可省略返回值和
if判断，直接delete(sm.m, key) - 注意：
sync.RWMutex的RLock()对delete()没用——删必须写锁，读多场景才值得用 RWMutex；纯删多场景，sync.Mutex更轻量
删除时需警惕的隐式并发陷阱
即使封装了安全删除函数，仍可能因外部使用方式引入竞争。常见坑包括：
- 传入的
key是指针或结构体，且被多个 goroutine 同时修改 → 删除的是旧值还是新值无法保证，应确保 key 不变或传副本 - 删除后立即用
len(m)判断是否为空，但其他 goroutine 正在插入 → 结果不可靠，需配合条件变量或原子计数器 - 用
for range遍历时调用Delete()→ Go 规范明确禁止，会导致未定义行为；正确做法是先收集待删 key，再统一删 - 误以为
sync.Map.Delete()是原子的“检查并删”，其实它不返回原值，也无法知道删前是否存在；若需此语义，必须自己加锁实现
真正难的从来不是写一个 Delete() 函数，而是厘清你的 key 生命周期、读写比例、以及“删除”在业务中究竟意味着什么——是释放资源？通知下游？还是仅移除索引？这些决定了该用 sync.Map、自定义锁、还是干脆换 channel + 单 goroutine 处理。
