答案。

在Go中，string和[]byte之间的转换通常会导致分配新内存（分配），因为字符串是不可变的（immutable），而字节切片是可变的（mutable）。一些内部优化（逃逸分析）可能会导致例外，但这些优化并不是保证的，并且会在Go的版本之间发生变化。

直接转换:

[]byte(s string)：总是分配一个新的字节数组并复制数据。
string(b []byte)：也总是将字节数组中的数据复制到一个新的字符串中。

零分配是一种避免额外分配的方法。在Go的标准库中，通过unsafe包可以进行不安全的转换，允许在不复制的情况下引用相同的数据。只有在完全理解相关风险的情况下才可以使用它。

import (
    "reflect"
    "unsafe"
)

func BytesToString(b []byte) string {
    return *(*string)(unsafe.Pointer(&b))
}

func StringToBytes(s string) []byte {
    sh := (*reflect.StringHeader)(unsafe.Pointer(&s))
    bh := reflect.SliceHeader{
        Data: sh.Data,
        Len:  sh.Len,
        Cap:  sh.Len,
    }
    return *(*[]byte)(unsafe.Pointer(&bh))
}

在大多数情况下，最好不要使用这些技巧——这会破坏数据的安全性（可以通过共享切片来修改字符串的内容，导致错误）。

诱导性问题。

常常有人问：“如果字符串很小或是常量，string到[]byte的转换就不会有分配吗？”

**正确答案：**不管字符串的大小如何，编译器总是会创建一个新的字节切片并复制内容。例外情况只存在于不保证安全性的unsafe优化中，而这些在Go官方文档中没有支持。

因为不了解主题的细微差别而导致的实际错误示例。

故事

团队正在编写一个高负载的日志解析服务，并不断将输入字符串转换为字节切片并反向处理。在高峰时段，垃圾回收器花费多达30%的处理器时间来收集短命的副本。经过分析发现：每次string↔[]byte转换都会分配一个单独的内存区域。经过引入池和重新设计API，成功消除了大部分转换，将GC的负担减半。

故事

一位开发者通过使用unsafe转换bytes→string来优化JSON处理以避免分配。最初性能有所提升，但一个月后出现了崩溃：某个字节缓冲区被重用，字符串指向旧的修改过的数据。最终只能通过恢复到标准的副本和重新设计进程间API来修复。

故事

在通过网络发送大规模二进制数据时，决定“优化”序列化，使用BytesToString（不复制）。有一次，发送的字符串变得公开可见，而字节切片的内容立刻被覆盖，导致发送了垃圾，并将私有数据泄露到错误包的日志中。最终，内存的去重导致了私有数据的泄露！

在Go中，字符串和字节切片之间的零分配（zero allocation）是如何工作的？在什么情况下进行string ↔ []byte转换时会分配新内存，而在什么情况下可以避免分配？

答案。

诱导性问题。

因为不了解主题的细微差别而导致的实际错误示例。