unsafe.Slice 长度计算错误导致越界的定位

用 unsafe.Slice 把一段连续内存转换为切片时，最容易误判的地方不是语法，而是 len 的单位和边界。len 表示元素数量，返回切片的长度与容量都等于它；如果把字节数当成元素数，或者在计算过程中发生整数溢出，后续访问就可能超出原始分配对象。

官方地址：https://pkg.go.dev/unsafe#Slice

先确认 unsafe.Slice 的长度与容量语义

官方文档把 unsafe.Slice(ptr, len) 描述为从 ptr 开始构造切片，长度与容量均为传入的 len。因此它不会因为指针指向的对象较小，就自动把结果截断为安全范围。定位问题时，第一件事是把“切片有多长”和“原始对象有多大”分成两个问题。

package main

import "unsafe"

func viewBytes(ptr *byte, n int) []byte {
	// n 是 byte 元素的数量，不是字节数乘 sizeof(byte) 后的结果。
	// 调用者必须保证 ptr 指向的对象至少能容纳 n 个 byte。
	return unsafe.Slice(ptr, n)
}

这里的危险点是“构造成功”不等于“访问合法”。如果 n 比原始对象能够提供的元素数更大，切片头仍然可能被构造出来，真正访问越界位置时才暴露问题，表现可能是错误数据、崩溃或难以复现的内存破坏。

沿指针来源回溯原始对象边界

遇到越界现象，不要先盯着最后一次索引。沿调用链向前追踪三项信息：指针来自哪个分配对象、它指向对象的哪个元素、对象在整个切片使用期间是否仍然存活。把一个数组中间位置的指针当作首地址，或者把已经失效的临时缓冲区交给异步任务，都会让长度检查失去依据。

import "unsafe"

type packet struct {
	data []byte
}

func packetView(p *packet, n int) []byte {
	if p == nil {
		// 先拒绝空对象，避免把 nil 传播到底层转换路径。
		return nil
	}
	if n  len(p.data) {
		// n 必须落在原始切片仍然拥有的元素范围内。
		return nil
	}
	if n == 0 {
		// 零长度直接返回原切片的零长度视图，减少 unsafe 使用面。
		return p.data[:0]
	}
	// 只有在边界已经由 p.data 证明后，才把首元素地址交给 unsafe.Slice。
	return unsafe.Slice(&p.data[0], n)
}

如果原始数据本身已经是 []byte，优先使用切片表达式，不要为了“零拷贝”再转一次指针。只有在确实需要把外部内存或特殊布局映射成 Go 切片时，才把 unsafe.Slice 放在很小的封装函数中，并让封装函数承担边界契约。

核对元素数量与字节数的换算

最常见的错误来自单位混用：协议字段给出的是字节数，而目标切片的元素类型可能是结构体；也可能先用 n * unsafe.Sizeof(T(0)) 算字节数，再把这个字节数误传给 unsafe.Slice。正确做法是明确接口究竟需要“元素数量”还是“字节数量”，并在乘法前做上界保护。

package main

import "unsafe"

type record struct {
	Kind uint16
	Size uint32
}

func recordView(ptr *record, byteCount int) []record {
	itemSize := int(unsafe.Sizeof(record{}))
	if itemSize == 0 || byteCount 

如果元素数量来自两个外部字段的乘积，不能只检查结果是否为负。对有符号整数，要在乘法前比较上界；对无符号整数，要检查乘法是否超过目标类型可表示范围。一个实用原则是：先把输入限制到业务允许的最大元素数，再换算字节数，最后再次确认总字节数不超过原始对象。

处理 nil、零长度和版本兼容边界

unsafe.Slice(nil, 0) 是文档定义的特殊情况，会返回 nil 切片；但 nil 指针配合非零长度会触发运行时 panic。排障时要把“没有元素”和“没有有效指针”区分开，不要用把长度改成零的方式掩盖上游长度计算错误。

import "unsafe"

func emptyOrView(ptr *byte, n int) []byte {
	if n 

unsafe.Slice 从 Go 1.17 引入。若项目仍要兼容更早版本，不能只替换一处调用，还要检查构建约束、底层转换封装和测试环境；迁移时建议先保留同一套长度契约，再替换实现，避免把版本变化与边界修复混在一起。

用小范围测试固定排障结论

边界测试的目标不是证明 unsafe 代码永远安全，而是把长度契约固定下来。至少覆盖空输入、单元素、最大合法长度、负长度、超过对象容量以及可能导致乘法溢出的输入；如果接口允许从字节数转换，还要覆盖不能整除元素大小的情况。

func TestRecordViewBoundaries(t *testing.T) {
	data := make([]record, 4)
	ptr := &data[0]

	tests := []struct {
		name string
		bytes int
		want int
	}{
		{"zero", 0, 0},
		{"one", int(unsafe.Sizeof(record{})), 1},
		{"all", len(data) * int(unsafe.Sizeof(record{})), len(data)},
		{"partial", int(unsafe.Sizeof(record{})) - 1, 0},
	}
	for _, tc := range tests {
		t.Run(tc.name, func(t *testing.T) {
			// 用返回长度核对字节到元素的换算，不读取可能越界的元素。
			got := recordView(ptr, tc.bytes)
			if len(got) != tc.want {
				t.Fatalf("len=%d, want %d", len(got), tc.want)
			}
		})
	}
}

迁移清单

1. 把所有 unsafe.Slice 调用的 len 标注为“元素数”或“字节换算后的元素数”。
2. 在封装函数入口检查负数、最大业务长度、整除关系和整数溢出。
3. 记录指针指向的原始分配对象与生命周期，避免跨越对象边界。
4. 对 nil、零长度、最大合法值和超界输入增加测试。
5. 如果普通切片操作已经能表达需求，移除多余的 unsafe 转换。

常见问题

unsafe.Slice 的 len 参数是字节数吗？

不是。它是目标元素的数量。只有当元素类型是 byte 时，元素数量才恰好与字节数相同。

传入比对象更大的长度会立即报错吗？

不能依赖它立即报错。长度契约主要由调用者保证，真正访问超出原始对象的元素时才可能暴露风险，因此要在构造前完成边界检查。

为什么不直接把长度截断到零？

截断会掩盖上游协议或计算错误，可能让调用方误以为数据为空。更稳妥的是返回明确错误，并记录原始长度、元素大小和可用边界。