Go 里指针本身不会越界，但 unsafe.Pointer 和 reflect 可能绕过边界检查
Go 的普通指针（*T）受 runtime 保护，无法像 C 那样随意算术偏移或解引用非法地址。真正危险的是主动放弃类型安全的路径：用 unsafe.Pointer 做地址运算，或通过 reflect.Value.UnsafeAddr() / reflect.SliceHeader 等方式构造出指向内存任意位置的指针。
- 常见错误现象：
panic: runtime error: invalid memory address or nil pointer dereference表面是空指针，实际可能是unsafe操作后解引用了非法地址；更隐蔽的是读到脏数据、触发 GC 崩溃或静默内存破坏 - 典型使用场景：高性能序列化（如
gogoprotobuf）、零拷贝网络包解析、与 C 交互（C.malloc返回的内存需手动管理） - 关键约束：只要没用
unsafe或reflect绕过类型系统，Go 编译器和 runtime 就不会让你“越界”——这不是靠程序员自觉，而是语言强制保障
用 unsafe.Slice 替代手写指针算术（Go 1.17+）
旧写法（Go 1.16 及以前）常这样操作底层数组：
ptr := unsafe.Pointer(&data[0])
hdr := &reflect.SliceHeader{
Data: uintptr(ptr) + offset,
Len: n,
Cap: n,
}
slice := *(*[]byte)(unsafe.Pointer(hdr))
问题在于：没校验 offset + n 是否超出原 data 底层内存范围，且 reflect.SliceHeader 是非导出结构，依赖内部布局，极易在版本升级后崩溃。
- Go 1.17 起必须用
unsafe.Slice：它会在 debug 模式下做边界检查（release 模式不检查，但语义明确） - 正确写法：
s := unsafe.Slice((*byte)(ptr), n)—— 第二个参数是长度，不是结束地址；起始地址ptr必须来自合法 slice/array 的首地址或其合法偏移（如unsafe.Offsetof） - 不能对
nilslice、已释放内存、栈上局部变量地址调用unsafe.Slice，否则行为未定义
和 C 交互时，别直接把 C.malloc 结果转成 Go slice
很多人这么写：
立即学习“go语言免费学习笔记（深入）”；
ptr := C.malloc(C.size_t(n)) slice := (*[1 << 30]byte)(ptr)[:n:n]
这非常危险：Go runtime 不知道这块内存是谁分配的，GC 不会管理它，也**不会校验你取的 n 是否超过 C.malloc 实际申请大小**。
- 正确做法：用
C.CBytes（它会 copy 到 Go heap）或runtime.Pinner（Go 1.21+）固定 C 分配的内存，再配合unsafe.Slice - 如果必须零拷贝，务必自己校验：
if n > maxAllowed { panic("out of C malloc bounds") }—— 这个maxAllowed得从C.malloc调用上下文里带出来，不能靠猜 -
C.free必须成对调用，且只能由分配者线程调用（多 goroutine 共享 C 内存时尤其容易踩坑）
静态分析工具比运行时更早发现隐患
Go 自带的 go vet 对部分 unsafe 误用有提示，但覆盖有限。真正管用的是专用工具：
-
staticcheck会警告：SA1023: possible misuse of unsafe.Pointer（比如把uintptr存到变量里跨函数传） -
govet -unsafeptr（Go 1.21+）专门检测unsafe.Pointer到uintptr转换后是否被持久化 - CI 中必须跑：
go vet -unsafeptr ./...+staticcheck ./...，仅靠本地测试很难暴露边界条件
最易被忽略的点：unsafe 相关代码一旦写错，往往在高负载、特定内存布局或 GC 触发时机下才爆发，复现成本极高。所以别等 panic，要把检查左移到写代码时。
