因为切片是值传递的三字段结构体{ptr, len, cap}，s[0]=x通过共享指针修改底层数组，故生效；append返回新header，未显式赋值则原变量不变，扩容时更完全脱离原数组。

Go 里切片操作的“意外修改”和“内存泄漏”不是 bug，是结构决定的行为——只要理解 slice 是 struct{ptr *T, len, cap int} 的值拷贝，所有看似反直觉的现象都有解。

为什么传参后改 s[0] = x 会生效，但 s = append(s, x) 有时却没影响？

因为函数参数传递的是切片头（header）的副本，其中 ptr 指向同一底层数组。所以直接索引赋值 s[0] = x 总是写入原数组；而 append 是否影响外部，完全取决于是否触发扩容：

• 未扩容时：append 在原数组末尾写入，外部切片的底层数组内容被改，但长度（len）不变，所以 fmt.Println(s) 看不到新元素
• 扩容时：append 分配新数组、复制数据、返回新 header，函数内 s 指向新地址，外部原变量完全不受影响
• 判断依据只看 len(s) == cap(s)：相等即满，下一次 append 必扩容；不等则大概率复用原底层数组

用 s[i:j] 截取小切片后长期持有，为什么 RSS 持续上涨？

截取只是新建 header，ptr 仍指向原始大数组起始位置。只要这个小切片还活着，整个底层数组就无法被 GC 回收——哪怕你只留了 2 个字节，却锁住了几 MB 内存。

Golang Spf13 Viper

Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。

下载

• 典型场景：读大文件后 buf[1024:1032] 提取 header，然后把这 8 字节存进 map 缓存
• make([]byte, 0, cap(s)) 或 s[i:j:j] 都不能切断引用，它们只是控制后续 append 行为
• 真正有效的解法只有两个：copy(dst, s[i:j]) 或 append([]byte{}, s[i:j]...)（Go 1.22+ 推荐 bytes.Clone() 处理 []byte）

并发读写同一个切片，为什么加了 sync.RWMutex 还 panic？

锁只能保护 header 访问，但无法阻止多个 goroutine 同时往同一底层数组写——尤其是用 for range s 得到的 v 是元素副本，&v 却永远是栈上同一个地址，协程捕获它会导致所有 goroutine 修改同一份临时变量。

立即学习“go语言免费学习笔记（深入）”；

• 写操作必须通过索引：s[i] = newval，且确保 i 不越界、不冲突
• 避免在循环里起 goroutine 并直接传 v 或 &v；要传 s[i] 或显式拷贝：val := s[i]; go process(val)
• 如果需并发修改不同段，用 s[a:b] 和 s[c:d] 前先确认它们不重叠、且底层数组无共享（用 &s[0] 打印地址验证）

最易被忽略的点：切片的“安全边界”不在代码注释里，而在每次 append 前的 len(s) == cap(s) 判断、每次截取后的主动 copy、以及每次传参前对是否需要隔离的明确决策——没有银弹，只有每一步都清醒。