runtime.ReadMemStats 是唯一可靠获取 GC 周期外瞬时堆内存峰值的方式，需高频采样 Alloc/HeapAlloc 并手动取最大值，同时禁用 GC 干扰；bufio.Scanner 默认缓冲易致内存暴增，须显式限制缓冲大小。
用 runtime.ReadMemStats 抓真实内存峰值
Go 的 runtime.ReadMemStats 是唯一能可靠反映 GC 周期外瞬时堆内存压力的方式，Alloc 和 HeapAlloc 字段最相关——但它们只在调用时刻快照，不自动跟踪“历史最高”。很多人误以为跑完 ReadMemStats 一次就能看到峰值，其实不然。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 在文件读取循环前后各调一次
ReadMemStats，还不够；必须在关键路径中高频采样（比如每读 1MB 就采一次），否则大 buffer 分配/释放的尖峰会被漏掉 - 注意 GC 干扰：测试前加
debug.SetGCPercent(-1)暂停自动 GC，否则Alloc可能被回收动作压低，掩盖真实占用 - 采样结果别只看单次最大值，要记录
HeapAlloc序列，再用max()手动算出峰值——Go 不提供内置“内存监控器”
bufio.Scanner 默认 64KB 缓冲会吃掉你的峰值
用 bufio.Scanner 读大文件很常见，但它默认的 MaxScanTokenSize 是 64KB，且内部缓冲区会随输入动态扩容。一旦某行超长（比如日志里嵌了 base64 图片），buffer 可能暴涨到几百 MB，而你完全没感知。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 显式限制：在
scanner := bufio.NewScanner(f)后立刻调用scanner.Buffer(make([]byte, 4096), 1，把 max 设为 1MB，避免无节制增长 - 换更可控的方案：对纯字节流，直接用
io.ReadFull或分块io.Read+ 复用[]byte，比Scanner更容易盯住内存 - 警惕
scanner.Text()：它每次返回新字符串，底层复制 bytes，大量短行也会因频繁分配推高峰值
Linux /proc/[pid]/status 的 VmHWM 更准，但得手动解析
VmHWM（High Water Mark）是内核记录的进程生命周期中物理内存使用最高值，单位 KB，比 Go 自身统计更贴近真实 RSS。但它只在进程退出后才稳定，运行中读取有延迟，且需权限读取 /proc。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 测试脚本末尾加一段：打开
/proc/self/status，逐行扫描匹配^VmHWM:，用strconv.ParseInt提取数值——比依赖 runtime 更硬核 - 别用
ps或top实时抓：它们显示的是采样瞬间 RSS，不是历史峰值，且受调度干扰大 - 注意容器环境：Docker/K8s 中
/proc/[pid]/status仍有效，但若用了 memory limit，VmHWM可能被 cgroup 截断，需同步检查/sys/fs/cgroup/memory/memory.max_usage_in_bytes
复用 []byte 能压平峰值，但别碰错边界
反复 make([]byte, n) 是内存飙升主因。用 bytes.Buffer 或预分配切片复用底层数组，可让峰值下降 50%+。但复用时越界或残留数据，会导致读错、panic 或隐蔽 bug。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 固定大小读取：用
buf := make([]byte, 1 配合 <code>io.ReadFull(f, buf)，读完立即buf = buf[:0]重置长度，不清零内容（性能关键） - 避免
copy(dst, src)时 dst 太小：提前检查len(dst) >= len(src)，否则 panic 或静默截断 - 如果逻辑需要多次拼接，用
bytes.Buffer比手动管理[]byte更安全，它的Bytes()返回的切片可复用底层数组
真正难的不是测出峰值数字，而是确认那个峰值对应哪一行代码触发的 buffer 分配——得结合 pprof heap profile 的 inuse_space 视图，按调用栈过滤，否则光看总量毫无意义。
