字符串与[]byte转换应优先用强制类型转换：[]byte(s)和string(b)均为零拷贝，仅修改头信息；仅当需修改字节且复用原string时才用copy；注意生命周期，避免悬空指针和数据竞争。
字符串转[]byte：别用copy，直接强制类型转换就行
Go里string和[]byte底层内存布局一致（只读 vs 可写），所以绝大多数场景下，[]byte(s)就是最高效、最安全的转换方式。它不分配新内存，只是改变头信息里的标志位和长度字段。
常见错误是手动make([]byte, len(s)); copy(dst, s)——这会触发一次完整内存拷贝，性能差3倍以上，还多占一倍内存。
- 仅当你要修改字节且后续还要复用原
string变量时，才需要copy（防止底层数据被意外改写） -
[]byte(s)返回的切片与s共享底层数组，所以不能在goroutine间随意传递并修改，否则有数据竞争风险 - 该转换在Go 1.20+已完全内联，汇编里就几条指令，没函数调用开销
[]byte转字符串：string(b)安全，但要注意生命周期
和上一个方向相反，string(b)也是零拷贝转换——只要b的底层数组不会被回收或重用，这个string就一直有效。
最容易踩的坑是把局部[]byte（比如函数内make出来的）转成string后返回，结果外部拿到的是指向已失效栈内存的悬空指针，运行时可能 panic 或读到垃圾值。
立即学习“go语言免费学习笔记（深入）”；
- 如果
b来自bytes.Buffer.Bytes()或io.Read()等稳定来源，直接string(b)没问题 - 如果
b是临时make的，又必须返回string，那就老老实实string(append([]byte{}, b...))——多一次拷贝，但安全 - Go 1.22起对
string(b)做了更严格的逃逸分析，部分场景会自动插入拷贝，但别依赖这个，自己控制更可靠
高频场景：HTTP响应体、JSON解析、文件读取时的转换策略
实际项目里，这些地方不是“要不要转”，而是“什么时候转、转几次”。比如http.Response.Body读出来是[]byte，但你想用json.Unmarshal，它接受[]byte，根本不用转string；反过来，日志打印或调试时想看内容，才转string。
- JSON解析：始终用
json.Unmarshal(b, &v)，别先string(b)再json.Unmarshal([]byte(s), &v)——白费一次分配 - 文件读取：
os.ReadFile返回[]byte，若后续只做字节处理（如哈希、编码转换），全程保持[]byte；只有需要strings.Split或正则匹配时，才转string - HTTP header值、URL path等本就是
string，别为了“统一类型”强行转[]byte——增加GC压力且无收益
边界情况：含\0字节、非UTF-8内容、超大字符串的处理
Go的string类型不保证UTF-8，也不禁止\0，所以转换本身不校验编码。但很多标准库函数（如fmt.Printf、strings.Index）遇到\0会截断，而[]byte操作不会。
- 处理二进制协议（如自定义RPC payload）时，坚持用
[]byte，避免任何隐式string转换 - 从C代码传入含\0的
*C.char，用C.GoStringN而非C.GoString，否则提前截断 - 超过1GB的字符串转
[]byte虽仍零拷贝，但可能导致GC扫描变慢——这时要考虑流式处理，而不是全量加载
