不能直接用 map[string]struct{} 做并发安全的 set，因为 go 原生 map 非并发安全，多 goroutine 读写会 panic；须用 sync.rwmutex 封装，且 mutex 必须作为结构体字段嵌入并置于 map 前，初始化需 make，add/contains/delete 要正确加锁，nil map 需防护，sync.map 不适合 set 场景。
为什么不能直接用 map[string]struct{} 做并发安全的 Set
因为 Go 的原生 map 不是并发安全的，多个 goroutine 同时读写会触发 panic："fatal error: concurrent map read and map write"。即使只读不写，只要存在任意写操作，就必须加锁——sync.RWMutex 的读锁（RLock）能允许多个 goroutine 并发读，但写仍需独占锁。
封装 Set 时 RWMutex 放哪里最稳妥
必须把 sync.RWMutex 作为结构体字段嵌入，且放在 map 字段之前（非必需但符合惯用写法），确保锁保护的是整个 map 操作。常见错误是把 mutex 定义在方法内、或作为局部变量传参，那根本起不到保护作用。
正确结构示例：
type Set struct {
mu sync.RWMutex
m map[string]struct{}
}
- 初始化时必须调用
make(map[string]struct{})，不能留空指针 - 所有对外方法（
Add、Contains、Delete）都要显式加锁/解锁 -
Contains用RLOCK，Add/Delete用Lock，别反了
Add 和 Contains 方法里容易漏掉的边界检查
两个典型坑：Add 未判空导致插入空字符串（逻辑上可能非法）、Contains 对 nil map panic。虽然 map 支持对 nil map 读（返回 false），但写会 crash，所以初始化必须到位。
立即学习“go语言免费学习笔记（深入）”；
-
Add前建议判断val == ""（按业务决定是否跳过） -
Contains方法开头加if s.m == nil { return false }更健壮 - 不要在
Add里重复make，应在构造函数（如NewSet()）中一次性完成
性能敏感场景下要不要用 sync.Map 替代 RWMutex + map
不用。除非你有极高读写频次且 key 分布极广，否则 sync.Map 在 Set 这类小规模、键值固定（string）的场景下反而更慢、内存开销更大。它针对的是“读多写少+键生命周期长”的缓存场景，不是通用并发容器。
-
sync.Map不支持遍历（range），而 Set 常需枚举元素 - 它的
LoadOrStore返回值语义复杂，不如手写mu.Lock(); defer mu.Unlock()直观 - 实测 10k 元素以下，RWMutex 封装的 map 吞吐高 2–3 倍
真正要注意的是：别在循环里反复调用 Add 而不批量处理；如果一次要塞几百个，先加锁、批量写、再解锁，比逐个加锁快得多。
