<p>Go 的 & 和 * 不会崩溃是因为编译器通过逃逸分析确保变量生命周期安全，而 unsafe.Pointer 绕过所有检查，解引用已释放或越界内存会导致 panic 或 crash；new(T) 安全分配堆内存，&x 由逃逸分析决定位置；nil 指针解引用 panic 是因访问无效地址，而非 nil 本身。</p>
为什么 Go 的 & 和 * 不会崩溃，但 unsafe.Pointer 会？
因为 Go 编译器对普通指针做了静态检查和逃逸分析：只要用了 &x，且该地址可能被函数外持有，x 就会被自动分配到堆上，GC 保证它存活。而 unsafe.Pointer 绕过了所有类型和生命周期检查，它只是个“地址容器”，一旦你把它转成 *T 去解引用，而此时原始内存早已释放或越界，就会直接 panic 或读到垃圾数据。
常见错误现象：
-
panic: runtime error: invalid memory address or nil pointer dereference（解引用 nil 指针） -
fatal error: unexpected signal during runtime execution（unsafe.Pointer转成错误类型后访问非法地址） - 程序偶发 crash，尤其在 GC 触发后——说明你用了
uintptr保存地址但没维持对象引用
实操建议：
- 永远优先用
*T，只在标准库级优化（如bytes.Buffer底层扩容）、CGO 交互、或零拷贝网络包解析时才考虑unsafe.Pointer - 用
go build -gcflags="-m"看变量是否逃逸，验证你的&x是否真被安全托管 - 如果必须用
unsafe.Pointer，务必确保：转换前对象仍可达；转换后立即转回*T使用，不长期持有unsafe.Pointer或uintptr
new(T) 和 &x 都返回指针，但它们的语义和风险点不同
new(T) 总是分配堆内存，返回指向零值 T 的 *T，安全无副作用；&x 是取已有变量地址，变量位置（栈 or 堆）由逃逸分析决定——这正是理解 Go 指针安全的关键入口。
立即学习“go语言免费学习笔记（深入）”；
使用场景差异：
- 想初始化一个可修改的空结构体？用
p := new(MyStruct)，不用先声明再取地址 - 想把局部变量暴露给外部作用域？写
return &localVar——Go 编译器会自动把它挪到堆，你不用操心 - 但若写
var p *int; func() { x := 42; p = &x }()，p后续解引用仍安全，因为x必然逃逸；可读性差，易被误判为“悬空”，实际不是问题
容易踩的坑：
- 以为
new(T)和&T{}完全等价——其实后者可能触发额外字段初始化逻辑，前者严格零值 - 在循环里反复
&slice[i]并存入切片，结果所有指针都指向最后一个元素（因slice[i]是临时副本）
什么时候必须用 unsafe.Pointer，什么时候纯属画蛇添足？
真实必要场景极少：标准库中 reflect 包读写 struct 字段、net 包把 []byte 直接映射为 syscall.Iovec、某些高性能序列化库做内存布局重解释。除此之外，99% 的所谓“性能瓶颈”靠优化算法或减少拷贝就能解决，不需要碰 unsafe。
典型画蛇添足操作：
- 只是为了“看起来快”而把
map[string]int强转成map[unsafe.Pointer]int——类型系统存在的意义就是防止这种事 - 用
uintptr存地址 + 手动偏移模拟数组遍历，却忘了 GC 不认uintptr，对象可能被提前回收 - 把
*os.File转成unsafe.Pointer再转成*int去读 fd——os.File结构体字段不公开，版本一升级就崩
性能影响提醒：
- 含
unsafe的包无法被 go vet 全面检查，CI 很难捕获潜在错误 - Go 未来版本可能收紧
unsafe使用规则（如限制转换链长度），老代码可能无法编译
nil 指针解引用和空 struct 指针的区别在哪？
var p *int; *p 会 panic，这是明确的运行时错误；但 var p *struct{}; *p 却合法且不 panic——因为 struct{} 占 0 字节，它的地址存在，解引用只是“读一段长度为 0 的内存”，Go 允许。
这个细节暴露了 Go 指针安全模型的真实边界：安全 ≠ 绝对防错，而是把危险操作（越界、非对齐访问、类型混淆）挡在编译期或 panic 点，把“语义模糊但技术可行”的灰色地带留给开发者判断。
容易被忽略的地方：
-
*ppanic 的本质是“试图读写无效地址”，不是“解引用 nil 本身”——所以unsafe.Pointer(nil)是合法值，但转成*int后解引用就崩 - 接口值底层是
(type, data)二元组，nil接口不等于nil指针；常有人写if myInterface != nil { ... }却没意识到里面指针可能是nil - 结构体嵌套指针字段时，
json.Unmarshal默认不会为nil字段分配内存，解引用前必须显式判空
