Go unsafe把数组视图转换为切片的风险边界

我第一次把固定数组交给零拷贝解析器时，直觉是把数组地址改写成切片就够了。真正容易出问题的地方不在这一行转换，而在数组可能为空、切片长度可能写错，以及底层对象的生命周期已经结束。Go 官方的 unsafe.Slice 可以建立数组视图，但它不会替你证明这三件事。

先把数组视图转换的边界说清

这个标题对应的是“数组已经存在，只想以切片 API 读取或处理”的场景。若只是为了调用函数，优先让函数接收数组切片、直接复制到新切片，或者使用普通的 arr[:]。只有在泛型封装、底层协议适配或明确的零拷贝热路径中，才值得承担 unsafe 的维护成本。

官方文档说明，unsafe.Slice(ptr, len) 返回的切片长度和容量都是 len；当指针为 nil 且长度为 0 时，结果是 nil。负长度会触发运行时 panic，非零长度配 nil 指针也会 panic。这意味着“能转换”不等于“可以访问任意范围”。

用首元素指针构造共享存储的切片

对一个非空数组，最直观的写法是把首元素地址交给 unsafe.Slice。这里的切片只是数组的另一个视图，修改切片元素会修改原数组；代码没有分配新的元素空间。

package main

import "unsafe"

func arrayView(arr *[4]byte) []byte {
	// 调用方保证 arr 非 nil；长度来自数组类型，避免手写容量。
	return unsafe.Slice(&arr[0], len(arr))
}

func main() {
	data := [4]byte{'G', 'o', '1', '7'}
	view := arrayView(&data)
	// 视图和 data 共享存储，这次写入会改变 data[0]。
	view[0] = 'g'
}

这里把数组指针作为参数还有一个好处：数组长度由类型携带，调用点不会额外传入一个可能失配的整数。若输入来自更大的内存块，则必须把“可读元素数”作为单独的可信边界传入，并在构造前检查它。

空数组、长度和指针边界要单独处理

最常见的坑是对零长度数组取 &arr[0]。它在语法上像普通数组，却没有下标 0。可以先用长度分支返回 nil，或者让泛型辅助函数接收一个已有指针；不要用伪造地址去绕开检查。

func bytesView(arr []byte) []byte {
	if len(arr) == 0 {
		// 空输入没有可供取址的第一个元素，返回 nil 视图。
		return nil
	}
	// len(arr) 来自同一底层数组，避免跨越分配对象边界。
	return unsafe.Slice(&arr[0], len(arr))
}

如果手里是固定数组，零长度数组应在构造前单独分支；如果手里是普通切片，arr[:] 本身已经是合适视图，不需要再绕到 unsafe。长度必须是非负整数，并且不能超过指针所指向的实际分配对象，否则得到的只是一个看似合法、访问时才暴露问题的切片描述符。

发布前检查对象存活，不要把 uintptr 当缓存指针

数组视图只在底层数组仍然有效时有意义。不要把 unsafe.Pointer 转成 uintptr 放进结构体，之后再转回指针；官方文档明确指出，uintptr 是整数，不会让垃圾回收器继续保留对象，也不会获得指针更新语义。指针转换和必要的算术应保持在同一个表达式里，并且结果仍要落在原分配对象中。

我在生产代码里会把这类函数限制在很小的边界：参数持有原数组或切片，返回值不逃逸到异步任务；调用处写一条长度不变量；上线前跑 go vet，再审查是否存在跨对象访问、保存地址或修改只读数据的路径。go vet 没有报警也不等于所有 unsafe 都正确。

常见问题与取舍

数组转切片会复制数据吗？不会。这个写法建立共享底层存储的视图；需要独立所有权时应显式复制。

能不能用 reflect.SliceHeader 自己拼？不建议。官方文档要求它只用于指向真实切片或字符串的头部，直接声明一个 header 再填 Data 容易让指针失去垃圾回收语义。

什么时候应该不用 unsafe？只要普通切片切片表达式、复制或标准库接口能满足需求，就优先选择它们。零拷贝带来的收益必须大于边界审查和跨版本可移植性的代价。

最后可以把检查清单压缩成四句话：输入非空时才取首元素；长度来自可信对象边界；视图使用期间原数组保持存活；任何 uintptr 都不作为长期指针。满足这些条件，数组到切片的转换才是可维护的底层优化，而不是隐藏的越界入口。