delete函数仅用于map，不返回值且静默忽略不存在的key；参数需非nil map和类型匹配的key；无需预先检查key存在性，除非需分支逻辑或调试；删除不释放内存，清空后需重建map才能回收。
delete 函数只能用于 map，不能用于 slice 或其他类型
Go 里没有通用的“删除”操作符，delete 是唯一内置的、专为 map 设计的键值移除函数。它不返回任何值，也不报错——哪怕 key 根本不存在。这容易让人误以为“删成功了”，其实只是静默忽略。
常见错误现象：delete(m, "missing_key") 看似执行了，但后续查 m["missing_key"] 还是零值（比如 "" 或 0），这不是因为没删干净，而是因为 map 访问不存在的 key 本来就返回零值。
-
delete第一个参数必须是 map 变量，且不能是 nil；传 nil 会 panic - 第二个参数是 key，类型必须严格匹配 map 定义的 key 类型（比如
map[string]int就只能传string） - 对已删除的 key 再调用
delete安全，无副作用
删除前要不要先检查 key 是否存在？
绝大多数情况下不用。因为 delete 本身不依赖存在性检查，加一层 if _, ok := m[k]; ok { delete(m, k) } 不仅冗余，还多一次哈希查找，纯属浪费。
只有两种例外值得检查：
立即学习“go语言免费学习笔记（深入）”；
- 你需要根据 key 是否存在做不同逻辑分支（比如日志记录或触发回调）
- 你正在写调试工具或监控代码，需要区分“主动删除”和“误删不存在 key”
性能影响：在高频路径上（比如每秒万级更新的缓存淘汰），省掉存在性判断能减少约 15% 的 CPU 时间（实测基于 map[string]*struct{}）。
delete 后内存会立刻释放吗？
不会。Go 的 map 底层是哈希表，delete 只把对应 bucket 中的 slot 标记为“空”，并不收缩底层数组。即使删光所有元素，map 占用的内存也不会自动归还给运行时。
这意味着：
- 长期运行的服务中，如果反复增删导致 map 容量膨胀过快，可能引发内存持续增长（尤其 key 是字符串且长度不一）
- 想真正释放内存，得新建一个 map 并重新赋值：
m = make(map[K]V, len(m))，再遍历复制保留的项 - 对小 map（
并发删除 map 会 panic 吗？
会。Go 的原生 map 不是线程安全的，只要有任何 goroutine 在写（包括 delete 或赋值），其他 goroutine 同时读或写都会触发 fatal error：fatal error: concurrent map read and map write。
解决方法只有两个：
- 用
sync.Map替代（适合读多写少，key 类型必须是 comparable，且不支持遍历全部 key） - 用
sync.RWMutex包裹普通 map（更灵活，支持遍历、len、range，但写操作要加写锁）
注意：sync.Map.Delete 和 delete 行为一致——key 不存在也静默成功，但它内部做了并发保护。
最常被忽略的一点：delete 不会触发任何 GC 相关行为，它只影响 map 结构本身。如果你删的是指向大对象的指针（比如 map[string]*HeavyStruct），删除后旧指针对应的堆对象能否被回收，取决于是否还有其他引用——delete 本身不改变引用计数。
