go 语言没有 jit 编译器，指针操作不会触发 jit；其真正影响在于逃逸分析（决定栈/堆分配）和 gc 扫描（增加标记开销），unsafe 与反射会削弱编译器检查。
Go 的指针不会触发 JIT 编译
Go 语言没有 JIT 编译器——这是最常被误解的前提。go run 启动的程序，底层走的是静态编译 + 直接生成机器码的路径，不是先编译成字节码再运行时编译。所以无论你用不用 *int、&x 或 unsafe.Pointer，都不会“触发”或“绕过”JIT，因为根本不存在 JIT。
常见错误现象：fatal error: unexpected signal during runtime execution 有时被误认为是“JIT 崩溃”，其实是 GC 扫描指针时碰到了非法内存（比如 unsafe 操作越界），和 JIT 完全无关。
- Go 的编译器（
gc）在构建阶段就完成全部优化，包括内联、逃逸分析、指针追踪 - 运行时（
runtime）只负责调度、GC、栈增长，不进行任何运行时代码重编译 - 所谓“热点函数优化”在 Go 中由编译期决定，不是靠执行次数动态触发
指针如何影响 Go 的逃逸分析
这才是指针真正起作用的地方：它直接决定变量分配在栈上还是堆上。编译器通过逃逸分析判断一个指针是否可能“逃出当前函数作用域”，一旦判定会逃逸，就会把原变量分配到堆，增加 GC 压力。
使用场景：高频创建小结构体但又需要返回其地址时，容易意外逃逸。
立即学习“go语言免费学习笔记（深入）”；
-
func newPoint() *Point { p := Point{1, 2}; return &p }→p必然逃逸，分配在堆 -
func getAddr(x int) *int { return &x }→x逃逸，即使只在函数内用 - 加
-gcflags="-m -l"可查看逃逸详情，比如./main.go:5:2: &x escapes to heap
unsafe.Pointer 和反射让指针行为更难预测
一旦进入 unsafe 或反射（reflect.Value.Addr()），编译器的逃逸分析和类型安全检查基本失效。这时指针的生命周期、有效性、对齐要求全靠程序员保证。
容易踩的坑：用 unsafe.Pointer 转换后，原变量若已超出作用域（比如栈上局部变量），解引用就是未定义行为，可能 crash 或读到脏数据。
-
u := unsafe.Pointer(&x); ...; y := *(*int)(u)—— 若x已随函数返回而销毁，y的值不可信 -
reflect.ValueOf(&x).Elem().UnsafeAddr()返回的地址，同样受制于x的生命周期 - 这类操作在 CGO 边界、内存池复用、结构体字段偏移计算中常见，但必须确保原始内存没被回收或重用
GC 如何扫描指针字段
Go 的三色标记 GC 会遍历所有可到达的对象，并检查其字段是否为指针类型（包括 interface、slice、map、channel 内部）。如果字段是 *T 或 unsafe.Pointer，GC 就把它当作潜在的存活对象引用，继续扫描下去。
性能影响：过多无效指针字段（比如 struct 里塞了个永远不使用的 *byte 字段）会导致 GC 扫描范围变大、暂停时间略增。
- struct 中混用指针与非指针字段，GC 仍需逐字段检查类型信息（虽然很快，但有开销）
- 用
go tool compile -S查看汇编，能发现编译器为含指针字段的 struct 插入了额外的 type info 表项 - 避免在热路径 struct 中放无意义的指针字段，尤其是
*struct{}这类空指针占位符
