s[i:j]截取共享底层数组，写操作会意外修改原切片；s[i:j:k]通过限制容量避免透传；需独立副本时用copy；字符串截取须转[]rune防UTF-8截断。
s[i:j] 截取出来的子切片默认共享底层数组，改它可能悄悄改掉原数据——这不是 bug，是设计，但必须主动防御。
为什么 s[i:j] 会意外影响原切片
截取不复制数据，只复制切片头（指针、len、cap），新旧切片指向同一段底层数组。只要没触发扩容，任何写操作都会透传。
- 常见错误现象：
s1 := []int{1,2,3,4,5}; s2 := s1[2:4]; s2[0] = 99→s1变成[1 2 99 4 5] - 使用场景：高频读、临时视图（如 HTTP body 分块解析）适合共享；写入或传递给不可信函数时危险
- 参数差异：
s[i:j]中i和j是下标，不是长度；j最大只能等于原切片的cap()，超了直接 panic - 性能影响：零分配、O(1)，但换来的是隐性耦合——调试时很难发现谁在改这个数组
s[i:j:k] 三参数截取怎么封住容量
第三个参数 k 不是“最大长度”，而是“新切片能用到的底层数组最远下标（不含）”，它硬性限制了 cap 上限，让后续 append 更可控。
- 容量计算公式：
cap(sub) == k - i，和原切片的cap无关 - 示例：
arr := [5]int{1,2,3,4,5}; sub := arr[1:3:3]→len(sub)=2,cap(sub)=2；再append(sub, 99)就会分配新数组，arr完全不受影响 - 容易踩的坑：
k超出原底层数组长度（比如arr[1:3:10]）会 panic，不是越界返回空，而是运行时报错 - 典型用途：从一个大缓冲区里切一小段交给 parser 处理，防止 parser 内部
append撑爆缓冲区剩余空间
什么时候该用 copy 而不是截取
当你需要一份独立副本，且明确不希望任何写操作波及原始数据时，copy 是唯一轻量又确定的方案。
立即学习“go语言免费学习笔记（深入）”；
- 正确写法：
dst := make([]int, len(src)); copy(dst, src)—— 注意make长度要够，copy不会自动扩容 - 别用
append([]int{}, src...)：看似简洁，但每次调用都新建底层数组 + 复制，性能差且语义模糊 - 常见误判：认为
s[:] == s是深拷贝，其实只是完全等价的视图，len/cap/ptr全相同 - 兼容性注意：对
nil切片调用copy(dst, src)是安全的（返回 0），但copy(dst, nil)会 panic
字符串截取为什么不能直接用 s[i:j]
Go 字符串底层是只读字节数组，s[i:j] 按字节切，UTF-8 编码的中文、emoji 很容易被从中截断，导致 invalid UTF-8 或 panic。
- 错误现象：
s := "你好"; s[1:2]→ 可能 panic 或输出乱码，因为“你”占 3 字节，s[1]是中间字节 - 正确做法：先转
[]rune，再切，再转回：rs := []rune(s); string(rs[1:3]) - 性能权衡：每次转换都要遍历解码整个字符串，高频场景（如日志行解析）要考虑缓存
[]rune或改用strings包的语义函数（如strings.IndexRune） - 边界检查不能省：
len([]rune(s))才是真实字符数，len(s)是字节数，混用必越界
真正难的不是记住语法，是每次写 s[i:j] 时，心里得过一遍：这段内存，我敢让它和别人共享吗？
