Go中不能直接修改string头部指针截取字符串，因其底层只读且不可变；unsafe.String和unsafe.Slice是Go 1.20+最安全的零拷贝替代方案，需确保数据不被GC回收且范围合法。
Go 里不能直接修改 slice 头部指针来“截取字符串”
字符串在 Go 中是只读的底层结构，string 类型本身没有可修改的 header；它由编译器保证不可变，任何试图通过 unsafe 操作其头部指针来“零拷贝截取”的做法，本质是在操作底层字节数组，但必须清楚：这不等于“修改 string 的 slice 头部”，而是构造一个新 string 或 []byte，且极易越界或引发 panic。
为什么 unsafe.String + unsafe.Slice 是当前最安全的替代方案
Go 1.20+ 提供了 unsafe.String 和 unsafe.Slice，它们明确封装了底层指针转换逻辑，并做了长度校验（运行时仍会检查越界），比手写 reflect.StringHeader 或裸指针更可靠。你不是在“修改 slice 头部”，而是在用受控方式复用底层数组内存。
- 必须确保原始字符串底层数据不会被 GC 提前回收（例如它来自常量、全局变量或已逃逸到堆上的大对象）
- 截取范围不能超出原字符串长度，否则触发 panic（
runtime error: slice bounds out of range） -
unsafe.String接收*byte和len，不接受uintptr—— 这避免了整数指针误算
// 示例：从 s 截取 [3:7]，零拷贝 s := "hello world" b := unsafe.String(&s[3], 4) // => "lo w"
常见错误：用 reflect.StringHeader 强制改 Data 字段
这种写法在 Go 1.20 后已被标记为危险且不稳定，reflect.StringHeader 不再保证字段顺序和对齐，且 Data 字段类型是 uintptr，无法直接参与地址运算。更严重的是，它绕过所有边界检查，一旦偏移计算错误，程序可能静默读到非法内存，或在 GC 时崩溃。
- 错误示范：
sh := (*reflect.StringHeader)(unsafe.Pointer(&s)); sh.Data += 3; sh.Len = 4—— 这段代码在 Go 1.21+ 编译失败或运行时 UB - 即使能编译，
sh.Data是uintptr，加法结果不是有效指针，不能直接传给unsafe.String - 字符串字面量的地址可能被优化掉，或位于只读段，强制取地址可能导致 segfault
真正需要极速截取时，该选 string 还是 []byte？
如果后续操作全是只读遍历或子串匹配，string 更轻量；如果要频繁拼接、修改或调用 bytes 包函数，直接用 []byte 避免反复转换。注意：string(s[3:7]) 看似简单，但底层仍会复制 —— 除非你用 unsafe.String 显式复用。
立即学习“go语言免费学习笔记（深入）”；
-
string([]byte)总是拷贝，哪怕源[]byte来自unsafe.Slice -
[]byte(string)也总是拷贝，Go 不允许 byte 切片直接指向 string 底层 - 若原始数据是
[]byte，优先用s[3:7]切片 —— 这才是真正的零拷贝 slice 操作
真正难的不是怎么“快”，而是怎么确保快的同时不踩内存陷阱。别碰 StringHeader，别假设字符串地址可任意偏移，用 unsafe.String 前先确认数据生命周期 —— 这些细节漏掉一个，就不是提速，是埋雷。
