无法安全读取切片或字符串长度，因go未承诺reflect.sliceheader/reflect.stringheader内存布局稳定，unsafe越权访问依赖未定义行为，正确方式仅是使用len(slice)或len(s)。
不能用 unsafe “越权”获取切片或字符串长度——Go 没有提供任何合法接口让你绕过类型系统读取未导出的长度字段，所谓“非法长度获取”本质是误读内存布局或依赖未定义行为。
为什么无法安全读取切片的 len 字段
切片头（reflect.SliceHeader）包含 Len、Cap、Data 三个字段，但它的内存布局不是稳定 ABI：Go 编译器可能因对齐、GOARCH 或版本升级调整字段顺序。即使你用 unsafe.Pointer(&slice) 强转为 *reflect.SliceHeader，hdr.Len 的值在 Go 1.20+ 之后也不再被保证与运行时实际长度一致——因为运行时内部已改用更紧凑的表示，且部分字段被内联或优化掉。
常见错误做法：
- 直接
(*reflect.SliceHeader)(unsafe.Pointer(&slice)).Len→ 可能在某些 GOOS/GOARCH 下读错字节，返回垃圾值 - 用
unsafe.Offsetof计算偏移后手动读取uintptr→ 偏移量本身不跨平台稳定，且字段对齐受//go:notinheap等注释影响 - 假设
len总是位于前 8 字节 → 在 32 位系统或带 padding 的结构体中完全失效
字符串长度同样不可“越权”读取
string 的底层结构（reflect.StringHeader）也仅在文档中描述，不承诺稳定布局。官方明确禁止用户代码直接访问其 Len 字段，因为：
-
string常量可能被编译器折叠进只读段，其头信息甚至不驻留在可寻址内存中 - 运行时可能复用同一底层数组构造多个
string，长度信息由上下文决定，而非固定存储 -
unsafe.StringData(s)只返回*byte，不暴露长度；想“反推”长度需额外元数据，而该元数据不在字符串自身里
真正能拿到长度的合法方式只有这些
所有“获取长度”的操作都必须走公开 API，unsafe 不参与：
- 切片长度：直接用
len(slice)—— 这是编译器内建指令，零开销，且语义明确 - 字符串长度：直接用
len(s)—— 同样是编译器优化过的常量时间操作 - 若你在 C 函数中接收了
[]byte并需要传长度给 C，用C.goBytes或unsafe.Slice+ 显式传len(slice)，而不是试图从指针里“挖”出来 - 如果封装了一个自定义结构体并想隐藏长度逻辑，导出一个
Len()方法，而不是用unsafe绕过它
真正危险的不是“读不到”，而是你以为读到了——比如在交叉编译环境或升级 Go 版本后，原来能跑通的 unsafe 读取突然返回错误值，而这种 bug 很难通过测试覆盖，因为它依赖底层内存排布细节。别把临时可行当成正确可行。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
