会，而且必然发生内存拷贝。因string只读、[]byte可写，语义冲突致转换必须拷贝以保障安全与不可变性；实测底层指针不同；无用户可控例外；性能优化应减少转换频次、缓存或换用零拷贝方案。
会，而且必然发生内存拷贝。这是 Go 语言规范强制要求的行为，不是实现细节或优化开关，2026 年依然如此，且没有改变迹象。
为什么必须拷贝？底层不可绕过
string 是只读的字节序列，底层结构只有指针 + 长度；[]byte 是可写的切片，含指针 + 长度 + 容量。二者语义冲突：
- 若 []byte(s) 不拷贝，后续 b[0] = 'X' 就会试图修改只读内存——违反语言安全性
- 若 string(
b) 不拷贝，原切片后续修改（如 b[0] = 99）就可能意外影响已生成的字符串——破坏不可变性保证
- 运行时无法在不拷贝的前提下同时满足“可写”和“只读”两种语义
实测验证：地址肯定不同
用 unsafe.StringData 和 unsafe.SliceData 可直接对比底层指针（仅用于调试，勿上生产）：
- s := "hello"
- b := []byte(s)
- unsafe.StringData(s) != unsafe.SliceData(b) → 输出 false，确认非同一块内存
有没有例外？极少数编译器特例不构成通路
某些特定场景下（如 map[string]v 的 key 比较、range over []byte(s) 的临时遍历），编译器可能做零分配优化，但：
- 这些是内部实现细节，不暴露为用户可控行为
- 不适用于任何需要持有、修改、传递或复用该 []byte 的场景
- 与 string → []byte 的常规转换路径完全无关
性能敏感时怎么办？少转、缓存、换思路
拷贝无法避免，但可以大幅减少其影响：
- 读字符串内容 → 用 strings.NewReader(s)，直接对接 io.Reader 接口，零拷贝
- 拼接构建字符串 → 用 strings.Builder，复用底层数组，避免反复 string/[]byte 来回转
- 需多次处理同一字符串 → 预分配 []byte 缓冲并复用，用 copy(dst, s) 替代每次 []byte(s)
- 涉及 I/O 或编码（如 JSON、HTTP）→ 优先传 []byte，很多标准库函数（json.Unmarshal、ResponseWriter.Write）原生支持，无需转回 string
