[]byte(s)和string(b)绝大多数情况是零拷贝、无分配、最快最安全的转换方式，因仅修改切片头字段、共享底层数组，但需严格管控生命周期与并发写入风险。
直接用 []byte(s) 和 string(b) 就行，绝大多数情况零拷贝、无分配、最快最安全；但必须清楚它们共享底层数组，生命周期和并发修改是关键风险点。
为什么 []byte(s) 不该用 copy 手动转
常见错误是写 dst := make([]byte, len(s)); copy(dst, s)——这会触发完整内存拷贝，性能差 3 倍以上，还多占一倍堆内存。Go 的 []byte(s) 是纯头信息转换：只改切片头里的数据指针、长度、容量字段，不碰底层字节数组。字符串和 []byte 在内存布局上本就是同一块只读/可写区域的两种视图。
- 仅当你要修改字节，且后续还要继续使用原
s变量（比如缓存原始字符串）时，才需要copy -
[]byte(s)返回的切片与s共享底层数组，不能在 goroutine 间传递并写入，否则触发数据竞争 - Go 1.20+ 已将该转换完全内联，汇编里就几条指令，没函数调用开销
string(b) 返回后内容突然变乱？查生命周期
最常踩的坑是把局部 []byte（比如函数内 make 出来的、或 bytes.Buffer.Bytes() 返回的引用）直接转成 string 并返回——外部拿到的可能是悬空指针，运行时 panic 或读到垃圾值。
-
bytes.Buffer.Bytes()、io.Read()、os.ReadFile()返回的[]byte底层稳定，可安全转string(b) - 若
b是临时make的，又必须返回string，用string(append([]byte{}, b...))——多一次拷贝，但内存安全 - Go 1.22 起对
string(b)加强了逃逸分析，部分场景自动插入拷贝，但别依赖它，自己控制更可靠
HTTP/JSON/文件处理中，别为转而转
高频场景里，“要不要转”本质是“要不要额外分配”，不是类型统一问题。
立即学习“go语言免费学习笔记（深入）”；
-
json.Unmarshal(b, &v)直接接受[]byte，别先string(b)再json.Unmarshal([]byte(s), &v)——白费一次分配 -
http.Response.Body读出来是[]byte，若后续做哈希、base64 编码、gzip 解压，全程保持[]byte；只有需strings.Split或正则匹配时才转string - HTTP header、URL path 等本就是
string，强行转[]byte只增加 GC 压力，无实际收益
含 \0 或非 UTF-8 数据怎么办
Go 的 string 类型不校验 UTF-8，也不禁止 \0，所以转换本身不会报错或截断。但标准库函数行为会因此变化：
-
fmt.Printf("%s", s)遇到\0会提前截断输出（C 风格） -
regexp.Compile、strings.Index等函数可能行为异常或 panic，因为它们默认假设输入是有效 UTF-8 - 若数据来自二进制协议或加密 payload，保持
[]byte处理更稳妥；仅当明确需文本语义（如日志打印、HTTP 响应体解析）才转string，并自行校验
真正难的不是怎么写那两行转换代码，而是判断哪次该零拷贝、哪次该主动拷贝、哪次根本不用转——这取决于数据来源、生命周期、是否并发访问、下游函数签名这四个变量的组合。漏掉任何一个，都可能在线上跑几天才暴露。
