Go unsafe 字符串转字节切片有哪些生命周期风险

把 string 转成 []byte，默认写法是复制；为了减少一次分配而使用 unsafe，则可能得到与字符串共用底层字节的只读别名。真正需要警惕的不是“转换语句会不会立刻失效”，而是别名切片的不可变约束、指针是否仍然保持 Go 的指针语义，以及调用方是否把它当成普通可写缓冲区。

本文只讨论字符串底层存储和生命周期边界。结论先说：不确定调用链是否全程只读时，使用 []byte(s)；只有在边界很小、只读保证能被代码结构固定下来时，才考虑 unsafe.StringData 与 unsafe.Slice 的组合。

先分清复制转换和别名转换

Go 字符串本质上是只读的字节序列。普通转换会创建独立的字节切片，后续修改切片不会回写字符串；不安全转换则只是把同一段数据用另一种视图暴露出来，调用方必须继续遵守字符串不可变的契约。

下面这个小函数把不安全边界集中在一个名字明确的位置。它适合交给只读解析器使用，不适合返回给会修改或异步持有切片的通用接口。

package readonly

import "unsafe"

// ReadonlyBytes 只创建字符串数据的只读视图，不允许调用方写入返回切片。
func ReadonlyBytes(s string) []byte {
	// 空字符串不依赖 unsafe.StringData 对地址的具体约定。
	if len(s) == 0 {
		return nil
	}
	// unsafe.Slice 的长度来自字符串长度，切片容量也被限定为同一长度。
	return unsafe.Slice(unsafe.StringData(s), len(s))
}

这里的“只读”不是 Go 类型系统给出的新类型，而是项目约定。返回值仍然是普通的 []byte，因此最好让函数名、包级注释和调用位置同时表达限制。

第一类风险：别名切片不能写

对别名切片做索引赋值、排序、原地解码或把它交给会复用缓冲区的函数，都会把“字符串不可变”变成调用方必须自己维护的前置条件。即使某次运行没有立即崩溃，也不能把这种结果当作可依赖的行为。

append 也不能当成安全护栏。当前用 unsafe.Slice 构造的切片容量等于长度，追加通常会分配新数组，但代码一旦改变容量来源、改成普通切片或把切片交给其他包装层，别名关系就不应靠猜。真正可靠的规则是：只要后续逻辑可能写入，就先复制。

func ParseHeader(s string) (byte, bool) {
	// 解析只读取字节，不把字符串的底层存储交给可写逻辑。
	b := ReadonlyBytes(s)
	if len(b) == 0 {
		return 0, false
	}
	// 这里只做索引读取；写入、排序和原地变换都不属于这个边界。
	return b[0], true
}

func MutableBytes(s string) []byte {
	// 需要修改、拼接或交给异步任务时，显式创建独立副本。
	return []byte(s)
}

第二类风险：把指针变成 uintptr

生命周期问题通常来自另一种写法：先从字符串取得地址，再把地址存到 uintptr，稍后转换回来。uintptr 只是整数，不是 Go 指针；垃圾回收器不会因为某个整数看起来像地址，就把对应对象当成仍被引用。

因此不要使用 reflect.StringHeader、reflect.SliceHeader 或自定义结构把地址字段保存成 uintptr，也不要在函数之间传递一个脱离原对象的整数地址。需要构造视图时，让 unsafe.Pointer 直接参与当前表达式，并让最终切片保持正常的 Go 指针语义；需要跨异步边界时，优先复制数据。

还要把“长度可信”单独看待。unsafe.Slice 不会替调用方推断真实长度；长度为负数或指针为空但长度非零时可能触发运行时错误。字符串长度来自 len(s) 时通常最容易建立对应关系，手工传入外部长度则需要先完成边界检查。

把不安全操作收敛成小项目边界

在实际项目里，我更愿意把它当成一个很小的“只读解析适配层”：入口接收字符串，内部只创建一次别名，马上交给只读函数，输出值而不是输出可写缓冲区。这样即使以后替换解析器，也只需要审查一个边界。

type HeaderReader struct{}

func (HeaderReader) ReadKind(s string) (byte, bool) {
	// 适配层把只读约束固定在本方法内，避免别名切片扩散到业务层。
	b := ReadonlyBytes(s)
	if len(b) 

如果解析器需要保留输入、异步处理、排序、拼接或调用未知的第三方接口，就不要返回别名切片。直接使用 []byte(s)，或者寻找同时接受 string 的标准库 API，通常比解释一条隐含的生命周期约定更便宜。

按场景选择实现

最后可以用三句话做代码审查：这个切片是否可能被写入？它是否会跨异步或缓存边界？地址是否被保存成了 uintptr？只要有一个答案不明确，就回到复制转换。

常见问题

普通的 []byte(s) 会不会影响原字符串？

它的目的就是创建独立字节切片，后续修改切片不会把写入操作设计成对原字符串的修改。代价是可能产生分配和复制。

只读别名一定比复制更快吗？

不能只凭转换语句下结论。是否值得承担 unsafe 的维护成本，要看解析器是否真正需要切片接口、调用链能否证明全程只读，以及性能数据是否来自真实负载。

归纳起来，字符串转字节切片的核心不是“能不能拿到地址”，而是“谁拥有底层字节、谁保证不写入、指针语义能否持续”。把不安全视图限制在短小的只读边界内，其他场景默认复制，通常是最容易长期维护的选择。