因为 slice 是值传递的 header（指针+len+cap），修改元素通过指针影响共享底层数组，而 append 返回新 header，原变量未赋值故不变；扩容时 header 指针更新，未扩容时仅 len 变化但仅作用于副本。
为什么修改 slice 元素能影响原 slice，但 append 却不行
因为 []int 是值类型，传参时复制的是 slice header（array 指针 + len + cap），不是底层数组本身。所以 a[0] = 1 实际是通过指针改了共享的底层数组，而 a = append(a, x) 是给这个 header 的拷贝重新赋值——新 header 可能指向新数组（扩容时），原变量 header 完全不受影响。
常见错误现象：append 后原 slice 长度、内容都没变；调试时发现函数内 fmt.Println(a) 有新元素，但调用方打印还是旧的。
- 扩容触发条件：当
len(a) == cap(a)时，append必然分配新底层数组 - 不扩容时：
append只改 header 的len字段，但该修改仅作用于参数副本 - 验证方式：在函数内打印
&a[0]和调用方的&s[0]，扩容后地址不同，未扩容时相同
append 在函数内生效的三种可靠写法
想让 append 的结果回到调用方，必须让修改“穿透”参数副本。不能靠返回值？可以，但得显式接收；不能靠指针？其实可以，但要注意语法。
- 返回新 slice：
func f(s []int) []int { return append(s, 1) }，调用方必须写s = f(s) - 传 slice 指针：
func f(s *[]int) { *s = append(*s, 1) }，调用方传&s - 预分配足够容量避免扩容：
s := make([]int, 0, 10)，再传入函数，此时append不会换底层数组，但依然只改副本 header —— 所以仍需返回或指针，仅预分配不够
性能提示：频繁扩容会引发内存重分配和拷贝，make([]int, 0, expectedCap) 是更可控的做法，但不解决传参语义问题。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
为什么 copy 有时比 append 更安全
当你需要在函数内构造一个与原 slice 独立的新 slice（比如防止并发读写冲突、或避免意外修改上游数据），copy 是明确的深拷贝手段，而 append 的行为依赖容量状态，不可控。
-
copy(dst, src)总是复制元素值，不共享底层数组 - dst 必须已初始化且长度 ≥ src 长度，否则只拷贝 min(len(dst), len(src)) 个元素
- 典型误用：
dst := []int{}; copy(dst, src)→ dst 长度为 0，啥也不拷；正确写法：dst := make([]int, len(src)); copy(dst, src) - 注意：这仍是浅拷贝，若 slice 元素是 struct 指针或 map，内部引用仍共享
容易被忽略的底层数组共享陷阱
多个 slice 指向同一底层数组时，一个 slice 的修改可能“悄悄”影响另一个，尤其在子切片（s[2:5]）、append 未扩容、或函数传参场景下。
- 例子：
s := []int{1,2,3,4,5}; s1 := s[1:3]; s2 := s[2:4]; s1[0] = 99→s2[0]也变成 99，因为都指向s的第 2 个元素 - 子切片
append未扩容时，会覆盖原数组后续位置，可能破坏其他 slice 视图 - 并发场景下，若多个 goroutine 同时写不同 slice 但共享底层数组，会引发 data race ——
go run -race能捕获，但逻辑上已错
真正隔离数据，要么用 copy 显式分离，要么从头 make 新 slice 并手动赋值；别依赖 “看起来没改原 slice” 就认为安全。
