unsafe.slice 仅在 buf 是生命周期明确且不会被提前 gc 回收的底层数组时更合适，可零分配复用原数组；否则易致悬垂指针或内存破坏。
unsafe.Slice 什么时候比 buf[i:j] 更合适
只有当 buf 是生命周期明确、不会提前被 GC 回收的底层数组时，unsafe.Slice 才有优势。标准切片截取 buf[i:j] 在逃逸分析判定为“可能逃逸”时（比如 buf 是函数参数、来自 make([]byte, N) 且后续要返回），会触发堆分配；而 unsafe.Slice(&buf[0], n) 绕过运行时检查，复用原底层数组，零分配。
- 适用场景：解析 mmap 内存、预分配大缓冲区中反复切小子切片、网络包解析中固定结构体头提取
- 必须满足：n ≤
len(buf)，且buf的存活时间 ≥ 返回切片的整个使用周期 - 禁止对
unsafe.Slice返回值调用append——它没有容量信息，越界写会直接破坏相邻内存 - 错误示例：
unsafe.Slice(&b[0], len(b)+1)或在b是局部变量但切片被返回后继续使用
unsafe.String 不是 string(b) 的简单替换
unsafe.String 的核心约束是“只读复用”，不是“任意转字符串”。string(b) 总是拷贝，unsafe.String(unsafe.SliceData(b), len(b)) 则直接共享 b 底层数组指针——前提是该数组内容不会被修改，且生命周期可控。
- 安全用法：从只读 mmap 区域、全局字典字节切片、
bytes.Buffer.Bytes()（注意非bytes.Buffer.String()）构造字符串 - 危险用法：对
io.Read到临时[]byte的结果立即调用unsafe.String——缓冲区可能下一刻就被复用或释放 - 绝对禁止：对
unsafe.String返回的字符串底层内存做任何写操作，Go 运行时假设字符串不可变 - 别混淆：
unsafe.StringData(s)只能用于原本就来自[]byte的字符串；常量字符串（如"hello"）的底层不可写、不可保证地址长期有效
string ↔ []byte 零拷贝互转的唯一安全路径
Go 1.20+ 后，(*[]byte)(unsafe.Pointer(&s)) 这类裸指针强转已被 vet 拦截，且在 GC 期间极易导致悬垂指针崩溃。正确路径只有两条原子组合：
- 从
[]byte→string：先用unsafe.SliceData(b)获取数据指针，再传给unsafe.String(ptr, len(b)) - 从
string→[]byte：先用unsafe.StringData(s)获取数据指针，再传给unsafe.Slice(ptr, len(s)) - 这两步缺一不可，不能跳过
Data函数直接传&s[0]——字符串字面量可能没有可寻址首字节 - 若原
string并非由[]byte构造（如fmt.Sprintf、"abc"），则反向转出的[]byte不可写，写入即未定义行为
最容易被忽略的生命周期陷阱
unsafe 不报错，但错误会在 GC 后某个时刻静默爆发——比如返回一个基于局部 []byte 的 unsafe.String，函数返回后局部变量栈帧回收，但字符串还在被引用，下次 GC 后该地址可能已分配给其他对象，读出来就是垃圾值，或者直接 panic。
- 判断依据不是“代码能不能编译”，而是“谁持有底层数组的所有权、何时释放”
- 全局变量、包级变量、mmap 映射、
sync.Pool管理的缓冲区相对安全；函数参数、局部make的切片极不安全 - 一旦涉及跨 goroutine 传递，必须额外确保写操作互斥——
unsafe.String共享的内存若被并发写，就是数据竞争
