Go字符串不可变，底层为只读字节切片；修改需转[]byte再转回string，但避免频繁转换；切片应预分配容量防扩容抖动；返回局部变量会逃逸到堆；goroutine泄漏主因是channel阻塞或select缺default。
字符串不可变但底层是字节切片，别用 s[i] = 'x' 改单个字节
Go 的 string 类型在语法上禁止修改，编译器会直接报错 cannot assign to s[i]。这不是限制，而是设计保障：字符串底层用 StringHeader{Data uintptr, Len int} 表示，指向只读内存页。强行绕过（比如用 unsafe.String + unsafe.Slice 转成 []byte 再改）会导致未定义行为，尤其在字符串常量或编译期优化后地址不可写。
日常开发中常见误操作：
- 想“原地”修改字符串某字符，结果写
s[0] = 'A'→ 编译失败 - 用
[]byte(s)转换后修改，再转回string(b)→ 正确，但注意每次转换都分配新底层数组（小字符串走栈缓存，>32B 走堆） - 对同一字符串反复做
[]byte↔string转换 → 频繁堆分配，GC 压力上升
建议：需要频繁编辑，直接用 []byte；仅读取或拼接，保持 string；拼接多段时优先用 strings.Builder，比 + 或 fmt.Sprintf 少 2–3 次内存分配。
slice 扩容规则影响性能，make([]T, 0, n) 预分配很关键
切片的 append 在容量不足时触发扩容：小于 256 字节按翻倍增长，≥256 字节按 1.25 倍增长。这意味着如果初始没预设容量，一个从空开始追加 1000 个元素的切片，可能经历多次底层数组复制（如 0→1→2→4→8→…→1024），实际拷贝字节数远超最终大小。
立即学习“go语言免费学习笔记（深入）”；
典型踩坑场景：
- 循环中无脑
result = append(result, item)，result初始为[]T{}→ 扩容抖动明显，pprof 显示runtime.growslice占 CPU 热点 - 已知长度却写
make([]T, len(data))→ 长度和容量相同，后续append仍会扩容 - 从数组截取切片未考虑原数组生命周期 → 如
s := arr[1:3]，只要s还活着，整个arr都不能被 GC
改进做法：确定最终长度时，用 make([]T, 0, estimatedCap)；不确定但有上限，按上限预估；需复用底层数组时，显式传入 cap 并检查是否足够。
函数返回局部切片或指针，逃逸分析决定它在栈还是堆分配
Go 编译器通过逃逸分析判断变量是否“逃出”当前函数作用域。若函数返回了某个变量的地址（如 &x）或切片（如 xs，其 Data 指向内部数组），该变量就会被分配到堆——哪怕它看起来很小。
例如：
func newBuf() []byte {
buf := make([]byte, 64) // 64B，在栈分配？错：因为返回了，必须堆分配
return buf
}这个 buf 一定逃逸到堆，即使只有 64 字节。而：
func process(buf []byte) int {
for i := range buf {
buf[i]++
}
return len(buf)
}这里的 buf 不逃逸，参数传入的是 SliceHeader 副本，底层数组若来自调用方栈帧（如 make([]byte, 64) 在 caller 中），就仍在栈上。
容易被忽略的点：
-
fmt.Sprintf返回的string总是堆分配（内部用了strings.Builder） - 闭包捕获局部变量 → 变量逃逸
- interface{} 包装值类型 → 若值较大或需动态调度，常触发堆分配
验证方式：go build -gcflags="-m -l" main.go，看输出中是否有 ... escapes to heap。
goroutine 泄漏比内存泄漏更隐蔽，select 缺默认分支或 channel 未关闭是主因
goroutine 一旦启动，除非自己退出或被调度器回收（极少见），否则一直存活。泄漏常发生在 channel 通信场景：发送方往无缓冲 channel 发数据，但接收方永远不读；或 select 等待多个 channel，但没写 default 分支，导致 goroutine 挂起阻塞。
真实例子：
go func() {
select {
case ch <- data:
// 缺 default！如果 ch 已满或被关闭，此 goroutine 永久阻塞
}
}()或：
ch := make(chan int)
go func() {
for range ch { /* 处理 */ } // 如果 ch 永远不 close，这个 goroutine 永不退出
}()排查建议：
- 用
runtime.NumGoroutine()定期打点，突增即可疑 - pprof 查
/debug/pprof/goroutine?debug=2，看堆栈里大量 goroutine 停在chan send或selectgo - 所有 channel 使用方，明确谁负责 close；用
context.WithCancel控制生命周期更可靠
最麻烦的不是泄漏本身，而是泄漏的 goroutine 可能持有其他资源（文件句柄、DB 连接、大内存 slice），这些不会自动释放。
