io.limitreader不修改原*os.file，仅返回新io.reader；必须将返回值赋给新变量并全程使用，否则限制失效。
用 io.LimitReader 包装文件读取器，但必须换掉原变量
io.LimitReader 不修改原始 *os.File，只返回一个新 io.Reader。如果你调了 io.LimitReader(f, 1024*1024) 却继续用 f.Read(buf)，限制完全失效。
- 必须把返回值重新赋给变量：
limited := io.LimitReader(f, 1024*1024)，后续所有读操作都走limited -
*os.File支持Seek，但io.LimitReader不封装该方法——调用会 panic；如需 seek + 限长，改用io.SectionReader - 它不关闭底层文件，
defer f.Close()仍要保留，且不能漏掉
别用 bufio.Scanner 读大文件，显式设缓冲上限
bufio.Scanner 默认允许单次扫描最大 64KB，遇到超长行（比如嵌了 base64 的日志）会无节制扩容，瞬间吃掉几百 MB 内存，而你毫无感知。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 创建后立刻调
scanner.Buffer(make([]byte, 4096), 1024*1024)，把 max 设为 1MB，禁用自动增长 - 对纯字节流，优先用
io.ReadFull或复用[]byte分块读：buf := make([]byte, 64*1024)+ 循环io.ReadFull(f, buf) -
scanner.Text()每次返回新字符串，底层复制 bytes；大量短行也会因频繁分配推高峰值
测真实内存峰值，得关 GC + 高频采样 runtime.ReadMemStats
runtime.ReadMemStats 只拍快照，不自动记录历史最高值。一次调用看到的 Alloc 或 HeapAlloc 很可能不是峰值——尤其 buffer 分配/释放的尖峰很容易被漏掉。
- 测试前加
debug.SetGCPercent(-1)暂停自动 GC，否则回收动作会压低Alloc，掩盖真实压力 - 在读取循环中高频采样，比如每处理 1MB 就调一次
runtime.ReadMemStats(&ms)，自己维护max(ms.HeapAlloc) - 别依赖
ps或top：它们显示的是瞬时 RSS，不是生命周期内最高值；/proc/self/status中的VmHWM更准，但只在进程退出后稳定
容器环境必须设 GOMEMLIMIT，且要对齐 cgroup limit
Go 运行时缓存堆内存（mcache、mspan 等），runtime.ReadMemStats().Alloc 常远低于实际 RSS。Kubernetes 杀进程看的是 RSS，不是 Alloc——没设 GOMEMLIMIT，runtime 就不会主动配合 cgroup 限界。
-
GOMEMLIMIT必须设为容器memory.limits的 80%～90%，单位是字节（如512Mi→4294967296） - 必须在启动前设置（Dockerfile
ENV或docker run -e），运行时改无效 - Go 1.22+ 的自动推导不可靠，务必手动验证：
cat /sys/fs/cgroup/memory.max和os.Getenv("GOMEMLIMIT")对比是否接近
io.LimitReader、bufio.Scanner、io.Copy 多种抽象，只要一处绕过限制，峰值就崩。建议统一入口做 Reader 封装，并在关键节点 assert 当前 ms.HeapAlloc 是否超标。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
