go指针禁止对不可寻址值取地址（如字面量、表达式结果、map元素、函数调用返回值），解引用nil指针必panic，传指针仅在需修改原值或值过大时必要。
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 —— 它们不是“安全”与“不安全”的区别，而是同一种检查。
立即学习“go语言免费学习笔记（深入）”；
- 所有对 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，而是那种“程序没崩，但行为不对”的共享误用——它不会报错，只会在某个并发时刻悄悄改掉你没意识到的字段。