gogc=100在教学demo中易误导，因其在固定低负载下导致gc过于频繁（如每几毫秒触发），使学生误判为代码错误；而真实服务中该值才是cpu与内存的平衡点。
为什么GOGC=100在教学Demo里反而容易误导
默认GOGC=100在真实服务中是平衡点，但在教学场景下常导致学生误判内存行为。比如一个简单HTTP handler反复创建[]byte，堆增长快、GC频繁触发，学生看到runtime.ReadMemStats里NumGC飙升，就以为“代码写错了”，其实只是阈值太激进。
- 教学代码通常分配节奏固定、无真实负载，
GOGC=100会让GC每几毫秒就跑一次，掩盖了对象生命周期的真实模式 - 初学者调试时习惯加
runtime.GC()，但runtime.GC()会阻塞当前goroutine，且不等待清理完成，在main函数末尾调用可能根本没效果 - 真正该观察的是
HeapAlloc和HeapSys的差值，而不是GC次数——很多教学示例里HeapAlloc只涨不跌，其实是对象还在被变量引用，不是GC失效
学生做内存泄漏练习时GOMEMLIMIT比GOGC更管用
教学生识别泄漏，重点不是“GC没运行”，而是“GC运行了但内存没下来”。这时候设GOMEMLIMIT比调GOGC更直接有效——它强制GC在接近上限时介入，且一旦超限会panic，错误信息明确指向内存失控。
-
GOMEMLIMIT=128*1024*1024（128MB）对教学环境足够，比盲目调低GOGC更能暴露持续增长的map或slice缓存 - 注意
GOMEMLIMIT从Go 1.19起才支持，低于该版本设了也无效，学生用旧版SDK时会发现环境变量完全不起作用 - 配合
GODEBUG=gctrace=1，能看到每次GC后heap goal是否逼近GOMEMLIMIT，这是判断泄漏是否存在的硬指标
用debug.SetGCPercent替代环境变量更适合课堂演示
在代码里动态改GC阈值，比设环境变量更可控，也避免学生忘记清掉GOGC影响后续实验。但debug.SetGCPercent有隐藏约束：它只对后续GC生效，且不能设为负数或零（会panic）。
- 必须在
init()或main()开头调用，放在HTTP handler里毫无意义——GC策略是全局的，不是按请求切换的 - 设成
debug.SetGCPercent(500)能让GC变得非常懒，适合演示“分配多但回收少”时内存如何缓慢爬升 - 设成
debug.SetGCPercent(-1)会禁用GC，但仅限调试，生产环境绝对不要这么干；学生试完必须重启进程，否则后续所有实验都卡在内存满状态
pprof heap profile里最容易被忽略的两个字段
学生看go tool pprof -http=:8080 <binary><heap></heap></binary>时，盯着flat和cum看哪行代码分配最多，却常漏掉inuse_objects和inuse_space的实际含义。
-
inuse_objects反映当前存活对象个数，如果某结构体inuse_objects持续上涨，大概率是map没删key、slice没截断——不是分配快，是没释放 -
inuse_space才是真实内存占用，但要注意它不含OS预留但未使用的页，所以HeapSys可能比inuse_space大得多，这不是泄漏，是分配器预占 - 导出svg后放大看调用栈，箭头指向的“leaf function”才是真凶，上层wrapper函数只是中转，别一看到
json.Unmarshal就去优化它
GOGC文档里，但决定了学生看到的数字到底代表什么。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
