sync.Map并非万能并发Map，仅适用于读多写少、键稳定场景；其读无锁、写加锁，但写频繁时性能反不如map+sync.RWMutex。
用 sync.Map 替代 map + mutex 的常见误用
直接在并发场景下读写普通 map 会 panic，错误信息是 fatal error: concurrent map read and map write。很多人第一反应是加 sync.Mutex 包裹读写，但锁粒度粗、易阻塞、且容易漏锁或重复锁。
如果只是做键值缓存、配置热更新、或状态映射这类“读多写少”场景，sync.Map 是更轻量的选择——它内部做了分片和原子操作优化，读不加锁，写只锁局部桶。
-
sync.Map不支持遍历（range），必须用Range方法传回调函数处理 - 不能直接取地址：
sync.Map.Load返回interface{}，需类型断言；若存的是结构体指针，别误以为能直接修改字段（要先 Load 再 Store） - 初始化后无法像普通 map 那样用
make(map[string]int)方式预分配，也没法用len()获取长度
channel 传数据不是万能的，得看传递模式
协程间传数据，第一直觉常是 channel，但它只适合“生产者-消费者”或“信号通知”类场景，不适合共享状态同步。比如想让多个 goroutine 共同更新一个计数器，用 chan int 发送增量再累加，反而引入调度开销和竞争风险。
真正该用 channel 的时候：事件广播（如配置变更通知）、任务分发（worker pool）、结果聚合（waitgroup + channel 收集返回值）。
立即学习“go语言免费学习笔记（深入）”；
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
- 单次传递用
chan struct{}表示信号，比chan bool更省内存 - 带缓冲 channel（
make(chan int, 10)）可缓解发送方阻塞，但缓冲区大小要匹配实际吞吐，设太大等于掩盖背压问题 - 不要在循环里反复创建 channel，尤其在高频 goroutine 启动时，会导致 GC 压力和内存泄漏
context.WithValue 是临时透传，不是状态容器
很多人把 context.WithValue 当成协程安全的全局状态池来用，这是危险的。它的设计初衷是传递请求生命周期内的**不可变元数据**（如 trace ID、user ID），不是用来存可变业务状态。
问题在于：context.Value 返回的是拷贝值，修改 struct 字段不会影响原 context 中的值；而且 key 类型若用字符串，极易冲突；用自定义类型又难统一管理。
- key 必须是导出的未比较类型（如
type ctxKey string），避免不同包用相同字符串 key 覆盖 - 只存小对象（string、int、指针），别塞大 struct 或 map，否则每次
WithValue都复制一份 - 一旦用了
context.WithValue，下游必须显式检查ok返回值，否则可能 panic 或静默失败
struct + sync.RWMutex 是最可控的折中方案
当数据结构较复杂（比如含多个字段、需要原子读+条件写）、或读写频率接近时，sync.RWMutex 包裹 struct 是最清晰、最易测试的方式。它不像 sync.Map 那样隐藏实现细节，也不像 channel 那样强制改变控制流。
关键点是封装访问方法，禁止直接暴露字段：
type Config struct {
mu sync.RWMutex
host string
port int
}
func (c *Config) Host() string {
c.mu.RLock()
defer c.mu.RUnlock()
return c.host
}
func (c *Config) Update(host string, port int) {
c.mu.Lock()
defer c.mu.Unlock()
c.host = host
c.port = port
}
- 读多用
RWMutex.RLock()，写时才升级为Lock()，避免读阻塞读 - 方法内必须成对使用
Lock/Unlock或RLock/RUnlock，建议用defer，别依赖 return 逻辑 - 如果 struct 字段本身是 map/slice，它们仍需额外同步——
sync.RWMutex只保护字段地址，不保护底层数据
真正麻烦的不是选哪种机制，而是混用：比如用 sync.Map 存指针，又在 goroutine 里直接改指针指向的 struct 字段。这种“看似线程安全实则裸奔”的情况，调试起来最耗时间。
