Go切片本身不会内存泄漏，但s=s[100:103]仅修改Len和指针偏移，Data仍指向原底层数组，只要该数组被任一变量引用，GC就无法回收，导致10MB内存滞留。
Go 切片本身不会“泄漏内存”，但会拖住整个底层数组不放——哪怕你只用其中 3 个字节，背后可能锁着 10MB 的数组。
为什么 s = s[100:103] 后 RSS 不降
切片赋值或截断（如 s = s[n:]）只是改了 Len 和指针偏移，Data 字段仍指向原底层数组起始地址。只要还有任意一个变量（包括全局变量、结构体字段、闭包捕获值）持有对该数组的引用，GC 就不能回收它。
- 典型场景：从
make([]byte, 1 创建的大缓冲区里切出几字节 header，传给 HTTP handler 或存进 map —— 整个 1MB 数组就卡住了 - 结构体字段陷阱：
type Packet struct { Data []byte }，若直接赋值p.Data = bigBuf[1024:1032]，该Packet实例生命周期内，bigBuf底层数组一直存活 - 函数返回子切片：如
func sub(b []byte) []byte { return b[:4] }，调用方拿到的切片和原始b共享底层数组，哪怕b已离开作用域
如何切断引用：用 make + copy，别信 [:0] 或 nil
slice = slice[:0] 或 slice = nil 只是让当前变量“松手”，但底层数组仍被其他地方拽着；真正有效的是换一块新内存。
- 安全复制（推荐）：
newSlice := make([]byte, len(oldSlice)) copy(newSlice, oldSlice)
- 只取前 N 个：
newSlice := make([]byte, N) copy(newSlice, oldSlice[:N])
- 一行写法（语义清晰但略低效）：
newSlice := append([]byte(nil), oldSlice...) - 绝对避免：
oldSlice = oldSlice[:0]、oldSlice = nil、oldSlice = oldSlice[:N]—— 这些都不换底层数组
字符串切片也要当心：s = s[n:] 可能拖住大 []byte
字符串底层结构类似切片（ptr + len），但没有公开 cap。若字符串来自 string(bigByteSlice)，再反复切片，就会持续引用整个 bigByteSlice 底层数组。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 风险代码：
data := make([]byte, 1<<16) s := string(data) // s 持有整个 64KB 数组 s = s[1000:1005] // 仍拖着全部 64KB
- 解耦方案：
s = string([]byte(s)) // 触发新分配，旧数组可回收 // 或更高效： b := make([]byte, len(s)) copy(b, s) s = string(b)
- 预防原则：大文本处理优先用
[]byte，仅在需要不可变性或标准库接口时转string
验证是否真释放：别看 pprof，查 runtime.ReadGCStats
RSS 稳定不等于内存已回收，操作系统未必立刻归还；pprof 的堆分配趋势也容易误判。要确认底层数组是否被 GC，得看 GC 统计本身。
- 关键指标：
NumGC是否递增、LastGC时间戳是否推进 - 操作前后各调一次：
var stats runtime.GCStats runtime.ReadGCStats(&stats) fmt.Println("GC count:", stats.NumGC, "last:", stats.LastGC) - 必要时加
runtime.GC()强制触发（仅限调试，禁止上线） - 如果
NumGC没变，说明没回收——十有八九还有活跃引用藏在某个结构体字段或 map value 里
最难的不是写出那三行 make + copy，而是意识到 config.Headers = raw[8:12] 这一行代码，已经悄悄把整个网络包缓冲区钉在内存里了。
