会，只要没触发扩容，所有基于同一底层数组的切片共享内存；这是Go的设计选择，高效但需主动管理，修改子切片会直接改变原切片内容。
切片赋值后修改会影响原切片吗
会，只要没触发扩容，所有基于同一底层数组的切片共享内存。这不是 bug，是 Go 的设计选择——高效但需主动管理。
常见错误现象：append 后原切片内容意外改变；函数接收 []int 参数却悄悄改了调用方数据。
- 判断是否共享：用
unsafe.SliceHeader对比Data字段（仅调试用，生产禁用） - 安全隔离：用
make([]T, len(s), cap(s))+copy显式复制，例如newS := make([]int, len(oldS)); copy(newS, oldS) - 注意
append行为：当len(s) 时复用底层数组；超过则分配新数组，此时不再共享
为什么 append 有时共享、有时不共享
取决于当前切片容量是否足够容纳新增元素。Go 不会在每次 append 都分配新内存，而是按倍增策略扩容（小切片 2 倍，大切片 1.25 倍），这是性能与内存的权衡。
使用场景：批量构建切片时，预估容量能避免多次 realloc；但若后续要长期持有旧切片副本，必须提前分离。
立即学习“go语言免费学习笔记（深入）”；
-
s := make([]int, 0, 4)→append(s, 1,2,3,4)：仍在原数组，cap刚好用完 - 再
append(s, 5)：触发扩容，返回新底层数组，原s的旧引用失效（但变量仍指向旧地址，内容未变） - 参数传递中，
func f(s []int) { s = append(s, 1) }不影响调用方，因为s是值拷贝；但for i := range s { s[i]++ }会改原数据
如何检测切片是否已脱离底层数组
没有运行时 API 直接判断，但可通过 reflect 或 unsafe 获取底层信息——仅限诊断，不可用于逻辑分支。
更实用的做法是：默认假设共享，除非你明确做了复制或扩容后重新截取。
- 检查
len和cap变化：扩容后cap突增，大概率已换底层数组 - 观察指针行为：对两个切片分别取
&s[0]（需len > 0），地址相同即共享 - 避免依赖“是否共享”做逻辑分支——这会让代码脆弱。该复制时就复制，别赌扩容时机
在 HTTP handler 中传递切片要注意什么
典型坑点：从请求解析出的 []byte（如 http.Request.Body）被多个 goroutine 复用或缓存，结果读一次就清空，或并发写冲突。
根本原因：标准库多数 io.Read 实现会复用缓冲区，bytes.Buffer、json.Decoder 也倾向复用底层数组。
- 读取
Body后立即bytes.Clone（Go 1.22+）或append([]byte{}, data...)复制一份再处理 - 不要把 handler 接收的切片直接塞进 map 或全局缓存——下次请求可能覆盖内容
- 用
sync.Pool管理临时切片时，务必在归还前清零（for i := range b { b[i] = 0 }），否则残留数据会泄露
