扩容后原切片完全不受影响，因为 append 返回新切片而非修改原切片；触发扩容的唯一条件是 len(s) == cap(s)，此时必新建底层数组，可通过打印 &s[0] 地址验证。
扩容后原切片完全不受影响，因为 append 返回的是新切片
Go 中 append 是纯函数式操作：它不修改原有切片头，而是返回一个新切片。即使你把切片传进函数、在函数内调用 append，只要触发扩容，新切片就指向全新底层数组，原切片的 ptr、len、cap 全部保持不变。
常见错误现象：modify(s []int) { s = append(s, 99) } 调用后外部 s 看起来“没变”，不是因为 append 失效，而是你没接收返回值——函数内 s 变量被重新赋值，但这个赋值只作用于形参副本。
- 形参
s是切片头（struct）的拷贝，修改它不影响调用方变量 - 扩容时
append返回的新地址不会自动同步回实参 - 未扩容时看似“生效”，其实是共享底层数组的副作用，不是预期行为
怎么判断一次 append 是否触发扩容
关键看当前长度是否已达容量上限：len(s) == cap(s) 时，下一次 append 必定新建底层数组。这不是经验猜测，而是 Go 运行时的确定性规则。
调试时可直接打印地址验证：fmt.Printf("%p", &s[0])，append 前后对比是否变化。注意：对空切片或 nil 切片首次 append 总会分配，此时也必然有地址变化。
立即学习“go语言免费学习笔记（深入）”；
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
-
cap是唯一决定扩容与否的字段，和当前len无关（只要len ，就不扩容） - 扩容策略分段：cap cap += cap / 4）
- 别依赖
cap大小来“防污染”——只要没扩容，哪怕cap很大，s[i] = x仍会改到原数组
想让函数内修改影响外部，必须显式返回并赋值
Go 不支持“引用传递”意义上的就地修改。要让扩容后的结果反映到调用方，唯一可靠方式是函数返回新切片，并由调用方重新赋值。
示例：
func extend(s []int, x int) []int {
return append(s, x)
}
// 使用：
s = extend(s, 99) // 必须接收返回值
- 不写
s = extend(...)，就等于什么都没做 - 结构体字段含切片时尤其危险：如
rule.Right = extend(rule.Right, "item")，漏掉赋值会导致逻辑错乱 - 多个
append连续调用时，每次都要接返回值，不能省略中间步骤
为什么传指针 *[]T 也不能绕过这个限制
传 *[]T 只能让你修改切片头本身（比如让指针指向别处），但它解决不了扩容导致的底层数组分离问题。更关键的是：一旦 append 内部扩容，它返回的新切片仍需手动解引用赋值，否则照样无效。
示例错误写法：
func badExtend(p *[]int, x int) {
*p = append(*p, x) // 看似正确？但若 *p 容量不足，append 返回新底层数组，*p 被更新——这确实生效了
}
// 但问题在于：调用方仍需传地址，且该函数无法区分扩容/未扩容场景，语义混乱
- 传指针增加了调用复杂度，却没带来本质收益
- 它掩盖了“切片操作本质是值返回”的设计哲学，反而更容易写出难以维护的代码
- 真正需要隔离修改时，应主动用
append([]T(nil), s...)或make+copy创建新底层数组，而不是依赖指针“强行绑定”
ptr 引用，未扩容的 append 和直接索引赋值就始终共享内存。 
