会，因为切片值传递时ptr指向同一底层数组，修改已有元素生效，但append扩容后ptr指向新数组，原切片不受影响，需显式返回并重赋值。
Go切片传参时修改底层数组会影响原切片吗
会，但仅限于修改已有元素，不包括追加新元素。因为切片本身是值传递（含 ptr、len、cap 三个字段），函数内拿到的是原切片的副本，但这个副本里的 ptr 指向同一块底层数组。
常见错误现象：append 后原切片没变、索引赋值却生效了、函数里重赋值 s = append(s, x) 对调用方完全无影响。
- 修改已有索引：如
s[0] = 100→ 原切片可见变化 - 用
append超出原cap→ 底层新分配数组，原切片不受影响 - 函数内重新赋值切片变量（如
s = s[1:]或s = append(s, ...)）→ 不改变调用方的变量值
如何让函数内 append 的结果反馈给调用方
必须显式返回新切片，并由调用方重新赋值。Go 没有“引用传参”语法糖，append 是纯函数式操作，它不修改旧切片，只返回新切片。
使用场景：需要动态扩展数据并持续使用扩展后的结果，比如解析日志行、累积错误、构建响应体。
立即学习“go语言免费学习笔记（深入）”；
示例：
func addLog(logs []string, msg string) []string {
return append(logs, msg)
}
// 正确用法
logs := []string{"start"}
logs = addLog(logs, "done") // 必须重新赋值
- 不返回、不赋值 →
logs仍是原长度 - 传入
&[]string（指向切片的指针）虽可行，但违背 Go 习惯，且无法避免误用append后忘记解引用 - 如果函数逻辑复杂、多次
append，统一在末尾return最终结果最安全
为什么 cap 突破后原切片就“断连”了
因为 append 在底层数组容量不足时，会调用 growslice 分配更大内存块，把旧数据拷贝过去，再返回指向新地址的切片。此时函数内切片的 ptr 已指向新地址，而原变量仍指向旧地址。
性能影响：频繁触发扩容会带来拷贝开销；更隐蔽的问题是——你以为在累积数据，其实只在操作一个临时副本。
- 可通过
len(s) == cap(s)预判下一次append是否扩容 - 若已知大致长度，用
make([]T, 0, estimatedCap)预分配，减少意外断连 - 调试时打印
uintptr(unsafe.Pointer(&s[0]))可验证是否指向同一地址（仅调试用，勿进生产）
切片作为结构体字段时的陷阱
结构体复制时，其内的切片字段也是值复制：ptr、len、cap 全拷一份，所以两个结构体仍共享底层数组。这和单独传切片参数行为一致，但更容易被忽略。
容易踩的坑：把结构体塞进 map 或 slice 后反复修改其切片字段，结果多个结构体实例互相干扰。
- 如果结构体需独立数据，初始化时用
append([]T{}, src...)深拷贝切片内容 - 如果只是读取或只写不扩容，共享底层数组反而节省内存，无需额外处理
- 注意
json.Unmarshal等反序列化默认会新建底层数组，不会延续原有共享关系
append 前，心里默问一句：“我接下来的操作，会不会让这个切片的 ptr 指向别处？” 
