Go 无传统指针悬挂但存在逻辑悬挂：指针有效却指向过期或语义非法数据；应避免返回局部变量地址、警惕切片/map/sync.Pool中指针失效、并发时保护共享指针、始终检查nil。
Go 里基本不存在传统意义上的指针悬挂（dangling pointer）——因为运行时的垃圾回收和逃逸分析会自动保障对象只要被引用，就不会被回收。但“逻辑悬挂”仍可能发生：指针还有效，指向的却是过期、被覆盖或语义上不该再访问的数据。关键不在内存是否释放，而在引用是否仍符合业务预期。
别返回局部变量地址（即使它能跑通）
虽然 Go 编译器会把被外部引用的局部变量自动逃逸到堆上，让 &x 返回后依然可用，但这容易掩盖设计意图，也增加维护风险。
- 避免写
func() *string { s := "hello"; return &s }这类代码，哪怕它不 panic - 优先用值返回或显式在堆上构造：
return &User{Name: "A"}或直接返回结构体 - 用
go build -gcflags="-m" main.go确认逃逸行为，但别依赖它来“救”不良习惯
警惕切片、map 和 sync.Pool 中的指针失效
这些容器内部可能重新分配底层数组或复用对象，导致原有指针指向的位置不再对应原数据。
- 不要长期保存
&slice[i]的指针，尤其在 slice 可能扩容或重切时 - 从
sync.Pool.Get()拿出的对象，需重置字段；不能假设其状态干净 - map 中存指针时，确保所指向的变量生命周期 ≥ map 本身；避免 map 存了
&localVar
并发场景下必须保护共享指针数据
多个 goroutine 同时读写同一指针指向的内存，不是悬挂，但会导致数据竞争——而竞态可能让指针“看起来”指向了错误内容。
- 用
sync.Mutex或sync.RWMutex保护指针所指向的结构体字段 - 更推荐方式：用 channel 传递指针，而非多个 goroutine 共享一个指针
- 加
-race编译运行，快速暴露潜在的读写冲突
始终检查 nil，别跳过这一步
nil 指针解引用是 Go 最常见的 panic 来源，它虽不是悬挂，但表现类似——访问了“不该访问的地方”。
- 函数接收指针参数时，第一行就加
if p == nil { return }或返回错误 - 构造函数如
NewXxx()应保证返回非 nil，或明确文档说明可能返回 nil - 用
govet和staticcheck工具自动捕获未判空的解引用
基本上就这些。Go 把底层悬挂挡在了语言机制之外，但开发者仍要对“指针该不该存在、该活多久、该被谁改”保持清醒。不复杂但容易忽略。
