go中string与[]byte内存布局不同，直接强制转换可能导致写入只读内存而panic；unsafe.string/slice需确保指针有效且内存生命周期足够；多数场景应优先使用copy。
字符串转[]byte时为什么不能直接强制类型转换
Go 语言里 string 和 []byte 内存布局不同：前者是只读的 header（含指针+长度），后者是可读写的 header（含指针+长度+容量）。直接 unsafe.Pointer 转换后写入 []byte，可能改写到只读内存，运行时 panic 或静默崩溃。
- 常见错误现象：
fatal error: unexpected signal during runtime execution，或在 CGO 调用中触发段错误 - 仅当字符串底层数据确定为可写（比如来自
make([]byte)后转成string再转回）时，才可考虑零拷贝回转 —— 但 Go 标准库不保证这种“往返安全” -
reflect.StringHeader和reflect.SliceHeader字段名和大小虽一致，但语义隔离，编译器不会帮你校验生命周期
unsafe.String 和 unsafe.Slice（Go 1.20+）怎么用才不出事
Go 1.20 引入了两个更安全的封装函数，它们仍依赖 unsafe，但把指针合法性检查前移到了调用侧，避免手写 header 结构体出错。
- 使用场景：需要把 C 函数返回的
*C.char快速转成 Go 字符串，且确认该内存由 C 分配、长期有效；或从 mmap 映射区读取只读文本 -
unsafe.String(ptr, len)要求ptr指向连续的 UTF-8 字节，且len不超过该内存块实际可用长度，否则越界读 -
unsafe.Slice(ptr, len)对[]byte更友好，但同样要求ptr可寻址、内存未被释放；若底层是栈分配的临时变量地址，函数返回后立刻失效 - 示例：
s := unsafe.String(&data[0], len(data))—— 这里data必须是切片，且生命周期覆盖s使用期
为什么 copy 仍是大多数情况下的正确选择
零拷贝听起来快，但多数业务场景下，一次小字符串（copy 开销远低于维护内存生命周期带来的复杂度和风险。
- 性能影响：现代 CPU 缓存友好，
copy在小数据上基本是单指令循环，实测比unsafe封装慢不到一个数量级，但稳定性高几个数量级 - 兼容性影响：不依赖 Go 版本、不触发 vet 工具警告、不破坏 gc 垃圾回收假设
- 容易踩的坑：有人用
unsafe把 HTTP body 的[]byte转成string后缓存，结果 body 被复用或重用底层 buffer，导致后续请求看到脏数据 - 真正需要零拷贝的场景极少：高频日志行解析、协议解析器（如 DNS/HTTP/2 解帧）、内存映射文件流式处理
CGO 边界传参时 C.CString 和 C.GoString 的替代方案
这两个函数内部做了内存拷贝，常被诟病性能差。想绕过，就得自己管理 C 内存生命周期，但代价是必须显式 C.free，且不能传栈变量地址给 C。
立即学习“go语言免费学习笔记（深入）”；
- 安全替代：用
C.CBytes+(*C.char)(unsafe.Pointer(&bytes[0]))，但必须确保bytes是 heap 分配、且 C 使用完前不被 GC 回收（可用runtime.KeepAlive） - 常见错误现象：
free(): invalid pointer，通常是因为传了局部切片底层数组地址，函数返回后数组被释放 - 参数差异：
C.GoString假设 C 字符串以\0结尾；若 C 数据含中间\0，必须用C.GoStringN并显式传长度 - 更稳妥的做法：对短字符串继续用
C.CString；对长缓冲区，用C.malloc分配，再用unsafe.Slice构建 Go 视图，全程自己控制生命周期
