go禁止(*int)(unsafe.pointer(&x))因类型系统强制校验对齐、存活与偏移，须经uintptr桥接；切片需用&buf[0]而非&buf取数据地址；uintptr非指针，gc不保护，转换须单表达式完成。
为什么 (*int)(unsafe.Pointer(&x)) 会编译失败
Go 编译器不是“不支持”，而是主动拒绝这种写法——它把 unsafe.Pointer 当作一道安全闸门，必须显式经过 uintptr 或 *byte 桥接，才能继续流转。直接写 (*int)(unsafe.Pointer(&x)) 会被报错 cannot convert unsafe.Pointer to *int。
这不是语法缺陷，是类型系统在强制你确认三件事：地址是否对齐、内存是否存活、偏移是否合法。跳过中间层，等于绕过校验。
-
&x是*int类型，可转为unsafe.Pointer -
unsafe.Pointer不能直转*int，但可转为uintptr -
uintptr再转回unsafe.Pointer，最后才转*int
正确单行写法：(*int)(unsafe.Pointer(uintptr(unsafe.Pointer(&x))))；拆开写也必须严格按此链，少一环就编译不过。
&slice[0] 和 &slice 的区别到底在哪
这是实际踩坑最密集的点。切片变量本身是个 header（含 data、len、cap 三个字段），&slice 拿到的是这个 header 结构体的地址，不是底层数组起始位置。
错误示例：(*Point)(unsafe.Pointer(&buf)) —— 它覆盖的是 header 内存，后续读 buf 可能 panic 或返回垃圾值。
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
- 要用
&buf[0]才真正指向数据首字节 -
buf长度必须 ≥unsafe.Sizeof(Point{})，否则越界 - 若
buf是局部[]byte，其底层数组可能被 GC 回收；推荐用make([]byte, n)（堆分配）或加runtime.KeepAlive(buf) - Go 1.17+ 更推荐
unsafe.Slice(&buf[0], n)，debug 模式下带边界检查，语义更清晰
uintptr 不是轻量指针，它是 GC 安全断点
uintptr 是整数，不是指针。GC 完全不认它，哪怕里面存的是有效地址，只要没其他 Go 指针引用原始对象，GC 就可能把它回收掉。
危险模式：u := uintptr(unsafe.Pointer(&x)); time.Sleep(100 * time.Millisecond); *(*int)(unsafe.Pointer(u)) = 42 —— 中间间隔里 &x 可能已被回收，解引用即野指针。
- 所有转换必须在单表达式内完成，不能有函数调用、不能存中间变量
- 跨函数传递时，必须传原始 Go 指针（如
*T），由接收方做转换；或在作用域末尾显式调用runtime.KeepAlive(x) - 把
uintptr存进 map、全局变量、闭包，等同于放弃 GC 保护
函数指针转换的唯一合法入口是 &fn
函数名本身（如 fn）不是地址，而是一个 callable 值；只有取它的地址 &fn，才能得到一个类型为 *func(...) 的指针，进而转为 unsafe.Pointer。
错误写法：unsafe.Pointer(fn) 会编译失败，因为 fn 不是指针类型；unsafe.Pointer(&fn) 也不对，因为 &fn 是 **func(...)，多了一层。
- 正确起点：
ptr := unsafe.Pointer(&fn)（注意是&fn，不是fn或&&fn） - 转回函数指针时，必须先转成目标签名的
*func(...)，再解引用：(*func(int) bool)(ptr) - 函数指针转换不参与 GC 跟踪，生命周期完全由你控制；一旦原始函数变量超出作用域，再调用就是未定义行为
真正难的从来不是怎么写对那一行转换，而是你得清楚知道哪块内存归谁管、对齐是否满足、GC 是否还在保活——这些信息不会出现在错误提示里，只会在 runtime panic 时沉默地崩掉。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
