go指针生命周期核心在于变量可达性、共享引用与gc可见性；需用-gcflags="-m"查逃逸，pprof和setfinalizer查持有链，-race检并发，c交互时手动管理内存。
Go 指针不是“可选技能”，而是理解变量生命周期、函数参数行为和结构体方法调用的底层钥匙。不搞清 & 和 * 的语义边界，写出来的代码容易在并发场景或大对象传递时出 silent bug。
为什么 & 不能对常量或字面量取地址？
Go 编译器只允许对“可寻址的值”使用 &。常量、字面量（如 42、"hello"）、函数调用返回值（如 time.Now()）都不具备内存地址——它们没有被分配到变量槽位中。
常见错误现象：cannot take the address of ... 编译失败。
-
&42❌ 编译报错；必须先赋给变量：x := 42; p := &x✅ -
&fmt.Sprintf("a")❌ 报错；需先存为变量：s := fmt.Sprintf("a"); ps := &s - 切片字面量
[]int{1,2,3}本身不可取址，但它的元素可以：&[]int{1,2,3}[0]❌（整个字面量无地址），a := []int{1,2,3}; &a[0]✅
*p 解引用前必须确保 p != nil
nil 指针解引用会直接 panic：panic: runtime error: invalid memory address or nil pointer dereference。这不是编译期检查，而是运行时崩溃。
容易踩的坑：函数返回指针但未判空就直接用。
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
- 调用
json.Unmarshal后的*T值可能为 nil（比如 JSON 字段缺失且字段类型是*string），直接fmt.Println(*p)就崩 - 构造函数（如
NewXXX()）返回*T，但内部逻辑可能因错误返回 nil，调用方没检查就obj.Method()→ panic - 正确做法：始终显式判空，尤其在处理外部输入或第三方库返回值时：
if p != nil { use(*p) }
指针接收器 vs 值接收器：方法能否修改原始结构体？
结构体方法的接收器类型决定它能否修改调用者数据。这不是语法糖，而是内存模型的直接体现。
关键判断依据：接收器是否指向原结构体实例的内存地址。
- 值接收器
func (s S) Mutate() { s.field = 1 }→ 修改的是副本，原结构体不变 - 指针接收器
func (s *S) Mutate() { s.field = 1 }→ 直接写入原内存位置，生效 - 混用风险：若一个结构体既有值接收器方法又有指针接收器方法，调用时 Go 会自动取址或解引用，但仅限于“地址可得”的变量；对临时值（如
S{}.Method()）只能调用值接收器方法 - 最佳实践：只要方法需要修改字段，或结构体较大（避免拷贝），一律用指针接收器
指针逃逸：为什么局部变量有时被分配到堆上？
Go 编译器通过逃逸分析决定变量分配在栈还是堆。& 操作是主要逃逸触发器之一——一旦变量地址被传出函数作用域，它就必须在堆上分配，否则返回后地址失效。
影响实际性能：堆分配 + GC 压力，比纯栈操作开销高。
-
func f() *int { x := 10; return &x }→x逃逸到堆（因为地址被返回） -
func f() int { x := 10; return x }→x留在栈，无额外开销 - 验证方式：加编译参数
go build -gcflags="-m" main.go，看输出是否有... moved to heap - 注意：即使没显式
&，闭包捕获变量、传给 goroutine 或 map/slice 元素也可能导致逃逸
指针边界的本质，是 Go 在“安全”与“可控”之间划的一条线：禁止指针算术、强制类型匹配、nil 检查不可绕过。真正难的不是语法，而是每次写 & 或 * 时，心里得清楚那个地址背后连着谁的生命期、谁的并发访问、谁的 GC 命运。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
