delete函数本身不保证并发安全，是Go内置的map操作，无锁机制；多goroutine同时读写会触发panic；需用sync.RWMutex的Lock()保护写操作，sync.Map.Delete则线程安全但语义不同。
delete 函数本身不保证并发安全
delete 是 Go 的内置函数，只作用于 map 类型，它本身没有任何锁机制或同步逻辑。无论你用 sync.RWMutex、sync.Map 还是自定义封装，只要底层 map 被多个 goroutine 同时读写（哪怕只是 delete 和 range 交叉），就会触发 fatal error: concurrent map iteration and map write panic。
关键点在于：不是 delete 写错了，而是它执行时 map 正在被另一个 goroutine 遍历或读取——Go 运行时会直接中止程序。所以「用 delete」和「用得安全」是两回事。
-
delete第一个参数不能为nil，否则 panic；第二个参数类型必须严格匹配 map key 类型 - 对不存在的 key 调用
delete安全，无副作用，但不意味着“可以乱删”——并发下仍需锁保护 - 即使只调用
delete，也属于写操作，必须与所有读操作（包括for range、m[key]）互斥
sync.RWMutex 下 delete 的正确加锁姿势
用 sync.RWMutex 保护 map 时，常见错误是误用 RLock() 执行 delete。这是非法的：RLock() 只允许读，不允许任何写，包括 delete。
正确做法始终是：写操作（含 delete、赋值、make 后首次写）必须用 Lock()，不能降级为读锁。
立即学习“go语言免费学习笔记（深入）”；
- ✅ 单个删除：先
mu.Lock()，再delete(m, key)，最后mu.Unlock() - ✅ 批量删除：先
mu.RLock()收集待删 key 列表（只读），mu.RUnlock()，再mu.Lock()批量delete - ❌ 在
RLock()持有期间调用delete→ panic - ❌ 在
for range循环里边遍历边delete→ panic（即使加了Lock()，也因迭代器失效而不可靠）
sync.Map 里 delete 的特殊行为
sync.Map 提供了 Delete(key interface{}) 方法，它内部做了线程安全封装，调用时无需额外加锁。但要注意它和原生 map + sync.RWMutex 的语义差异：
-
sync.Map.Delete不会 panic，即使 key 不存在或 map 为 nil（它自己处理了边界） - 它不支持原子性批量删除；也没有办法像原生 map 那样高效遍历后筛选删除
- 如果业务需要频繁遍历+条件删除（比如按超时时间清理缓存），
sync.Map反而更慢，因为它的Range方法返回的是快照，无法在遍历时安全修改 - 它的零值是有效的，不需要
make，但内部存储结构导致高并发写场景下内存占用略高
delete 后 map 内存不会立即释放
调用 delete(m, key) 只是移除键值对的引用，底层哈希桶和内存不会立刻回收。map 的底层数组容量不变，后续插入仍可能复用旧空间。这意味着：
- 反复增删后 map 实际占用内存可能远大于当前元素数
- 若要真正释放内存，必须重建 map：
m = make(map[K]V, len(m))，再把剩余有效项 copy 过去 - 在连接池、缓存等长期运行场景中，如果 map 大小波动剧烈，建议定期重建而非只依赖
delete
这点容易被忽略：你看到 len(m) 变小了，不代表 GC 会立刻回收那部分内存。真正的释放时机取决于 map 底层 bucket 的复用策略和 GC 周期。
