Golang指针能做什么？指针使用限制详解

Go语言指针并非功能残缺，而是经过精心设计的安全抽象：它明确支持取地址、解引用、传参、作为方法接收者及结构体字段访问，但坚决禁止指针算术、对不可寻址值（如字面量、map元素、函数返回值）取地址以及隐式类型转换——这些限制不是疏漏，而是编译器主动封堵的危险路径；理解何时必须用指针（修改原值或避免大对象拷贝）、何时应避免（小结构体传值更高效）、以及那些不会panic却更致命的“逻辑野指针”陷阱（如并发竞争、切片中悬垂指针、违背生命周期的设计误用），才是写出健壮、可维护Go代码的关键。

Go 指针能做的操作很明确：取地址、解引用、传参、作为方法接收者、访问结构体字段（语法糖支持），但**不能做指针算术、不能对不可寻址值取地址、不能隐式转换类型**——这些不是“功能缺失”，而是 Go 编译器主动封堵的危险路径。

哪些值 &v 会编译报错？

Go 编译器禁止对“不可寻址”的值取地址，防止语义混乱和悬垂风险。常见报错场景：

• &42 ❌ 字面量无内存地址
• &(x + y) ❌ 表达式结果是临时值，生命周期仅限当前语句
• &myMap["key"] ❌ map 元素地址不固定，Go 明确禁止
• &func(){}() ❌ 函数调用返回值不可寻址

✅ 正确做法：先赋给局部变量再取地址

val := myMap["key"]
val.Field = 100
myMap["key"] = val

为什么 *p 有时 panic，有时却能直接写 p.Name？

本质是 nil 检查时机不同：*p 是显式解引用，只要 p == nil 就 panic；而 p.Name 是语法糖（等价于 (*p).Name），同样会 panic —— 它们不是“安全”与“不安全”的区别，而是同一种检查。

• 所有对 nil 指针的读/写/方法调用都会 panic：p.Name、p.Greet()、*p
• 只有少数操作是安全的：if p == nil、fmt.Printf("%p", p)、reflect.ValueOf(p).IsNil()
• 结构体字段是指针时（如 type User { Profile *Profile }），必须确保 u.Profile != nil 才能访问 u.Profile.Age

传指针 vs 传值：什么时候真该用 *T？

核心就两条：要改原值，或值太大（通常 > 128 字节）。别被“结构体都要用指针接收者”带偏。

• 修改原值必须用指针：func increment(x *int) { *x++ }
• 大结构体（如含 slice/map/大数组）建议传指针，避免拷贝开销
• 小结构体（如 type Point { X, Y int }）传值更高效，逃逸分析友好，GC 压力小
• 切片、map、channel 本身是引用类型，传值即可共享底层数据；加 * 只在需要替换整个头信息时才必要（如函数内想让调用方看到新分配的底层数组）

容易被忽略的“逻辑野指针”场景

Go 不会出现 C 那种真正的野指针（栈地址被复用），但以下情况会导致“指针还活着，但指向的数据已失效或不该被改”：

• 多个 goroutine 并发读写同一 *T，没加 sync.Mutex 或没走 channel —— -race 一跑就出问题
• 切片中存了结构体指针：items := []*User{&u1, &u2}，后续又对 u1 重新赋值，items[0] 仍指向旧内存，但语义上可能已过期
• 返回局部变量地址虽被逃逸分析兜底（自动堆分配），但若该变量本应是短生命周期，长期持有其指针就违背设计意图

真正难防的不是 panic，而是那种“程序没崩，但行为不对”的共享误用——它不会报错，只会在某个并发时刻悄悄改掉你没意识到的字段。

今天带大家了解了的相关知识，希望对你有所帮助；关于Golang的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~