值类型变量默认栈分配，但逃逸分析可能移至堆；用go build -gcflags="-m"查看，含“escapes to heap”即堆分配；返回指针必逃逸，值返回通常不逃逸；make/new 创建的对象底层数据总在堆上。
值类型变量默认在栈上分配，但逃逸分析可能把它“推”到堆上——这不是语法决定的，而是编译器根据使用方式做的自动判断。
怎么知道一个 int 或 struct{} 到底分配在栈还是堆？
用 go build -gcflags="-m" main.go 查看逃逸分析结果。输出中出现 ... escapes to heap 就说明该变量被分配到了堆。
- 没逃逸：局部变量只在函数内使用、没取地址、没传给 goroutine → 栈分配
- 逃逸了：返回了指针（
&x）、作为参数传给异步调用（go f(&x)）、赋值给全局变量或 map/slice 元素 → 堆分配 - 大对象（如超大 struct）即使没显式逃逸，也可能被编译器直接扔到堆，避免栈帧过大
为什么 return &T{} 一定逃逸，而 return T{} 通常不逃逸？
值返回（T{}）本质是拷贝一份数据，调用方拿到的是副本，原栈帧销毁不影响它；而指针返回（&T{}）意味着外部要持有对“这个内存”的引用，但原栈帧马上就要弹出——所以编译器必须把 T{} 分配到堆上，确保生命周期足够长。
- 反例：如果写
func f() *int { x := 42; return &x }，x必然逃逸，go build -gcflags="-m"会明确提示x escapes to heap - 注意：哪怕
x是int这种小类型，只要取地址并返回，就逃逸——大小不是唯一标准，语义才是
用 make 或 new 创建的值，一定在堆上吗？
是的。make([]int, 10)、make(map[string]int)、new(*int) 这些操作生成的对象，其底层数据结构（底层数组、哈希桶、新分配的零值内存）都由运行时在堆上分配。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
-
make返回的是引用类型（slice/map/channel），它们本身是栈上的 header（含指针、长度、容量等字段），但指向的数据在堆上 -
new(T)总是返回*T，且T的内存一定在堆上（因为你要通过指针访问它，必须保证长期有效） - 例外极少：某些极小、无逃逸的
new(int)在特定版本 Go 中可能被优化掉，但不可依赖，应视作堆分配
性能影响和常见误判
栈分配快、无 GC 开销；堆分配慢、增加 GC 压力。但别过早优化——95% 的场景下，编译器选得比人准。真正该警惕的是“隐式逃逸”。
- 把局部变量塞进
interface{}可能触发逃逸（尤其当接口方法集非空时） - 向
[]interface{}追加值：每个元素都会被装箱，大概率逃逸 - 日志打印时传入结构体指针（
log.Printf("%+v", &s)）→s逃逸，不如传值或用字段显式打印 - 用
go tool compile -S main.go看汇编，可确认是否真的分配了堆内存（搜CALL runtime.newobject）
最易被忽略的一点：逃逸分析发生在编译期，不看运行时行为。哪怕你逻辑上“肯定不会跨函数用”，只要代码写法符合逃逸条件，它就在堆上——编译器不猜意图，只看语法事实。
