深挖Go语言指针：不可寻址值全解析 + unsafe内存操作黑科技，面试必考
做Go开发久了，你会发现一个很有意思的现象：很多人写了两年Go，天天用指针，但一碰到cannot take the address of ...这个编译错误就懵了。更别提面试官追问一句“map的value为什么不可寻址”“字符串底层数组能不能通过unsafe改”这类问题，能答得清清楚楚的人真不多。
我最初也是踩了一堆坑才把这些细节理顺。今天这篇文章就专门把Go语言指针里最绕的两个点一次性讲透：一个是不可寻址值的判定规则和底层原因，另一个是unsafe包做内存操作的黑科技玩法。这两块内容恰好也是Go面试里出现频率最高的进阶考点，尤其是大厂一面二面，基本跑不掉。建议程序员的收藏夹里留一个位置，硬核程度对得起你的收藏。
1. Go指针的本质：不是C语言那种“万能钥匙”
1.1 指针到底是什么，Go指针和C指针的差异
很多从C/C++转过来的Go程序员，一开始会把Go指针当成C指针用，结果处处碰壁。原因很简单：Go的指针是“受控指针”，它保留了C指针的“引用内存地址”这个核心语义，但砍掉了两个危险能力：指针运算和隐式类型转换。
var p *int n := 10 p = &n fmt.Println(*p) // 10这就完了。你不能做p++，不能把*p当数组首地址去遍历后面几个元素，也不能把int*强行转成byte*去读内存。这种设计换来的代价是编译器能做更严格的逃逸分析、垃圾回收和内存安全检测。在Go这个有GC的语言里，指针只是“引用”的显式表达，而不是玩内存的万能钥匙。
但这并不代表Go内存不可操作。Go留了一个后门，就是unsafe.Pointer。它可以把任意类型的指针转换成另一种类型的指针，甚至把uintptr当内存地址来读写。这也是本文第二大部分要展开的内容，你先把“受控指针”的约束记住，后面看unsafe能打破多少约束就特别有意思。
1.2 值、地址、可寻址（addressable）的基本语义
要理解不可寻址，得先明确Go语言里“可寻址”的精确定义。官方文档Go spec里对addressable的定义是：一个变量、指针引用、切片索引表达式、可寻址结构体的字段、可寻址数组的索引等，都是可寻址的。而字面量、map索引表达式、类型转换结果、函数调用返回值等，都是不可寻址的。
这句话信息量很大。可寻址的本质，是编译器知道这个值在内存中有一个确定的、固定的位置。只有存在固定内存位置，你才能对它取地址（&x），才能通过地址去修改它。反过来，如果一个值是临时生成的、只存在于寄存器或堆栈的计算中间态，没有对应的持久内存空间，那它就没有“地址”可言。
用生活类比来说：可寻址的值相当于你租了一个长租房，门牌号是固定的，你随时可以把快递寄到那里。不可寻址的值相当于你在路上临时叫的一辆网约车，它有一个实时位置，但那个位置下一秒就变了，你不能把快递寄到“这辆车的实时坐标”上。
理解了这个本质，后面所有不可寻址值的规则都可以推导出来，而不是死记硬背。
2. 不可寻址值全解析：哪些值不能取地址
2.1 字面量、常量与临时结果的取地址陷阱
最容易踩坑的就是字面量不可寻址。下面这行代码直接编译报错：
p := &10 // go vet会报，编译器直接报错：cannot take the address of 10为什么字面量不可寻址？因为10这个值是一个常量，它在编译期间就被编码进二进制指令里了，程序运行时并没有一个“存放10的变量内存”。如果你强行取地址，你得先把它放到内存里，那这个过程就必须显式地用一个变量来接住它。所以正确写法是：
n := 10 p := &n接口值的临时结果同理。函数返回的string、int、结构体等，都是临时值，它们被返回后会被赋值给变量，或者直接用作表达式的一部分，但你对返回值本身取地址也不行。
func getNum() int { return 100 } p := &getNum() // 编译错误：cannot take the address of getNum()这是面试里很经典的判断题。就算你把返回值改成指针返回，也不一定能直接取地址，要看返回的是什么类型。
另外，类型转换的结果也不可寻址。比如&int64(3)、&float64(x)这种都是非法的。不过字符串转字节切片这种属于内置转换，结果同样不可寻址，只能在变量里先存一下。
2.2 map索引结果的不可寻址问题：面试高频
map索引大概是平时开发里遇到“不可寻址”报错最多的地方。不管你是m["key"]还是v, ok := m["key"]，得到的结果都不可寻址。
m := map[string]int{"a": 1} p := &m["a"] // 编译错误：cannot take the address of m["a"]原因有两层：
第一，map内部是哈希表，在插入、删除、扩容时，key/value的存储位置会发生移动。如果你拿到了一个value的内存地址，下一次map扩容后这个地址就失效了，变成悬垂指针。Go语言为了安全，直接禁止对map元素取地址，从语言层面堵死了这个漏洞。
第二，Go里把map的value设计成不可寻址，换来的是map的实现可以更加自由（比如存放元素的桶是连续内存，但扩容时会整体搬迁）。如果你非要改map里的value怎么办？
- 如果value是结构体，你可能会想
m["a"].Name = "x"，但这也是不允许的，因为map索引结果不可寻址，自然不能给它的字段赋值。 - 正确做法是先把value取出来修改，再放回去：
type User struct { Name string Age int } m := map[string]User{"a": {Name: "Tom", Age: 20}} u := m["a"] u.Age = 21 m["a"] = u- 或者，把map的value定义为指针类型。这在实际工程中非常常见，也是规避不可寻址问题的最优雅方案：
m := map[string]*User{"a": {Name: "Tom", Age: 20}} m["a"].Age = 21 // 直接修改，因为value是指针，这里“m["a"]”返回的是指针，指针本身是地址的拷贝，你可以通过指针去修改指向的内容注意，这里本质上仍然是“取出指针值，通过指针修改目标”，而不是对map元素本身取地址。这个区别面试时一定要说清楚，这是加分项。
2.3 切片索引与数组索引的“双标”行为
切片和数组的索引表达式是否可寻址，是面试容易埋伏笔的点。直接给结论：数组的索引是可寻址的，切片的索引也是可寻址的。
arr := [3]int{1, 2, 3} p := &arr[0] // 可以，把p指向arr[0] sli := []int{1, 2, 3} q := &sli[0] // 可以为什么切片可以？因为切片的底层数组在堆或栈上有固定内存，索引表达式解析后就是“底层数组第n个元素的地址”，这个地址是稳定的。虽然切片本身可能扩容后底层数组会换，但只要不触发扩容，索引地址是合法的。
但是有个陷阱：切片作为参数传递，如果你在函里直接对形参的索引取地址，这个地址还存活，但要注意形参是值传递的引用结构。这里不展开，重点是下面这个面试常见题：
sli := make([]int, 3) sli = append(sli, 4) p := &sli[3]这个合法吗？合法。因为切片的索引元素确实存在于底层数组中，可寻址。真正坑的是切片字面量的索引表达式，比如：
s := &([]int{1,2,3}[0]) // 这个居然合法！因为复合字面量在求值时会被求值为临时变量，可以寻址这个边界很多资料没讲透。Go spec里允许“复合字面量”的元素取地址，因为复合字面量在内存中是有实际存储的（要么栈上要么堆上），编译器会为其分配存储。所以&[]int{1,2,3}[0]是可以的。但&[3]int{1,2,3}[0]同样可以。唯一不行的是单独的普通字面量，比如&1不行，因为数字字面量没有存储空间，它只是一个常量的抽象表示。
2.4 字符串索引、range迭代变量和for循环变量
字符串底层是字节数组，但字符串是只读的。所以&"abc"[0]是禁止的，因为就算你拿到地址，也不应该允许你去修改字符串的字节内容。这是字符串不可变设计的一部分。如果你想读字符串某个字节，可以用s[i]，但只能读不能写。
for range迭代变量同样是一个不可寻址的坑。来看这段代码：
sli := []int{1, 2, 3} for _, v := range sli { p := &v // 这个v是可寻址的，但要注意所有的迭代都共用同一个变量v }这里的v是一个循环变量，它在循环体外部声明，每次迭代只是被重新赋值。它的地址是固定的（同一块内存），所以取地址合法，但取到的永远是同一个地址，所有迭代里保存的指针都指向同一个变量，最终值会是最后一次迭代的值。这不是“不可寻址”，而是“共享变量”的经典问题。Go 1.22以后，循环变量作用域有了变化，不再共享，但旧版本坑依然存在。面试官喜欢问：
下面代码输出什么？
func main() { s := []int{1, 2, 3} var ps []*int for _, v := range s { ps = append(ps, &v) } for _, p := range ps { fmt.Print(*p, " ") } }Go 1.21及之前，输出是3 3 3。Go 1.22之后，新语义输出1 2 3。这就是迭代变量地址副作用在语言层面的修复。但Go 1.22也还是要求迭代变量可寻址，它本身是变量，自然可寻址，只是共享与否的问题。
另外，for循环里的循环变量也是可寻址的，不过也可能涉及闭包捕获的共享问题，这个就不展开了，属于另一个范畴。
2.5 结构体字面量、函数返回值与其他不可寻址特例
结构体部分很多人搞混。看三个例子：
type User struct { Name string Age int } p := &User{"Tom", 20} // 合法，复合字面量可寻址 u := User{"Tom", 20} q := &u.Age // 合法，u是变量，u.Age可寻址 r := &(User{"Tom", 20}.Age) // 非法，因为User{...}虽然是复合字面量，但其字段访问结果的寻址规则是：只有可寻址结构体的字段才可寻址。临时结构体字面量不是变量，它是不可寻址的，所以字段也不可寻址最后一个例子是不是很反直觉？复合字面量本身可以取地址，但如果你想直接对它的字段取地址，编译器会判非法。所以你必须先tmp := User{...}，再对tmp.Age取地址。这也是面试中容易设陷阱的点。
再补充几个不可寻址的特例：
- 类型转换结果：
&time.Duration(3)非法。 - chan接收结果：
v := <-ch这种可以，但&(<-ch)非法，因为接收表达式不是变量。 - 函数调用返回值：已经是老生常谈了。
- 切片字面量的完整表达式：前面说了，切片复合字面量可寻址，但
(&[]int{1,2,3})[0]与普通索引一样可寻址，这里没问题。 *p指针解引用结果：如果p是变量，&*p合法，甚至可以简写成p。但如果p是复杂表达式，要小心：&*getPtr()这种要分情况，getPtr返回的是一个指针的临时值，虽然解引用可寻址，但取地址操作通常会被优化成直接拿指针，实际编译是允许的。这里不再深挖，遇到以后最好是先存进变量。
2.6 不可寻址值的实际危害：方法集与接口陷阱
不可寻址值还牵涉到Go方法集的一个经典问题：不可寻址的值不能调用其指针接收者方法。
在Go里，定义方法时可以选值接收者还是指针接收者。如果一个值是不可寻址的，那么编译器无法自动生成取地址代码，因此你不能对它调用指针接收者的方法。
type Counter struct { Count int } func (c *Counter) Inc() { c.Count++ } func getCounter() Counter { return Counter{Count: 0} } func main() { getCounter().Inc() // 编译错误：cannot call pointer method Inc() on getCounter() }因为getCounter()的返回值是不可寻址的临时值，Inc方法需要*Counter接收者，编译器无法将临时值取地址，于是报错。把方法改成值接收者func (c Counter) Inc()就没问题了，因为改的是拷贝，但副作用不会生效。
这个考点在接口那里更常见：如果某个类型的方法集里包含指针接收者方法，那么只有该类型的指针类型才实现了这个接口。值类型即使有这个方法的“定义”，但由于不可寻址的临时值无法调用它，编译器干脆就认为值类型不包含该方法。
type Incrementer interface { Inc() } func accept(i Incrementer) {} var c Counter accept(&c) // 可以，*Counter有Inc方法 accept(c) // 编译错误：Counter没有Inc方法这个逻辑如果你理解“不可寻址值不能调用指针接收者方法”这个底层规则，就不用死记接口规则了。
3. unsafe内存操作黑科技：打破规则的正确姿势
3.1 unsafe.Pointer到底是什么，三个类型的转换规则
unsafe.Pointer是Go里的一个特殊指针类型，它有如下特性：
- 它可以指向任意类型的值。
- 它不能直接做算术运算（不能偏移）。
- 它不能直接解引用（不能
*p）。 - 但它可以在任意普通指针类型和
uintptr之间相互转换。
转换规则有两个经典图示：
T1* -> unsafe.Pointer -> T2*任何类型的普通指针都能转成unsafe.Pointer，unsafe.Pointer也能转回任意类型的指针。这一步的意义是绕过类型系统，把内存里的数据“重新解释”成另一种类型。
unsafe.Pointer -> uintptr -> unsafe.Pointer只有通过uintptr，你才能对地址做加减运算，然后转回指针去访问偏移后的内存。这里有个极其重要的警告：uintptr是一个整数，不是指针。GC不会把uintptr当作引用，因此当对象被GC移动或回收时，uintptr里保存的地址不会得到更新（其实Go的GC目前是non-moving，即不移动对象，但在某些场景下仍有过期风险，比如栈扩容时指针会重新调整，uintptr不会跟随调整）。所以在实际使用中，原则就是：转换链要在一个表达式内完成，不要在变量中保存uintptr后跨语句使用。
3.2 unsafe.Sizeof、Offsetof、Alignof的用法与原理
这些函数属于Go的预定义函数，由编译器直接支持，返回的是编译期常量。
unsafe.Sizeof(x)：返回x类型所占内存大小（字节数），不包含动态部分。比如unsafe.Sizeof("abc")返回的是字符串头的大小，是16字节（在64位系统上，data指针8字节+len 8字节），而不是3字节。很多新手会踩坑。unsafe.Offsetof(x.field)：返回结构体字段相对于结构体起点的偏移量。可以用来计算字段对齐。unsafe.Alignof(x)：返回类型的对齐系数，决定了字段在内存中的放置位置。
这三个函数经常被用来手动分析结构体内存布局。比如下面这个结构体：
type S struct { A bool // 1字节 B int32 // 4字节 C int64 // 8字节 }在64位平台上，由于对齐规则，A后面需要填充3个字节，B占4字节，然后C从偏移8开始，整个结构体大小是16字节。用unsafe.Offsetof可以验证：Offsetof(S.B) == 4，Offsetof(S.C) == 8。这类问题在内存优化时会非常有用，你可以通过调整字段顺序来减少填充浪费。
3.3 经典黑科技一：Go string和[]byte零拷贝互转
这是面试必问的高频技巧。string底层结构是reflect.StringHeader（32位上是两个字段的变体），slice底层结构是reflect.SliceHeader。零拷贝互转的思路就是利用unsafe.Pointer直接改写头信息，避免内存拷贝。
先看代码，然后解释原理。
func StringToBytes(s string) []byte { if s == "" { return nil } return unsafe.Slice(unsafe.StringData(s), len(s)) } func BytesToString(b []byte) string { if len(b) == 0 { return "" } return unsafe.String(unsafe.SliceData(b), len(b)) }这里用的是Go 1.20之后引入的unsafe.StringData、unsafe.SliceData、unsafe.String、unsafe.Slice这几个更加安全的“黑科技”函数。它们比直接操作StringHeader和SliceHeader更安全，因为编译器知道这些是把数据解释成string/slice。转换后得到的[]byte是只读的，如果被修改会直接崩溃或者产生未定义行为。所以本质上：这个技巧适合“只读场景”，比如字符串内容的Hash计算、正则匹配前的转换（只读）、HTTP header查询等。
在Go 1.20之前，标准的转换方式是这样：
func StringToBytes(s string) []byte { return *(*[]byte)(unsafe.Pointer(&s)) }这个做法是构造一个slice header，Data指向string的Data，Len等于string长度，Cap也等于长度（因为string没有容量概念）。注意这里没有改Cap，也没法改，但作为只读切片没问题。Go 1.20以后，unsafe.StringData和unsafe.Slice是官方推荐的替代方案。
3.4 经典黑科技二：操作结构体私有字段
在Go里，如果你import别的包，你是无法访问那个包的未导出字段的，不管你是值还是指针。但用unsafe可以突破封装，直接修改私有字段。这在有些性能敏感或调试场景下很有效，但在生产代码里风险也很大。
比如有个包定义：
package secret type Request struct { url string method string }在外部想修改req.url，可以这样：
req := &secret.Request{} pUrl := (*string)(unsafe.Pointer(uintptr(unsafe.Pointer(req)) + unsafe.Offsetof(req.url)))但这个写法太危险，因为req.url未导出，unsafe.Offsetof(req.url)在外部包中访问私有字段是不能编译的。更好的做法是用reflect+unsafe的组合，或者直接使用字段偏移量硬编码，但那极度脆弱。我不推荐在生产中这么干，但理解原理有助于你阅读某些黑科技库或框架源码。
更安全的“伪私有字段修改”场景是在同一个包内，或者使用reflect的unsafe_NewAt之类的工具。这里主要理解unsafe突破访问限制的能力即可。
3.5 经典黑科技三：手动构造切片头和字符串头
老牌黑科技是完全绕过类型系统，用reflect.StringHeader和reflect.SliceHeader来构造底层结构，比如把一个数组的一部分直接当作切片用，而不用与切片赋值粘连。
func ArrayToSlice(arr *[10]byte) []byte { var sl []byte header := (*reflect.SliceHeader)(unsafe.Pointer(&sl)) header.Data = uintptr(unsafe.Pointer(arr)) header.Len = 10 header.Cap = 10 return sl }这种方式在Go 1.17之前非常流行，因为当时unsafe.Slice还不存在。但现在建议使用unsafe.Slice更安全简洁：
func ArrayToSlice(arr *[10]byte) []byte { return unsafe.Slice(&arr[0], 10) }注意，如果数组是局部变量，你将它的内存作为slice返回，要注意逃逸分析：数组可能被复制到堆上，而arr[0]的地址在函数返回后是有效的，只要该slice还在使用，GC会追踪它。这比uintptr安全得多。
手动构造字符串头的风险也一样：你构造出的string的Data指向一块内存，但如果你没有正确管理生命周期，GC可能认为这块内存已经不可达而将其回收，导致悬垂指针。所以一定不要裸用reflect.StringHeader去瞎拼Data，优先用Go 1.20+的unsafe.String。
3.6 经典黑科技四：直接读取/修改任意内存地址
结合uintptr可以做指针偏移，实现对一块连续内存的“手动遍历”。来看一个遍历int数组的例子：
arr := []int{1, 2, 3, 4, 5} base := unsafe.Pointer(&arr[0]) size := unsafe.Sizeof(arr[0]) for i := 0; i < len(arr); i++ { eleAddr := uintptr(base) + uintptr(i)*size ele := *(*int)(unsafe.Pointer(eleAddr)) fmt.Println(ele) }这个示例在arr不扩容的前提下是安全的：arr[0]是数组第一个元素，底层内存连续，后面4个元素的地址可以通过偏移算出。但如果你拿到地址后，另一个goroutine对切片做append触发扩容，原地址就失效了，继续读写就是野指针。所以这类黑科技只适合不并发的场景，而且建议把整个偏移逻辑都包在一个没有其他操作的单线程段落里。
另一个经典的应用是修改string底层字节。虽然string不可变，但如果你通过unsafe拿到它的Data并转成可读写的[]byte，你是能够改掉那块内存的。不过如果该字符串恰好是字符串常量（编译期只读数据段），直接修改会触发段错误崩溃。我这里不给你展示可运行代码，因为风险太高，面试时点到为止就够了。
3.7 unsafe的坑：uintptr不是指针，别收藏地址过夜
这是unsafe里最核心的安全红线。uintptr只是内存地址的整数表示，它不参与GC对象图的构建。如果你写这样的代码：
ptr := unsafe.Pointer(&obj) u := uintptr(ptr) // 此时obj可能被GC回收，或者由于栈扩展，u里的地址已失效在Go的当前实现中，GC不会移动堆上普通对象，所以堆上对象地址基本稳定，但栈上的对象会随着栈扩容、缩容而移动。一旦goroutine的栈发生增长，老的栈内存会被拷贝到新栈，所有指向旧栈的指针都会被更新，但u这个整数不会被更新。于是u就成了指向旧栈的悬垂地址。这也是为什么go vet特别警告不要这样写。
为了安全，标准做法是让uintptr转换和后续使用在同一个表达式内，编译器可能可以识别并保护对象生命周期。极端情况还是建议用反射或者unsafe.Slice这类隐式保留引用的方式，不要让地址脱离指针类型单独存储。
4. 实战：手写高性能内存操作与面试题拆解
4.1 用unsafe实现高效结构体序列化/反序列化（简单版）
序列化通常用encoding/json，但性能差。对于固定内存布局的结构体，我们可以直接用unsafe把结构体内存当成字节数组读写。这个方法在某些特殊场景很有用，比如网络协议里格式固定的报文头。
先看一个简化版：
type Header struct { Version uint8 Type uint8 Length uint16 Flags uint32 } func HeaderToBytes(h *Header) []byte { return unsafe.Slice((*byte)(unsafe.Pointer(h)), unsafe.Sizeof(*h)) } func BytesToHeader(b []byte) *Header { return (*Header)(unsafe.Pointer(&b[0])) }这里HeaderToBytes返回的切片直接引用了h的内存，修改切片内容等于修改结构体。这个转换的本质就是：结构体在内存中按照对齐规则紧凑排列（这里有填充），底层的字节就是它的内存表达。unsafe.Sizeof(*h)正好是结构体占用的总字节数。
注意：如果结构体里有字符串或切片这类引用类型，这个“序列化”只会拷贝头信息（指针和长度），不会拷贝底层数据，不能直接用于持久化存储或网络传输。适合的场景是固定大小的数值类型结构体，而且机器字节序必须一致。如果协议要求大端序，你还需要手动转换字节序。因此这东西极少数情况下才能用，但能极大提升性能。
4.2 利用unsafe将float64按位转成uint64并进行比较
Go的浮点数不能直接用==比较，因为涉及NaN和-0。但在内存层面，浮点数的IEEE 754表示可以用来做位运算。比如想快速检查float64的符号位：
func SignBit(f float64) uint64 { return (*(*uint64)(unsafe.Pointer(&f))) >> 63 }通过把float64的内存解释成uint64，取出最高位。原理：float64由1位符号位+11位指数位+52位尾数位组成。这比用math.Float64bits更底层，两者效果一致，但后者会更安全地道。这个例子说明unsafe能让你在二进制层面操作任何值。
面试题：math.Float64bits和这个unsafe转换有何区别？答：math.Float64bits是安全的标准库封装，内部实现也用了unsafe，但对外保证行为；而unsafe转换则暴露了内存解释的细节，更“硬核”也更危险。实际工程建议首选标准库函数。
4.3 结构体内存布局优化：调整字段顺序，减小内存占用
unsafe的Sizeof、Alignof最实际的工程价值就是结构体内存布局分析。我们可以先写出愚蠢版本，再用unsafe验证：
type Bad struct { A bool // 1 B int64 // 8 C bool // 1 } // 实际占用：alignof int64=8，结构体大小：A占1，填充7，B占8，C占1，然后填充到对齐倍数8，总共24字节 type Good struct { B int64 // 8 A bool // 1 C bool // 1 } // 实际占用：B占8，A占1，C占1，总共10字节，对齐到8，总共16字节通过调整字段顺序，一个结构体从24字节降到16字节，节省了33%。在大量实例的场景（比如缓存对象、网关计数），这种优化非常可观。
写个小程序验证：
fmt.Println(unsafe.Sizeof(Bad{})) // 24 fmt.Println(unsafe.Sizeof(Good{})) // 16 fmt.Println(unsafe.Offsetof(Bad{}.B)) // 8面试官如果问“如何知道struct大小”，你就从内存对齐和unsafe.Sizeof两个角度回答，同时给出这个小实验，基本稳了。
4.4 高质量面试高频题：这些代码段输出什么
我来整理几道自己面试别人时必问的题，大家可以自测。
第一题：能不能编译通过？
m := map[string]int{"a": 1} v := m["a"] p := &v答案：能。v是变量，可寻址。但这个v是map中value的拷贝，修改*p并不会改到m["a"]。很多人以为拿到了地址就能改原值，这里必须澄清。
第二题：下面哪里出错？
type S struct { X int } s := []S{{1}, {2}} p := &s[0].X答案：没问题。s[0]是切片索引表达式，可寻址，字段也可寻址。
第三题：map里存struct，为什么不能直接修改字段？
m := map[string]struct{ X int }{"a": {1}} m["a"].X = 2 // 报错答案：map索引表达式不可寻址，因此也不允许给不可寻址结构体的字段赋值。解决办法：定义成指针map，或者取出拷贝改完再放回。
第四题：unsafe.Pointer和uintptr转来转去，什么时候有风险？
答案：uintptr不引用对象，在栈扩容或GC移动（当前Go GC不移动堆对象，但栈会移动）后可能失效。保存uintptr并跨语句使用就是危险的。
第五题：有一个字符串常量，用unsafe转成[]byte再去修改，会怎样？
答案：未定义行为，可能导致崩溃（segment fault），因为字符串常量的内存可能被放在只读段。
第六题：空结构体struct{}{}的地址是什么？
答案：Go对空结构体有特殊优化，所有空结构体变量的地址可能相同，是zerobase。通常指向一个全局的零地址变量。这个不算不可寻址，但它的大小是0。
4.5 避坑总结：Go指针与unsafe的最佳实践
用Go指针本身没什么坑，但一碰unsafe就要格外小心。基于我多年实践，整理几条最重要的经验：
第一，不要存储uintptr，除非你是专家且明确的知道生命周期。实在需要存地址，请使用unsafe.Pointer而不是uintptr。因为unsafe.Pointer本身是指针类型，GC会保留指向的对象，对象不会提前被回收。
第二，不要用unsafe绕过只读约束去修改字符串。字符串不可变的约定是整个标准库都依赖的，你一旦修改，Hash表、map key、字符串比较、并发安全全部可能出问题。
第三，零拷贝转换的[]byte只能读不能写。即使你通过unsafe转换获得了可写接口，也别写。如果你要大量修改字符串内容，老老实实复制一把。
第四，使用Go 1.20+的新API：unsafe.Slice、unsafe.String、unsafe.StringData、unsafe.SliceData是官方给出的更安全转换工具，尽量使用它们，而不要自己用reflect.StringHeader和reflect.SliceHeader拼凑。在Go 1.20+里，reflect.StringHeader也被标记为deprecated了（虽然还能用，但官方建议不用）。这些都是底层内存操作，任何时候都要先确认对象的生命周期覆盖使用范围。
第五，警惕栈逃逸与栈扩容。如果你把一个局部变量的地址传给另一个函数，甚至保存起来，编译器可能让这个变量逃逸到堆上，那么栈上地址就是堆上地址，GC会正常管理。但如果地址变成了uintptr，GC不知道它还在引用堆对象，对象可能被回收。所以“指针的引用”这个语义一旦丢失，后果自负。
第六，做代码审查时，看到unsafe要强制解释生命周期。我自己的团队规定：unsafe只能出现在特定性能敏感模块，并且必须有注释说明为什么安全。任何普通业务代码里出现unsafe，一律打回。这条规范值得所有团队借鉴。
5. 延伸：unsafe在Go源码和底层库中的应用
很多人觉得unsafe只是面试考点，实际生产用不到。其实不然，Go标准库和很多知名项目里unsafe无处不在。只是它们封装在底层的安全的API下面，用户感知不到。
典型例子：
sync.Pool内部用unsafe来减少锁粒度。encoding/json在处理反射时大量使用unsafe。strings.Builder的String()方法，内部用unsafe把[]byte转成string而不发生拷贝：
func (b *Builder) String() string { return unsafe.String(unsafe.SliceData(b.buf), len(b.buf)) }runtime和reflect包内部更是大量使用unsafe来实现内存级操作。golang.org/x/sys/unix里的BytePtrFromString、Uintptr等，也依赖unsafe。
如果你想成为Go专家，读这些源码时就会频繁看到unsafe.Pointer。懂这些黑科技，不是为了让你到处用，而是为了让你能看懂这些底层库在做什么，甚至能在关键时候改出高性能代码。
6. 结语：把不可寻址和unsafe串起来理解
回头再看，Go的指针其实代表着一种设计哲学：普通操作受编译器保护，关键操作可以通过unsafe打开后门，但打开后门的代价由程序员自己承担。
不可寻址值的本质是“这个值没有稳定的内存位置”，而unsafe所做的，恰恰是在某些特定场景下，绕过“没有稳定内存位置”的限制，直接用指针偏移去操作底层内存。两者一对照，你会发现：Go语言的安全边界是有意设计出来的，不是随意定的。
在我写Go的这些年里，这两块知识帮我解决过不少问题，也帮我在面试中拿过加分。面试官喜欢深挖一个点问到底，如果你能把他从“不可寻址”引导到“unsafe零拷贝”再到“内存对齐”，他就知道你对Go的理解不是浮于表面。这套思路也能套用在日常工作里，排查性能问题时，知道哪里可以大胆用unsafe，哪里必须避免，本身就是一种工程能力。
最后再分享一个我自己的小习惯：凡是用到unsafe的代码，我习惯在函数上方写一小段注释，说明“为什么这里必须用unsafe、这里的内存生命周期如何保证、如果未来修改需要注意什么”。这个习惯救过我很多次，因为三个月后你自己回来看代码，真的会忘记当时为什么这么做。如果你也想把Go指针玩得更透，建议从今天开始，在编译器报“cannot take address”的地方多停一下，问问自己：“这个值为什么不可寻址？它是什么时候进入内存的？”想通这个，你对Go的运行时模型就上了一个台阶。
