slice本身不是并发安全的，因为其底层共享数组在多goroutine调用append或读写同一索引时可能触发扩容或覆盖，导致静默数据错乱或panic。
为什么 slice 本身不是并发安全的，但很多人误以为它“看起来能用”
因为 slice 是一个包含指针、长度和容量的结构体，它的底层数据（底层数组）是共享的。多个 goroutine 同时调用 append 或读写同一索引位置，可能触发底层数组扩容或覆盖——这时不是“报错”，而是静默数据错乱或 panic。
常见错误现象：fatal error: concurrent map writes 虽然这句错误不提 slice，但它常和 slice 混用 map 的场景一起出现；更隐蔽的是某个 goroutine 看到 slice 长度突变、元素值被意外覆盖，却无任何日志。
- 使用场景：Web handler 中把请求参数塞进全局
results []string，多个请求并发执行时出错 -
append不是原子操作：先检查容量 → 若不足则分配新数组 → 复制旧数据 → 写入新元素。中间任何一步被抢占，其他 goroutine 就可能看到不一致状态 - 性能影响：加锁保护整个 slice 会严重限制吞吐；用
sync.Mutex锁住单个操作成本低，但锁粒度太粗容易成为瓶颈
sync.Map 不能替代 slice，但很多人拿它当“并发 slice”用
sync.Map 是为 map[string]interface{} 类型优化的并发安全映射，它不提供顺序访问、不支持索引、没有 len() 原子性保证，更不兼容切片的内存布局。把它当并发版 []int 用，等于硬套错工具。
典型误用：用 sync.Map 存一堆带序号的值，再循环 Load 出来拼成 slice——结果发现 key 是字符串、遍历无序、性能比加锁 slice 还差。
立即学习“go语言免费学习笔记（深入）”；
- 正确替代方案取决于场景：需要追加用
chan+ 单独 goroutine 收集；需要随机读写考虑sync.RWMutex包裹 slice；需要高并发计数用atomic.Int64 - 兼容性注意：
sync.Map在 Go 1.9+ 引入，老项目若需兼容 1.8 及以下，必须换方案 - 别忽略 GC 压力：
sync.Map内部用 read/write 分离 + 延迟清理，大量写入后不及时Range或Load，可能堆积 stale entry
数组字面量 [3]int 是值类型，但“并发安全”不等于“能随便读写”
数组是值类型，赋值会拷贝全部元素，所以多个 goroutine 各自持有一份副本，彼此修改互不影响——但这只在**不共享该数组变量**的前提下成立。一旦通过指针、闭包或结构体字段暴露出去，就立刻失去这个保障。
容易踩的坑：定义 var buf [1024]byte 作为缓冲区，在 HTTP handler 中直接传给 io.ReadFull(&buf, r)，然后启动 goroutine 处理 buf[:n] ——此时多个请求共用同一块栈内存，buf 内容被覆盖。
- 使用场景：固定大小配置项（如
[16]byte的 token）、小尺寸只读查找表可放心用数组 - 参数差异：
func f(a [3]int)和func f(a *[3]int)完全不同：前者传值，后者传指针，后者必须手动同步 - 性能提示：大数组（如
[1）传参会引发显著栈拷贝开销，Go 编译器不会自动优化，应改用 slice + 显式拷贝逻辑
真正安全的并发切片操作，往往要放弃“直接操作”这个念头
Go 的并发哲学不是“让所有数据结构都线程安全”，而是“用 channel 和 goroutine 划清所有权边界”。想安全地累积结果？别让多个 goroutine 往同一个 slice 写，改用 chan 把数据推给 collector goroutine；想并行处理切片元素？用 for i := range s 分段，每段起独立 goroutine，各自处理局部 slice，最后合并。
复杂点在于：你得判断“谁拥有这块内存”。底层数组是否会被其他 goroutine 扩容？当前 slice 是否只是某个更大 slice 的子视图？这些细节不厘清，加锁也救不了。
- 推荐模式：
make(chan T, 100)+range接收，避免缓冲区满阻塞；用sync.WaitGroup控制生产者退出时机 - 别信“我只读不写就安全”：如果另一个 goroutine 正在
append同一底层数组，读 goroutine 可能读到部分初始化的内存（尤其是 struct 字段未初始化时） - 容易被忽略的地方：struct 中嵌入
[]byte字段，该 struct 被多个 goroutine 共享时，字段本身不是并发安全的——哪怕你只读 struct，只要有人在改其 slice 字段，就危险
