只有当读写模式满足「高频读 + 低频写 + 键值对生命周期长」时才应使用 sync.map，它适用于缓存用户会话、配置项等长期存在且极少更新的场景，不适用于短生命周期键或需 len()、range 等原生操作的场合。
sync.Map 和 sync.Pool 都不是“通用并发容器”，它们解决的是特定场景下的共享内存安全问题，选错就容易踩坑。
什么时候该用 sync.Map 而不是普通 map？
只有当你的读写模式满足「高频读 + 低频写 + 键值对生命周期长」时，sync.Map 才比加锁的普通 map 更合适。它内部用了读写分离+分片锁，读几乎无锁，但写操作开销更大，且不支持 len()、range 这类原生语法。
- 错误用法：用
sync.Map存大量短生命周期键（比如 HTTP 请求 ID），会导致内部桶频繁扩容和 GC 压力上升 - 正确姿势：缓存用户会话、配置项这类长期存在、极少更新的键值对
- 注意：
sync.Map.Load返回的是interface{}，类型断言失败会 panic，务必检查ok返回值
sync.Pool 不是缓存，也不是连接池
sync.Pool 的核心语义是「临时对象复用」，它的对象可能在任意 GC 周期被清空，且不保证对象一定被复用——它只降低分配频率，不管理生命周期。
- 别往里塞含指针或闭包的对象：GC 可能漏掉引用，导致内存泄露
- 别依赖
Pool.Get()一定返回非 nil：必须做好初始化兜底，比如if v == nil { v = &MyStruct{} } - 常见误用：当成全局缓存存储业务状态，结果某次 GC 后数据消失，逻辑出错
真正需要并发安全队列或列表时，别硬套 sync.Map 或 sync.Pool
它们都不是为队列/栈/链表设计的。sync.Map 没有 FIFO 保证，sync.Pool 不提供顺序语义。真要并发安全队列，优先考虑：
- 用
chan：天然并发安全，适合生产者-消费者模型，但容量固定、无法随机访问 - 用
sync.Mutex包裹切片实现简单队列：适合控制精细、需自定义行为（如阻塞等待、超时） - 避免自己实现无锁队列：除非你清楚 CAS 循环、ABA 问题和内存序，否则大概率引入竞态
最常被忽略的一点：很多所谓“并发安全需求”，其实源于设计缺陷——比如本该用 channel 传递所有权，却非要多个 goroutine 共享一个 struct 字段去改。先想清楚“为什么必须共享”，比急着选容器更重要。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
